Translated ['src/generic-methodologies-and-resources/phishing-methodolog

2025-10-10 18:36:50 +00:00 · 2025-09-29 23:44:03 +00:00 · 2025-09-29 23:44:03 +00:00 · 96580cfd36
commit 96580cfd36
parent c86b88d252
4 changed files with 229 additions and 106 deletions
--- a/.gitignore
+++ b/.gitignore
@ -11,3 +11,4 @@ book
 book/*
 hacktricks-preprocessor.log
 hacktricks-preprocessor-error.log
+searchindex.js
--- a/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md
+++ b/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md
@ -3,97 +3,111 @@
 {{#include ../../banners/hacktricks-training.md}}


+## iOS Exploit Mitigations
+
+- **Code Signing** in iOS werk deur te vereis dat elke stukkie uitvoerbare kode (apps, libraries, extensions, ens.) kriptografies geteken is met ’n sertifikaat uitgegee deur Apple. Wanneer kode gelaai word, verifieer iOS die digitale handtekening teen Apple se vertroude root. As die handtekening ongeldig, afwesig of gemodifiseer is, weier die OS om dit uit te voer. Dit verhoed dat aanvallers kwaadwillige kode in regmatige apps inprop of unsigned binaries laat loop, en blokkeer dus die meeste exploit-kettings wat staatmaak op die uitvoering van ewekansige of veranderde kode.
+- **CoreTrust** is die iOS substelsel wat code signing by runtime afdwing. Dit verifieer handtekeninge direk met Apple se rootsertifikaat sonder om op gecachte trust stores te staatmaak, wat beteken dat slegs binaries wat deur Apple geteken is (of met geldige entitlements) kan uitvoering kry. CoreTrust verseker dat selfs as ’n aanvaller ’n app na installasie manipuleer, stelselbiblioteke verander of probeer om unsigned code te laai, die stelsel die uitvoering sal blokkeer tensy die kode steeds korrek geteken is. Hierdie streng afdwinging sluit baie post-exploitation vektore wat ouer iOS-weergawes met swakker of omseilbare handtekeningkontroles toegelaat het.
+- **Data Execution Prevention (DEP)** merk geheuegebiede as nie-uitvoerbaar tensy dit duidelik kode bevat. Dit keer dat aanvallers shellcode in datagebiede (soos die stack of heap) inprop en dit uitvoer, en dwing hulle om meer komplekse tegnieke soos ROP (Return-Oriented Programming) te gebruik.
+- **ASLR (Address Space Layout Randomization)** randomiseer die geheueadresse van kode, libraries, stack en heap elke keer as die stelsel loop. Dit maak dit veel moeiliker vir aanvallers om te voorspel waar nuttige instruksies of gadgets is, en breek baie exploit-kettings wat op vaste geheue-lay-outs staatmaak.
+- **KASLR (Kernel ASLR)** pas dieselfde randomisasiekonsep toe op die iOS-kernel. Deur die kernel se basisadres by elke boot te skud, verhoed dit dat aanvallers betroubaar kernel-funksies of strukture lok, wat die moeilikheidsgraad van kernelvlak-exploits verhoog wat andersins volle stelselbeheer sou gee.
+- **Kernel Patch Protection (KPP)**, ook bekend as **AMCC (Apple Mobile File Integrity)** in iOS, monitor voortdurend die kernel se kodebladsye om te verseker dat dit nie gewysig is nie. As enige manipulasie opgespoor word—soos ’n exploit wat kernel-funksies probeer patch of kwaadwillige kode invoeg—sal die toestel onmiddellik panic en herlaai. Hierdie beskerming maak volhoubare kernel-exploits baie moeiliker, aangesien aanvallers nie net kernel-instruksies kan hook of patch sonder om ’n stelselcrash te veroorsaak nie.
+- **Kernel Text Readonly Region (KTRR)** is ’n hardware-gebaseerde sekuriteitsfunksie wat op iOS-toestelle ingeval is. Dit gebruik die CPU se geheuebeheerder om die kernel se kode (text) afdeling permanent as read-only na boot te merk. Sodra dit gesluit is, kan selfs die kernel self nie hierdie geheuegebied wysig nie. Dit verhoed dat aanvallers—en selfs bevoorregte kode—kernel-instruksies by runtime patch, wat ’n groot klas exploits toemaak wat gebaseer was op direkte wysiging van kernel-kode.
+- **Pointer Authentication Codes (PAC)** gebruik kriptografiese handtekeninge ingebed in ongebruikte biete van pointers om hul integriteit te verifieer voordat dit gebruik word. Wanneer ’n pointer (soos ’n return address of funksiepointer) geskep word, teken die CPU dit met ’n geheime sleutel; voor dereferensie kontroleer die CPU die handtekening. As die pointer gemanipuleer is, misluk die kontrole en stop uitvoering. Dit verhoed dat aanvallers pointers forgery of hergebruik in geheue-korrupsie-exploits, en maak tegnieke soos ROP of JOP baie moeiliker om betroubaar uit te voer.
+- **Privilege Access never (PAN)** is ’n hardware-funksie wat verhoed dat die kernel (bevoorregte modus) direk user-space geheue benader tensy dit uitdruklik toegang toelaat. Dit stop aanvallers wat kernel-code-uitvoering verkry het om maklik user-memory te lees of te skryf om exploits te eskaleer of sensitiewe data te steel. Deur noue skeiding af te dwing verminder PAN die impak van kernel-exploits en blokkeer baie algemene privilege-escalation-tegnieke.
+- **Page Protection Layer (PPL)** is ’n iOS-sekuriteitsmeganisme wat kritiese kernel-beheerde geheuegebiede beskerm, veral dié wat verband hou met code signing en entitlements. Dit handhaaf streng skryfbeskermings met behulp van die MMU (Memory Management Unit) en addisionele kontroles, en verseker dat selfs bevoorregte kernel-kode nie lukraak sensitiewe bladsye kan wysig nie. Dit verhoed dat aanvallers wat kernelvlak-uitvoering kry, sekuriteit-kritieke strukture manipuleer, wat persistentie en code-signing-omseilings aansienlik moeiliker maak.
+
+
 ## Physical use-after-free

-Dit is 'n opsomming van die pos by [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html). Verder kan meer inligting oor exploits wat hierdie tegniek gebruik gevind word by [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
+This is a summary from the post from [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) moreover further information about exploit using this technique can be found in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)

 ### Geheuebestuur in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>

-Die **virtual memory address space** vir gebruikersprosesse op iOS strek van **0x0 to 0x8000000000**. Hierdie adresse kaart egter nie direk na fisiese geheue nie. In plaas daarvan gebruik die **kernel** **page tables** om virtuele adresse na werklike **physical addresses** te vertaal.
+Die **virtual memory address space** vir user-processes op iOS strek van **0x0 to 0x8000000000**. Hierdie adresse kaart egter nie direk na fisiese geheue nie. In plaas daarvan gebruik die **kernel** **page tables** om virtuele adresse na werklike **physical addresses** te vertaal.

-#### Levels of Page Tables in iOS
+#### Vlakke van bladsytabelle in iOS

-Page tables is hiërargies georganiseer in drie vlakke:
+Bladsytabelle is hiërargies in drie vlakke georganiseer:

 1. **L1 Page Table (Level 1)**:
-* Elke inskrywing hier verteenwoordig 'n groot gebied van virtuele geheue.
-* Dit dek **0x1000000000 bytes** (of **256 GB**) virtuele geheue.
+* Elke entiteit hier verteenwoordig ’n groot reeks virtuele geheue.
+* Dit dek **0x1000000000 bytes** (of **256 GB**) van virtuele geheue.
 2. **L2 Page Table (Level 2)**:
-* 'n Inskrywing hier verteenwoordig 'n kleiner streek van virtuele geheue, spesifiek **0x2000000 bytes** (32 MB).
-* 'n L1-inskrywing kan na 'n L2-table wys as dit nie die hele streek self kan map nie.
+* ’n Entiteit hier verteenwoordig ’n kleiner streek van virtuele geheue, spesifiek **0x2000000 bytes** (32 MB).
+* ’n L1-entiteit kan na ’n L2-tabel wys as dit nie die hele streek self kan map nie.
 3. **L3 Page Table (Level 3)**:
-* Dit is die fynste vlak, waar elke inskrywing 'n enkele **4 KB** geheuebladsy map.
-* 'n L2-inskrywing kan na 'n L3-table wys indien meer gedetailleerde beheer benodig word.
+* Dit is die fynste vlak, waar elke entiteit ’n enkele **4 KB** geheuebladsy map.
+* ’n L2-entiteit kan na ’n L3-tabel wys as meer gedetailleerde beheer benodig word.

-#### Mapping Virtual to Physical Memory
+#### Mapping van virtueel na fisies geheue

 * **Direct Mapping (Block Mapping)**:
-* Sommige inskrywings in 'n page table map direk 'n reeks virtuele adresse na 'n aaneenlopende reeks fisiese adresse (soort van kortpad).
+* Sommige entiteite in ’n bladsytabel kaart ’n reeks virtuele adresse direk na ’n aaneenlopende reeks fisiese adresse (soos ’n kortpad).
 * **Pointer to Child Page Table**:
-* As fynere beheer benodig word, kan 'n inskrywing op een vlak (bv. L1) na 'n child page table op die volgende vlak (bv. L2) wys.
+* As fynere beheer benodig word, kan ’n entiteit op een vlak (bv. L1) na ’n **child page table** op die volgende vlak (bv. L2) wys.

-#### Example: Mapping a Virtual Address
+#### Voorbeeld: Mapping van ’n Virtuele Adres

 Kom ons sê jy probeer toegang kry tot die virtuele adres **0x1000000000**:

 1. **L1 Table**:
-* Die kernel kyk na die L1 page table inskrywing wat ooreenstem met hierdie virtuele adres. As dit 'n **pointer to an L2 page table** het, gaan dit na daardie L2-table.
+* Die kernel kyk die L1 bladsytabel-entiteit na wat ooreenstem met hierdie virtuele adres. As dit ’n **pointer to an L2 page table** het, gaan dit na daardie L2-tabel.
 2. **L2 Table**:
-* Die kernel kyk die L2 page table na vir 'n meer gedetailleerde mapping. As hierdie inskrywing na 'n **L3 page table** wys, gaan dit verder daarheen.
+* Die kernel kyk die L2 bladsytabel vir ’n meer gedetailleerde mapping. As hierdie entiteit na ’n **L3 page table** wys, gaan dit verder daarheen.
 3. **L3 Table**:
-* Die kernel soek die finale L3-inskrywing, wat na die **physical address** van die werklike geheuebladsy wys.
+* Die kernel soek die finale L3-entiteit, wat na die **physical address** van die werklike geheuebladsy wys.

-#### Example of Address Mapping
+#### Voorbeeld van adres-mapping

-As jy die fisiese adres **0x800004000** in die eerste indeks van die L2-table skryf, dan:
+As jy die fisiese adres **0x800004000** in die eerste indeks van die L2-tabel skryf, dan:

 * Virtuele adresse van **0x1000000000** tot **0x1002000000** map na fisiese adresse van **0x800004000** tot **0x802004000**.
-* Dit is 'n **block mapping** op die L2-vlak.
+* Dit is ’n **block mapping** op die L2-vlak.

-Alternatiewelik, as die L2-inskrywing na 'n L3-table wys:
+Alternatiewelik, as die L2-entiteit na ’n L3-tabel wys:

-* Elke 4 KB-bladsy in die virtuele adresreeks **0x1000000000 -> 0x1002000000** sou deur individuele inskrywings in die L3-table gemap word.
+* Elke 4 KB bladsy in die virtuele adresreeks **0x1000000000 -> 0x1002000000** sou deur individuele entiteite in die L3-tabel gemap word.

 ### Physical use-after-free

-'N **physical use-after-free** (UAF) gebeur wanneer:
+’n **Physical use-after-free (UAF)** gebeur wanneer:

-1. 'n proses sekere geheue **alloceer** as **leesbaar en skryfbaar**.
-2. Die **page tables** word opgedateer om hierdie geheue na 'n spesifieke fisiese adres te map wat die proses kan benader.
-3. Die proses **dealloceer** (vrylaat) die geheue.
-4. Weens 'n **fout**, vergeet die kernel om die mapping uit die page tables te verwyder, selfs al merk dit die ooreenstemmende fisiese geheue as vry.
-5. Die kernel kan dan hierdie “vrygemaakte” fisiese geheue weer **herallokeer** vir ander doeleindes, soos **kernel data**.
-6. Aangesien die mapping nie verwyder is nie, kan die proses steeds na hierdie fisiese geheue **lees en skryf**.
+1. ’n proses iets geheue **allocates** as **readable and writable**.
+2. Die **page tables** word opgedateer om hierdie geheue na ’n spesifieke fisiese adres te map wat die proses kan benader.
+3. Die proses **deallocates** (free) die geheue.
+4. Vanweë ’n **bug**, vergeet die kernel egter om die mapping uit die page tables te verwyder, al merk dit die ooreenstemmende fisiese geheue as vry.
+5. Die kernel kan dan hierdie “vrygestelde” fisiese geheue **reallocate** vir ander doeleindes, soos **kernel data**.
+6. Aangesien die mapping nie verwyder is nie, kan die proses steeds **read en write** na hierdie fisiese geheue.

-Dit beteken die proses kan toegang tot **bladsye van kernel-geheue** kry, wat sensitiewe data of strukture kan bevat, en moontlik 'n aanvaller toelaat om **kernel memory** te manipuleer.
+Dit beteken die proses kan toegang kry tot **bladsye van kernel geheue**, wat sensitiewe data of strukture kan bevat, en moontlik ’n aanvaller toelaat om **kernel geheue te manipuleer**.

 ### IOSurface Heap Spray

-Aangesien die aanvaller nie kan beheer watter bepaalde kernel-bladsye aan vrygemaakte geheue toegewys sal word nie, gebruik hulle 'n tegniek genaamd **heap spray**:
+Aangesien die aanvaller nie die spesifieke kernel-bladsye wat aan vrygestelde geheue toegeken sal word kan beheer nie, gebruik hulle ’n tegniek genoem **heap spray**:

-1. Die aanvaller **skep 'n groot aantal IOSurface objects** in kernel-geheue.
-2. Elke IOSurface-object bevat 'n **magic value** in een van sy velde, wat dit maklik maak om te identifiseer.
-3. Hulle **skandeer die vrygemaakte bladsye** om te sien of enige van hierdie IOSurface-objekte op 'n vrygemaakte bladsy geland het.
-4. Wanneer hulle 'n IOSurface-object op 'n vrygemaakte bladsy vind, kan hulle dit gebruik om **kernel memory** te lees en te skryf.
+1. Die aanvaller skep ’n groot aantal IOSurface objects in kernel-geheue.
+2. Elke IOSurface object bevat ’n **magic value** in een van sy velde, wat dit maklik maak om te identifiseer.
+3. Hulle **scan die vrygestelde bladsye** om te kyk of enige van hierdie IOSurface objects op ’n vrygestelde bladsy beland het.
+4. Wanneer hulle ’n IOSurface object op ’n vrygestelde bladsy vind, kan hulle dit gebruik om **kernel geheue te lees en te skryf**.

-Meer inligting daaroor by [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
+More info about this in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)

 > [!TIP]
-> Wees bewus dat iOS 16+ (A12+) toestelle hardeware-mitigasies bring (soos PPL of SPTM) wat physical UAF-tegnieke baie minder uitvoerbaar maak.
-> PPL handhaaf streng MMU-beskerming op bladsye wat verband hou met code signing, entitlements, en sensitiewe kernel-data, so selfs as 'n bladsy weer gebruik word, word skrywe vanaf userland of gekompromitteerde kernel-kode na PPL-beskermde bladsye geblokkeer.
-> Secure Page Table Monitor (SPTM) brei PPL uit deur page table updates self te verharden. Dit verseker dat selfs bevoorregte kernel-kode nie stilweg vrygemaakte bladsye kan herkaart of mappings kan manipuleer sonder om deur sekure kontrole te gaan nie.
-> KTRR (Kernel Text Read-Only Region) vergrendel die kernel se code-afdeling as read-only na opstart. Dit voorkom enige runtime-wysigings aan kernel-kode en sluit 'n groot aanvalsvlak af waarop physical UAF-exploits dikwels staatmaak.
-> Boonop is `IOSurface`-allokasies minder voorspelbaar en moeiliker om in user-accessible streke te map, wat die “magic value scanning”-truuk minder betroubaar maak. En `IOSurface` word nou ook deur entitlements en sandbox-restriksies beskerm.
+> Wees bewus dat iOS 16+ (A12+) devices hardware-mitigations (soos PPL of SPTM) meebring wat physical UAF-tegnieke baie minder uitvoerbaar maak.
+> PPL dwing streng MMU-beskermings af op bladsye wat verband hou met code signing, entitlements, en sensitiewe kernel-data, so selfs as ’n bladsy hergebruik word, word skrywe vanaf userland of gekompromitteerde kernel-kode na PPL-beskermde bladsye geblokkeer.
+> Secure Page Table Monitor (SPTM) brei PPL uit deur page table updates self te verskerp. Dit verseker dat selfs bevoorregte kernel-kode nie stilweg vrygestelde bladsye kan herkaart of mappings kan manipuleer sonder om deur veilige kontroles te gaan nie.
+> KTRR (Kernel Text Read-Only Region) sluit die kernel se kodeafdeling as read-only na boot. Dit verhoed enige runtime-wysigings aan kernel-kode, wat ’n groot aanvalsvlak sluit waarop physical UAF-exploits dikwels staatmaak.
+> Verder is IOSurface-allocations minder voorspelbaar en moeiliker om na user-accessible streke te map, wat die “magic value scanning” truuk baie minder betroubaar maak. En IOSurface is nou beveilig deur entitlements en sandbox-beperkings.

 ### Step-by-Step Heap Spray Process

-1. **Spray IOSurface Objects**: Die aanvaller skep baie IOSurface-objekte met 'n spesiale identifiseerder ("magic value").
-2. **Scan Freed Pages**: Hulle kyk of enige van die objekte op 'n vrygemaakte bladsy toegeken is.
-3. **Read/Write Kernel Memory**: Deur velde in die IOSurface-object te manipuleer, verkry hulle die vermoë om **arbitrary reads and writes** in kernel-geheue uit te voer. Dit laat hulle toe om:
+1. **Spray IOSurface Objects**: Die aanvaller skep baie IOSurface objects met ’n spesiale identifiseerder ("magic value").
+2. **Scan Freed Pages**: Hulle kontroleer of enige van die objects op ’n vrygestelde bladsy toegeken is.
+3. **Read/Write Kernel Memory**: Deur velde in die IOSurface object te manipuleer, kry hulle die vermoë om **arbitrary reads and writes** in kernel-geheue uit te voer. Dit laat hulle toe om:
 * Een veld te gebruik om **enige 32-bit waarde** in kernel-geheue te lees.
-* 'n Ander veld te gebruik om **64-bit waardes** te skryf, en sodoende 'n stabiele **kernel read/write primitive** te bereik.
+* ’n Ander veld te gebruik om **64-bit waardes** te skryf, wat ’n stabiele **kernel read/write primitive** bewerkstellig.

-Genereer IOSurface objects met die magic value IOSURFACE\_MAGIC om later daarna te soek:
+Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for:
 ```c
 void spray_iosurface(io_connect_t client, int nSurfaces, io_connect_t **clients, int *nClients) {
 if (*nClients >= 0x4000) return;
@ -114,7 +128,7 @@ io_connect_t id = result.surface_id;
 }
 }
 ```
-Soek na **`IOSurface`**-voorwerpe in 'n vrygestelde fisiese bladsy:
+Soek na **`IOSurface`** voorwerpe in 'n bevryde fisiese bladsy:
 ```c
 int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) {
 io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000);
@ -148,25 +162,25 @@ free(surfaceIDs);
 return 0;
 }
 ```
-### Bereiking van Kernel Read/Write met IOSurface
+### Bereik Kernel Lees/Skryf met IOSurface

-Nadat ons beheer oor 'n IOSurface-object in kernel memory bereik het (gemapped na 'n vrygestelde fisiese bladsy wat vanaf userspace toeganklik is), kan ons dit gebruik vir **arbitrary kernel read and write operations**.
+Nadat beheer oor 'n IOSurface-objek in kernel-geheue bereik is (gemap na 'n vrygemaakte fisiese bladsy wat vanaf userspace toeganklik is), kan ons dit gebruik vir **arbitrêre kernel lees- en skryf-operasies**.

-**Key Fields in IOSurface**
+**Belangrike velde in IOSurface**

-Die IOSurface-object het twee belangrike velde:
+Die IOSurface-objek het twee beslissende velde:

-1. **Use Count Pointer**: Maak 'n **32-bit read** moontlik.
-2. **Indexed Timestamp Pointer**: Maak 'n **64-bit write** moontlik.
+1. **Use Count Pointer**: Laat 'n **32-bit lees** toe.
+2. **Indexed Timestamp Pointer**: Laat 'n **64-bit skryf** toe.

-Deur hierdie pointers oor te skryf, herlei ons hulle na willekeurige adresse in kernel memory en skep ons read/write-vermoëns.
+Deur hierdie pointers te oorskryf, herlei ons hulle na arbitrêre adresse in kernel-geheue, wat lees-/skryfvermoëns moontlik maak.

-#### 32-Bit Kernel Read
+#### 32-Bit Kernel Lees

-Om 'n read uit te voer:
+Om 'n lees uit te voer:

-1. Oorskryf die **use count pointer** sodat dit na die teikenadres minus 'n 0x14-byte offset wys.
-2. Gebruik die `get_use_count`-metode om die waarde by daardie adres te read.
+1. Oorskryf die **use count pointer** sodat dit na die teikenadres wys minus 'n 0x14-byte offset.
+2. Gebruik die `get_use_count` method om die waarde by daardie adres te lees.
 ```c
 uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
 uint64_t args[1] = {surfaceID};
@ -184,12 +198,12 @@ iosurface_set_use_count_pointer(info.object, orig);
 return value;
 }
 ```
-#### 64-bis kernskryf
+#### 64-Bit Kernel Write

-Om 'n skryf uit te voer:
+Om 'n skrywing uit te voer:

 1. Oorskryf die **indexed timestamp pointer** na die teikenadres.
-2. Gebruik die `set_indexed_timestamp` metode om 'n 64-bis waarde te skryf.
+2. Gebruik die `set_indexed_timestamp` metode om 'n 64-bit waarde te skryf.
 ```c
 void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
 uint64_t args[3] = {surfaceID, 0, value};
@ -203,13 +217,13 @@ set_indexed_timestamp(info.client, info.surface, value);
 iosurface_set_indexed_timestamp_pointer(info.object, orig);
 }
 ```
-#### Exploit Flow Opsomming
+#### Opsomming van die Exploit-vloei

 1. **Trigger Physical Use-After-Free**: Vrye bladsye is beskikbaar vir hergebruik.
 2. **Spray IOSurface Objects**: Ken baie IOSurface objects toe met 'n unieke "magic value" in kernel memory.
-3. **Identify Accessible IOSurface**: Lokaliseer 'n IOSurface op 'n vrygestelde bladsy wat jy beheer.
-4. **Abuse Use-After-Free**: Wysig pointers in die IOSurface object om arbitrêre **kernel read/write** via IOSurface methods moontlik te maak.
+3. **Identify Accessible IOSurface**: Vind 'n IOSurface op 'n vrygemaakte bladsy wat jy beheer.
+4. **Abuse Use-After-Free**: Wysig pointere in die IOSurface object om arbitrêre **kernel read/write** via IOSurface-metodes moontlik te maak.

-Met hierdie primitives verskaf die exploit beheerde **32-bit reads** en **64-bit writes** na kernel memory. Verdere jailbreak-stappe kan meer stabiele read/write primitives vereis, wat die omseiling van addisionele beskermings mag insluit (bv. PPL op nuwer arm64e-toestelle).
+Met hierdie primitiewe voorsien die exploit beheerde **32-bit reads** en **64-bit writes** na kernel memory. Verdere jailbreak-stappe kan meer stabiele read/write-primitiewe vereis, wat die omseiling van addisionele beskermings kan benodig (bv. PPL op nuwer arm64e-toestelle).

 {{#include ../../banners/hacktricks-training.md}}
--- a/src/generic-methodologies-and-resources/phishing-methodology/detecting-phising.md
+++ b/src/generic-methodologies-and-resources/phishing-methodology/detecting-phising.md
@ -1,69 +1,147 @@
-# Phishing Opsporing
+# Opsporing van phishing

 {{#include ../../banners/hacktricks-training.md}}

 ## Inleiding

-Om 'n phishing poging te kan opspoor, is dit belangrik om die **phishing tegnieke wat vandag gebruik word te verstaan**. Op die ouer bladsy van hierdie pos kan jy hierdie inligting vind, so as jy nie bewus is van watter tegnieke vandag gebruik word nie, beveel ek aan dat jy na die ouer bladsy gaan en ten minste daardie afdeling lees.
+Om 'n phishing-poging op te spoor is dit belangrik om die phishing-tegnieke wat deesdae gebruik word, te verstaan. Op die ouerbladsy van hierdie pos kan jy hierdie inligting vind, so as jy nie bewus is van watter tegnieke vandag gebruik word nie, beveel ek aan dat jy na die ouerbladsy gaan en ten minste daardie afdeling lees.

-Hierdie pos is gebaseer op die idee dat die **aanvallers op een of ander manier die slagoffer se domeinnaam sal probeer naboots of gebruik**. As jou domein `example.com` genoem word en jy gephish word met 'n heeltemal ander domeinnaam om een of ander rede soos `youwonthelottery.com`, sal hierdie tegnieke dit nie ontdek nie.
+Hierdie pos is gebaseer op die idee dat die **aanvallers op een of ander manier die slagoffer se domeinnaam sal naboots of gebruik**. As jou domein `example.com` is en 'n phishing-aanval 'n heeltemal ander domeinnaam soos `youwonthelottery.com` gebruik, gaan hierdie tegnieke dit nie ontdek nie.

-## Domeinnaam variasies
+## Domeinnaamvariasies

-Dit is **redelik maklik** om die **phishing** pogings wat 'n **soortgelyke domein** naam in die e-pos gebruik, te **ontdek**.\
-Dit is genoeg om 'n **lys van die mees waarskynlike phishing name** wat 'n aanvaller mag gebruik te **genereer** en te **kontroleer** of dit ** geregistreer** is of net te kyk of daar enige **IP** is wat dit gebruik.
+Dit is redelik **maklik** om daardie **phishing**-pogings wat 'n **soortgelyke domeinnaam** binne die e-pos gebruik, te **ontdek**.\
+Dit is genoeg om **'n lys te genereer van die mees waarskynlike phishing-name** wat 'n aanvaller mag gebruik en te **kontroleer** of dit **geregistreer** is, of net te kyk of daar enige **IP** is wat dit gebruik.

-### Vind verdagte domeine
+### Om verdagte domeine te vind

-Vir hierdie doel kan jy enige van die volgende gereedskap gebruik. Let daarop dat hierdie gereedskap ook DNS versoeke outomaties sal uitvoer om te kyk of die domein enige IP aan toegeken het:
+Vir hierdie doel kan jy enige van die volgende tools gebruik. Let wel dat hierdie tools ook DNS-versoeke outomaties sal doen om te kontroleer of die domein aan enige IP toegewys is:

 - [**dnstwist**](https://github.com/elceef/dnstwist)
 - [**urlcrazy**](https://github.com/urbanadventurer/urlcrazy)

+Tip: As jy 'n kandidaatlys genereer, voer dit ook in jou DNS-resolver logs in om **NXDOMAIN-opvraginge van binne jou org** op te spoor (gebruikers wat probeer 'n tikfout bereik voordat die aanvaller dit registreer). Sinkhole of pre-block hierdie domeine as beleid dit toelaat.
+
 ### Bitflipping

-**Jy kan 'n kort verduideliking van hierdie tegniek op die ouer bladsy vind. Of lees die oorspronklike navorsing in** [**https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/**](https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/)
+**Jy kan 'n kort verduideliking van hierdie tegniek op die ouerbladsy vind. Of lees die oorspronklike navorsing by** [**https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/**](https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/)

-Byvoorbeeld, 'n 1 bit verandering in die domein microsoft.com kan dit in _windnws.com_ omskep.\
-**Aanvallers mag soveel bit-flipping domeine registreer as moontlik wat met die slagoffer verband hou om wettige gebruikers na hul infrastruktuur te herlei**.
+Byvoorbeeld, 'n 1-bit wysiging in die domein microsoft.com kan dit omskep in _windnws.com._\
+**Aanvallers mag soveel bit-flipping domeine as moontlik registreer wat met die slagoffer verband hou om geldige gebruikers na hulle infrastruktuur te herlei.**

-**Alle moontlike bit-flipping domeinnames moet ook gemonitor word.**
+**Alle moontlike bit-flipping domeinnaam moet ook gemonitor word.**

-### Basiese kontroles
+As jy ook homoglyph/IDN lookalikes (bv. die meng van Latin/Cyrilliese karakters) in ag moet neem, kyk:

-Sodra jy 'n lys van potensieel verdagte domeinnames het, moet jy hulle **kontroleer** (hoofsaaklik die poorte HTTP en HTTPS) om te **sien of hulle 'n aanmeldvorm gebruik wat soortgelyk is** aan iemand van die slagoffer se domein.\
-Jy kan ook poort 3333 kontroleer om te sien of dit oop is en 'n instance van `gophish` draai.\
-Dit is ook interessant om te weet **hoe oud elke ontdekte verdagte domein is**, hoe jonger dit is, hoe riskanter is dit.\
-Jy kan ook **skermskote** van die HTTP en/of HTTPS verdagte webblad kry om te sien of dit verdag is en in daardie geval **dit betree om 'n dieper kyk te neem**.
+{{#ref}}
+homograph-attacks.md
+{{#endref}}
+
+### Basiese kontrole
+
+Sodra jy 'n lys het van potensiële verdagte domeine moet jy hulle **kontroleer** (hoofsaaklik die poorte HTTP en HTTPS) om te **sien of hulle 'n aanmeldingsvorm gebruik soortgelyk aan dié van die slagoffer se domein**.\
+Jy kan ook poort 3333 nagaan om te sien of dit oop is en 'n instansie van `gophish` loop.\
+Dit is ook interessant om te weet **hoe oud elke ontdekte verdagte domein is**; hoe jonger dit is, hoe riskanter.\
+Jy kan ook **skermkiekies** van die HTTP en/of HTTPS verdagte webblad kry om te sien of dit verdag is en in daardie geval dit te besoek om 'n dieper ondersoek te doen.

 ### Gevorderde kontroles

-As jy 'n stap verder wil gaan, beveel ek aan dat jy **daardie verdagte domeine monitor en van tyd tot tyd meer soek** (elke dag? dit neem net 'n paar sekondes/minute). Jy moet ook die oop **poorte** van die verwante IP's **kontroleer** en **soek na instances van `gophish` of soortgelyke gereedskap** (ja, aanvallers maak ook foute) en **die HTTP en HTTPS webbladsye van die verdagte domeine en subdomeine monitor** om te sien of hulle enige aanmeldvorm van die slagoffer se webbladsye gekopieer het.\
-Om dit te **automateer**, beveel ek aan om 'n lys van aanmeldvorms van die slagoffer se domeine te hê, die verdagte webbladsye te spinn en elke aanmeldvorm wat in die verdagte domeine gevind word met elke aanmeldvorm van die slagoffer se domein te vergelyk met iets soos `ssdeep`.\
-As jy die aanmeldvorms van die verdagte domeine geleë het, kan jy probeer om **rommel geloofsbriewe te stuur** en **te kontroleer of dit jou na die slagoffer se domein herlei**.
+As jy 'n stap verder wil gaan, beveel ek aan dat jy daardie verdagte domeine monitor en af en toe (elke dag? dit neem net 'n paar sekondes/minute) vir meer soek. Jy moet ook die oop poorte van die verwante IP's nagaan en soek na instansies van `gophish` of soortgelyke tools (ja, aanvallers maak ook foute) en die HTTP en HTTPS webblaaie van die verdagte domeine en subdomeine monitor om te sien of hulle enige aanmeldingsvorm van die slagoffer se webblaaie gekopieer het.\
+Om dit te outomatiseer beveel ek aan om 'n lys aanmeldingsvorms van die slagoffer se domeine te hê, die verdagte webblaaie te spider en elke aanmeldingsvorm wat in die verdagte domeine gevind word te vergelyk met elke aanmeldingsvorm van die slagoffer se domein met iets soos `ssdeep`.\
+As jy die aanmeldingsvorms van die verdagte domeine gevind het, kan jy probeer om vals inlogbewyse te stuur en te kyk of dit jou na die slagoffer se domein herlei.

-## Domeinnames wat sleutelwoorde gebruik
+---

-Die ouer bladsy noem ook 'n domeinnaam variasie tegniek wat bestaan uit die **slagoffer se domeinnaam binne 'n groter domein te plaas** (bv. paypal-financial.com vir paypal.com).
+### Jag deur favicon en webvingerafdrukke (Shodan/ZoomEye/Censys)

-### Sertifikaat Deursigtigheid
+Baie phishing-kit hergebruik favicons van die handelsmerk wat hulle naboots. Internet-wye skandeerders bereken 'n MurmurHash3 van die base64-gekodeerde favicon. Jy kan die hash genereer en daarop pivot:

-Dit is nie moontlik om die vorige "Brute-Force" benadering te neem nie, maar dit is eintlik **moontlik om sulke phishing pogings te ontdek** ook danksy sertifikaat deursigtigheid. Elke keer as 'n sertifikaat deur 'n CA uitgereik word, word die besonderhede publiek gemaak. Dit beteken dat deur die sertifikaat deursigtigheid te lees of selfs dit te monitor, dit **moontlik is om domeine te vind wat 'n sleutelwoord in sy naam gebruik**. Byvoorbeeld, as 'n aanvaller 'n sertifikaat van [https://paypal-financial.com](https://paypal-financial.com) genereer, kan jy deur die sertifikaat te kyk die sleutelwoord "paypal" vind en weet dat 'n verdagte e-pos gebruik word.
+Python voorbeeld (mmh3):
+```python
+import base64, requests, mmh3
+url = "https://www.paypal.com/favicon.ico"  # change to your brand icon
+b64 = base64.encodebytes(requests.get(url, timeout=10).content)
+print(mmh3.hash(b64))  # e.g., 309020573
+```
+- Navraag op Shodan: `http.favicon.hash:309020573`
+- Met gereedskap: kyk na community tools soos favfreak om hashes en dorks vir Shodan/ZoomEye/Censys te genereer.

-Die pos [https://0xpatrik.com/phishing-domains/](https://0xpatrik.com/phishing-domains/) stel voor dat jy Censys kan gebruik om sertifikate wat 'n spesifieke sleutelwoord beïnvloed te soek en te filter volgens datum (slegs "nuwe" sertifikate) en volgens die CA-uitreiker "Let's Encrypt":
+Aantekeninge
+- Favicons word hergebruik; behandel treffers as leidrade en valideer inhoud en certs voordat jy optree.
+- Kombineer dit met domain-age en keyword heuristics vir beter presisie.
+
+### URL telemetry hunting (urlscan.io)
+
+`urlscan.io` stoor historiese skermskote, DOM, requests en TLS metadata van ingediende URLs. Jy kan soek na brand abuse en clones:
+
+Voorbeeld navrae (UI of API):
+- Vind lookalikes terwyl jy jou legit domeine uitsluit: `page.domain:(/.*yourbrand.*/ AND NOT yourbrand.com AND NOT www.yourbrand.com)`
+- Vind sites wat jou assets hotlink: `domain:yourbrand.com AND NOT page.domain:yourbrand.com`
+- Beperk tot onlangse resultate: voeg by `AND date:>now-7d`
+
+API voorbeeld:
+```bash
+# Search recent scans mentioning your brand
+curl -s 'https://urlscan.io/api/v1/search/?q=page.domain:(/.*yourbrand.*/%20AND%20NOT%20yourbrand.com)%20AND%20date:>now-7d' \
+-H 'API-Key: <YOUR_URLSCAN_KEY>' | jq '.results[].page.url'
+```
+From die JSON, pivot op:
+- `page.tlsIssuer`, `page.tlsValidFrom`, `page.tlsAgeDays` om baie nuwe certs vir lookalikes op te spoor
+- `task.source` waardes soos `certstream-suspicious` om bevindings aan CT monitoring te koppel
+
+### Domein ouderdom via RDAP (skripbaar)
+
+RDAP lewer masjienleesbare skeppingsgebeure. Nutig om **nuut geregistreerde domeine (NRDs)** te merk.
+```bash
+# .com/.net RDAP (Verisign)
+curl -s https://rdap.verisign.com/com/v1/domain/suspicious-example.com | \
+jq -r '.events[] | select(.eventAction=="registration") | .eventDate'
+
+# Generic helper using rdap.net redirector
+curl -s https://www.rdap.net/domain/suspicious-example.com | jq
+```
+Verryk jou pyllyn deur domeine te merk met registrasie-ouderdomsbuckets (bv., <7 dae, <30 dae) en prioritiseer triage daarvolgens.
+
+### TLS/JAx fingerprints to spot AiTM infrastructure
+
+Moderne credential-phishing gebruik toenemend **Adversary-in-the-Middle (AiTM)** reverse proxies (bv. Evilginx) om session tokens te steel. Jy kan netwerk-kant detectors toevoeg:
+
+- Log TLS/HTTP vingerafdrukke (JA3/JA4/JA4S/JA4H) by uitgaande verkeer. Sommige Evilginx-builds is waargeneem met stabiele JA4 kliënt/server-waardes. Gee waarskuwings slegs op bekend-slegte vingerafdrukke as 'n swak sein en bevestig altyd met inhoud- en domein-intel.
+- Neem proaktief TLS sertifikaat-metadata op (issuer, SAN count, wildcard gebruik, geldigheid) vir lookalike hosts wat via CT of urlscan ontdek is en korreleer dit met DNS-ouderdom en geolokalisasie.
+
+> Let wel: Behandel vingerafdrukke as verriking, nie as enkele blokkeerders nie; frameworks ontwikkel en kan randomiseer of obfuskeer.
+
+### Domain names using keywords
+
+Die ouerblad bespreek ook 'n domeinnaamvariasiemetode wat bestaan uit om die **slagoffer se domeinnaam binne 'n groter domein te plaas** (bv. paypal-financial.com vir paypal.com).
+
+#### Certificate Transparency
+
+Dit is nie moontlik om die vorige "Brute-Force" benadering te gebruik nie, maar dit is eintlik **moontlik om sulke phishing-pogings op te spoor** danksy Certificate Transparency. Elke keer as 'n sertifikaat deur 'n CA uitgegee word, word die besonderhede openbaar gemaak. Dit beteken dat deur die certificate transparency te lees of selfs te monitor, dit **moontlik is om domeine te vind wat 'n sleutelwoord in hul naam gebruik**. Byvoorbeeld, as 'n aanvaller 'n sertifikaat genereer vir [https://paypal-financial.com](https://paypal-financial.com), kan jy deur die sertifikaat die sleutelwoord "paypal" vind en weet dat 'n verdagte e-pos gebruik word.
+
+Die post [https://0xpatrik.com/phishing-domains/](https://0xpatrik.com/phishing-domains/) stel voor dat jy Censys kan gebruik om na sertifikate te soek wat 'n spesifieke sleutelwoord raak en te filter op datum (slegs "nuwe" sertifikate) en op die CA-uitreiker "Let's Encrypt":

 ![https://0xpatrik.com/content/images/2018/07/cert_listing.png](<../../images/image (1115).png>)

-Jy kan egter "die dieselfde" doen met die gratis web [**crt.sh**](https://crt.sh). Jy kan **soek na die sleutelwoord** en die **resultate filter** **volgens datum en CA** as jy wil.
+Jy kan egter "dieselfde" doen met die gratis web [**crt.sh**](https://crt.sh). Jy kan **soek na die sleutelwoord** en die resultate **filter** **per datum en CA** indien jy wil.

 ![](<../../images/image (519).png>)

-Met hierdie laaste opsie kan jy selfs die veld ooreenstemmende identiteite gebruik om te sien of enige identiteit van die werklike domein ooreenstem met enige van die verdagte domeine (let daarop dat 'n verdagte domein 'n vals positiewe kan wees).
+Met hierdie opsie kan jy selfs die veld Matching Identities gebruik om te sien of enige identiteit van die regte domein ooreenstem met enige van die verdagte domeine (let wel dat 'n verdagte domein 'n vals-positief kan wees).

-**Nog 'n alternatief** is die fantastiese projek genaamd [**CertStream**](https://medium.com/cali-dog-security/introducing-certstream-3fc13bb98067). CertStream bied 'n regte-tyd stroom van nuut gegenereerde sertifikate wat jy kan gebruik om gespesifiseerde sleutelwoorde in (naby) regte tyd te ontdek. Trouens, daar is 'n projek genaamd [**phishing_catcher**](https://github.com/x0rz/phishing_catcher) wat presies dit doen.
+**Nog 'n alternatief** is die fantastiese projek genaamd [**CertStream**](https://medium.com/cali-dog-security/introducing-certstream-3fc13bb98067). CertStream voorsien 'n real-time stroom van nuut gegenereerde sertifikate wat jy kan gebruik om gespesifiseerde sleutelwoorde in (naby) real-time te ontdek. Daar is eintlik 'n projek genaamd [**phishing_catcher**](https://github.com/x0rz/phishing_catcher) wat presies dit doen.

-### **Nuwe domeine**
+Praktiese wenk: wanneer jy CT-hits triageer, prioritiseer NRDs, onbetroubare/onbekende registrars, privacy-proxy WHOIS, en certs met baie onlangse `NotBefore`-tye. Handhaaf 'n allowlist van jou eie domeine/handelsmerke om geraas te verminder.

-**Een laaste alternatief** is om 'n lys van **nuut geregistreerde domeine** vir sommige TLD's te versamel ([Whoxy](https://www.whoxy.com/newly-registered-domains/) bied so 'n diens) en **die sleutelwoorde in hierdie domeine te kontroleer**. Dit is egter dat lang domeine gewoonlik een of meer subdomeine gebruik, daarom sal die sleutelwoord nie binne die FLD verskyn nie en jy sal nie in staat wees om die phishing subdomein te vind nie.
+#### **Nuwe domeine**
+
+**Een laaste alternatief** is om 'n lys te versamel van **nuut geregistreerde domeine** vir sommige TLDs ([Whoxy](https://www.whoxy.com/newly-registered-domains/) bied so 'n diens) en **kontroleer die sleutelwoorde in hierdie domeine**. Lang domeine gebruik egter gewoonlik een of meer subdomeine, daarom sal die sleutelwoord nie binne die FLD verskyn nie en sal jy nie die phishing-subdomein kan vind nie.
+
+Bykomende heuristiek: behandel sekere **file-extension TLDs** (bv. `.zip`, `.mov`) met ekstra agterdog in waarskuwings. Hierdie word dikwels verwar met lêernaam in lures; kombineer die TLD-sein met handelsmerk-sleutelwoorde en NRD-ouderdom vir beter presisie.
+
+## References
+
+- urlscan.io – Search API reference: https://urlscan.io/docs/search/
+- APNIC Blog – JA4+ network fingerprinting (includes Evilginx example): https://blog.apnic.net/2023/11/22/ja4-network-fingerprinting/

 {{#include ../../banners/hacktricks-training.md}}
--- a/theme/ht_searcher.js
+++ b/theme/ht_searcher.js
@ -24,13 +24,15 @@
    /* 2 — load a single index (remote → local) */
    async function loadIndex(remote, local, isCloud=false){
      let rawLoaded = false;
-      try {
-        const r = await fetch(remote,{mode:'cors'});
-        if (!r.ok) throw new Error('HTTP '+r.status);
-        importScripts(URL.createObjectURL(new Blob([await r.text()],{type:'application/javascript'})));
-        rawLoaded = true;
-      } catch(e){ console.warn('remote',remote,'failed →',e); }
-      if(!rawLoaded){
+      if(remote){
+        try {
+          const r = await fetch(remote,{mode:'cors'});
+          if (!r.ok) throw new Error('HTTP '+r.status);
+          importScripts(URL.createObjectURL(new Blob([await r.text()],{type:'application/javascript'})));
+          rawLoaded = true;
+        } catch(e){ console.warn('remote',remote,'failed →',e); }
+      }
+      if(!rawLoaded && local){
        try { importScripts(abs(local)); rawLoaded = true; }
        catch(e){ console.error('local',local,'failed →',e); }
      }
@ -40,13 +42,41 @@
      return data;
    }

+    async function loadWithFallback(remotes, local, isCloud=false){
+      if(remotes.length){
+        const [primary, ...secondary] = remotes;
+        const primaryData = await loadIndex(primary, null, isCloud);
+        if(primaryData) return primaryData;
+
+        if(local){
+          const localData = await loadIndex(null, local, isCloud);
+          if(localData) return localData;
+        }
+
+        for (const remote of secondary){
+          const data = await loadIndex(remote, null, isCloud);
+          if(data) return data;
+        }
+      }
+
+      return local ? loadIndex(null, local, isCloud) : null;
+    }
+
    (async () => {
-      const MAIN_RAW  = 'https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/refs/heads/master/searchindex.js';
-      const CLOUD_RAW = 'https://raw.githubusercontent.com/HackTricks-wiki/hacktricks-cloud/refs/heads/master/searchindex.js';
+      const htmlLang = (document.documentElement.lang || 'en').toLowerCase();
+      const lang = htmlLang.split('-')[0];
+      const mainReleaseBase = 'https://github.com/HackTricks-wiki/hacktricks/releases/download';
+      const cloudReleaseBase = 'https://github.com/HackTricks-wiki/hacktricks-cloud/releases/download';
+
+      const mainTags = Array.from(new Set([`searchindex-${lang}`, 'searchindex-en', 'searchindex-master']));
+      const cloudTags = Array.from(new Set([`searchindex-${lang}`, 'searchindex-en', 'searchindex-master']));
+
+      const MAIN_REMOTE_SOURCES  = mainTags.map(tag => `${mainReleaseBase}/${tag}/searchindex.js`);
+      const CLOUD_REMOTE_SOURCES = cloudTags.map(tag => `${cloudReleaseBase}/${tag}/searchindex.js`);

      const indices = [];
-      const main = await loadIndex(MAIN_RAW , '/searchindex.js',        false); if(main)  indices.push(main);
-      const cloud= await loadIndex(CLOUD_RAW, '/searchindex-cloud.js',  true ); if(cloud) indices.push(cloud);
+      const main = await loadWithFallback(MAIN_REMOTE_SOURCES , '/searchindex.js',        false); if(main)  indices.push(main);
+      const cloud= await loadWithFallback(CLOUD_REMOTE_SOURCES, '/searchindex-cloud.js',  true ); if(cloud) indices.push(cloud);

      if(!indices.length){ postMessage({ready:false, error:'no-index'}); return; }