Translated ['src/binary-exploitation/libc-heap/unsorted-bin-attack.md']

src/binary-exploitation/libc-heap/unsorted-bin-attack.md

@@ -1,55 +1,111 @@
-# Ongeordende Bin Aanval
+# Unsorted Bin Attack
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## Basiese Inligting
 
-Vir meer inligting oor wat 'n ongeordende bin is, kyk na hierdie bladsy:
+Vir meer inligting oor wat 'n unsorted bin is, kyk hierdie blad:
 
 {{#ref}}
 bins-and-memory-allocations.md
 {{#endref}}
 
-Ongeordende lyste kan die adres na `unsorted_chunks (av)` in die `bk` adres van die chunk skryf. Daarom, as 'n aanvaller die **adres van die `bk` pointer** in 'n chunk binne die ongeordende bin kan **wysig**, kan hy in staat wees om **daardie adres in 'n arbitrêre adres te skryf**, wat nuttig kan wees om 'n Glibc-adres te lek of om sekere verdediging te omseil.
+Unsorted lists is in staat om die adres van `unsorted_chunks (av)` te skryf in die `bk` adres van die chunk. Daarom, as 'n aanvaller die adres van die `bk` pointer in 'n chunk binne die unsorted bin kan **wysig**, kan hy daardie adres in 'n arbitrêre adres **skryf**, wat nuttig kan wees om Glibc addresses te leak of sekere verdediging te omseil.
 
-So, basies, laat hierdie aanval toe om **'n groot getal op 'n arbitrêre adres in te stel**. Hierdie groot getal is 'n adres, wat 'n heap adres of 'n Glibc adres kan wees. 'n Tipiese teiken is **`global_max_fast`** om vinnige binne met groter groottes te skep (en om van 'n ongeordende bin aanval na 'n vinnige bin aanval oor te gaan).
+Dus, basies laat hierdie aanval toe om **'n groot getal by 'n arbitrêre adres te stel**. Hierdie groot getal is 'n adres, wat 'n heap adres of 'n Glibc adres kan wees. 'n Tradisionele teiken was **`global_max_fast`** om toe te laat om fast bin bins met groter groottes te skep (en van 'n unsorted bin aanval na 'n fast bin aanval oor te gaan).
+
+- Moderne nota (glibc ≥ 2.39): `global_max_fast` het 'n 8‑bit globale geword. Blindelings 'n pointer daarheen skryf via 'n unsorted-bin write sal nabygeleë libc data beskadig en sal nie meer betroubaar die fastbin limiet optel nie. Verkies ander teikens of primitiewe wanneer jy teen glibc 2.39+ werk. Sien "Modern constraints" hieronder en oorweeg om te kombineer met ander tegnieke soos 'n [large bin attack](large-bin-attack.md) of 'n [fast bin attack](fast-bin-attack.md) eens jy 'n stabiele primitive het.
 
 > [!TIP]
-> T> kyk na die voorbeeld wat gegee is in [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle) en gebruik 0x4000 en 0x5000 in plaas van 0x400 en 0x500 as chunk groottes (om Tcache te vermy), dit is moontlik om te sien dat **vandag** die fout **`malloc(): unsorted double linked list corrupted`** geaktiveer word.
+> Neem 'n kyk na die voorbeeld in [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle) en deur 0x4000 en 0x5000 te gebruik in plaas van 0x400 en 0x500 as chunk groottes (om Tcache te vermy) is dit moontlik om te sien dat **deesdae** die fout **`malloc(): unsorted double linked list corrupted`** getrigger word.
 >
-> Daarom, hierdie ongeordende bin aanval vereis nou (benewens ander kontroles) ook om in staat te wees om die dubbele gekoppelde lys reg te stel sodat dit `victim->bk->fd == victim` of nie `victim->fd == av (arena)` omseil nie, wat beteken dat die adres waar ons wil skryf die adres van die valse chunk in sy `fd` posisie moet hê en dat die valse chunk `fd` na die arena wys.
+> Daarom vereis hierdie unsorted bin aanval nou (onder andere kontroles) ook dat jy die dubbelgekoppelde lys kan herstel sodat dit nie hierdie fout veroorsaak nie — byvoorbeeld `victim->bk->fd == victim` of `victim->fd == av (arena)` moet voldoen — wat beteken dat die adres waarheen ons wil skryf die adres van die vals chunk in sy `fd` posisie moet hê en dat die vals chunk se `fd` na die arena verwys.
 
-> [!WAARSKUWING]
-> Let daarop dat hierdie aanval die ongeordende bin korrupteer (daarom klein en groot ook). So ons kan slegs **toewysings van die vinnige bin nou gebruik** ( 'n meer komplekse program mag ander toewysings doen en crash), en om dit te aktiveer moet ons **die dieselfde grootte toewys of die program sal crash.**
+> [!CAUTION]
+> Let daarop dat hierdie aanval die unsorted bin korrupteer (dus ook small en large). Ons kan dus slegs nou **allerlei toewysings uit die fast bin gebruik** ('n meer komplekse program mag ander toewysings doen en crash), en om dit te trigger moet ons **dieselfde grootte toewys — anders sal die program crash.**
 >
-> Let daarop dat om **`global_max_fast`** te oorskry in hierdie geval kan help, vertrou dat die vinnige bin in staat sal wees om al die ander toewysings te hanteer totdat die uitbuiting voltooi is.
+> Oorskrywing van **`global_max_fast`** kan in hierdie geval help in die veronderstelling dat die fast bin al die ander toewysings kan hanteer totdat die exploit voltooi is.
 
-Die kode van [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) verduidelik dit baie goed, alhoewel as jy die mallocs aanpas om genoeg geheue toe te ken sodat dit nie in 'n Tcache eindig nie, kan jy sien dat die voorheen genoemde fout voorkom wat hierdie tegniek voorkom: **`malloc(): unsorted double linked list corrupted`**
+Die kode van [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) verduidelik dit baie goed, alhoewel as jy die mallocs verander om geheue groot genoeg toe te ken sodat dit nie in 'n Tcache eindig nie, kan jy sien dat die vroeër genoemde fout verskyn wat hierdie tegniek verhoed: **`malloc(): unsorted double linked list corrupted`**
 
-## Ongeordende Bin Inligtingslek Aanval
+### Hoe die skryf werklik gebeur
 
-Dit is eintlik 'n baie basiese konsep. Die chunks in die ongeordende bin gaan pointers hê. Die eerste chunk in die ongeordende bin sal eintlik die **`fd`** en die **`bk`** skakels hê **wat na 'n deel van die hoof arena (Glibc)** wys.\
-Daarom, as jy **'n chunk binne 'n ongeordende bin kan plaas en dit kan lees** (gebruik na vry) of **dit weer kan toewys sonder om ten minste 1 van die pointers te oorskry** om dan **dit te lees**, kan jy 'n **Glibc inligtingslek** hê.
+- Die unsorted-bin skryf word geaktiveer tydens `free` wanneer die bevryde chunk by die kop van die unsorted lys geplaas word.
+- Tydens invoeging voer die allocator uit: `bck = unsorted_chunks(av); fwd = bck->fd; victim->bk = bck; victim->fd = fwd; fwd->bk = victim; bck->fd = victim;`
+- As jy `victim->bk` kan stel na `(mchunkptr)(TARGET - 0x10)` voordat jy `free(victim)` aanroep, sal die finale stelling die skryf uitvoer: `*(TARGET) = victim`.
+- Later, wanneer die allocator die unsorted bin verwerk, sal integriteitskontroles (onder andere) verifieer dat `bck->fd == victim` en `victim->fd == unsorted_chunks(av)` voordat dit unlink. Omdat die invoeging reeds `victim` in `bck->fd` (ons `TARGET`) geskryf het, kan hierdie kontroles bevredig word as die skryf suksesvol was.
 
-'n Soortgelyke [**aanval wat in hierdie skrywe gebruik is**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html), was om 'n 4 chunks struktuur (A, B, C en D - D is slegs om konsolidasie met die boonste chunk te voorkom) te misbruik, sodat 'n null byte oorgang in B gebruik is om C aan te dui dat B nie gebruik is nie. Ook, in B is die `prev_size` data gewysig sodat die grootte in plaas van die grootte van B A+B was.\
-Toe is C vrygestel, en met A+B gekonsolideer (maar B was steeds in gebruik). 'n Nuwe chunk van grootte A is toegeken en toe is die libc gelekte adresse in B geskryf waarvandaan hulle gelek is.
+## Moderne beperkings (glibc ≥ 2.33)
+
+Om unsorted‑bin skrywe betroubaar op huidige glibc te gebruik:
+
+- Tcache inmenging: vir groottes wat in tcache val, word frees daarheen omgeleid en raak nie die unsorted bin nie. Of
+  - maak versoeke met groottes > MAX_TCACHE_SIZE (≥ 0x410 op 64‑bit standaard), of
+  - vul die ooreenstemmende tcache bin (7 inskrywings) sodat addisionele frees by die global bins uitkom, of
+  - as die omgewing beheerbaar is, deaktiveer tcache (bv. GLIBC_TUNABLES glibc.malloc.tcache_count=0).
+- Integriteitskontroles op die unsorted lys: op die volgende allocasie-pad wat die unsorted bin ondersoek, kontroleer glibc (vereenvoudig):
+  - `bck->fd == victim` en `victim->fd == unsorted_chunks(av)`; anders abort dit met `malloc(): unsorted double linked list corrupted`.
+- Dit beteken die adres wat jy teiken moet twee skrywe verdra: eers `*(TARGET) = victim` tydens free; later, wanneer die chunk verwyder word, `*(TARGET) = unsorted_chunks(av)` (die allocator skryf `bck->fd` terug na die binkop). Kies teikens waar dit nuttig is om bloot 'n groot nie‑nul waarde af te dwing.
+- Tipiese stabiele teikens in moderne exploits
+  - Aansoek- of globale toestand wat "groot" waardes as vlae/limiete behandel.
+  - Indirekte primitiewe (bv. opstel vir 'n volgende [fast bin attack]({{#ref}}fast-bin-attack.md{{#endref}}) of om 'n latere write‐what‐where te pivot).
+  - Vermy `__malloc_hook`/`__free_hook` op nuwe glibc: dit is verwyder in 2.34. Vermy `global_max_fast` op ≥ 2.39 (sien vorige nota).
+- Oor `global_max_fast` op onlangse glibc
+  - Op glibc 2.39+ is `global_max_fast` 'n 8‑bit globale. Die klassieke truuk om 'n heap pointer daarin te skryf (om fastbins te vergroot) werk nie meer netjies nie en sal waarskynlik nabygeleë allocator toestand beskadig. Verkies ander strategieë.
+
+## Minimale uitbuiting resep (moderne glibc)
+
+Doel: bereik 'n enkele arbitrêre skryf van 'n heap pointer na 'n arbitrêre adres deur gebruik van die unsorted‑bin invoegingsprimitive, sonder om te crash.
+
+- Layout/voorbereiding
+  - Allocate A, B, C met groottes groot genoeg om tcache te omseil (bv. 0x5000). C voorkom konsolidasie met die top chunk.
+- Korrupsie
+  - Overflow van A in B se chunk header om `B->bk = (mchunkptr)(TARGET - 0x10)` te stel.
+- Aktivering
+  - `free(B)`. Tydens invoeging voer die allocator `bck->fd = B` uit, dus `*(TARGET) = B`.
+- Voortsetting
+  - As jy beplan om voort te gaan met toewysings en die program die unsorted bin gebruik, verwag dat die allocator later `*(TARGET) = unsorted_chunks(av)` sal stel. Albei waardes is tipies groot en kan genoeg wees om grootte/limiet semantiek in teikens wat slegs vir "groot" check, te verander.
+
+Pseudocode skeleton:
+```c
+// 64-bit glibc 2.35–2.38 style layout (tcache bypass via large sizes)
+void *A = malloc(0x5000);
+void *B = malloc(0x5000);
+void *C = malloc(0x5000); // guard
+
+// overflow from A into B’s metadata (prev_size/size/.../bk). You must control B->bk.
+*(size_t *)((char*)B - 0x8) = (size_t)(TARGET - 0x10); // write fake bk
+
+free(B); // triggers *(TARGET) = B (unsorted-bin insertion write)
+```
+> [!NOTE]
+> • As jy nie tcache met grootte kan omseil nie, vul die tcache bin vir die gekose grootte (7 frees) voordat jy die gekorrupte chunk vrylaat sodat die free na unsorted gaan.
+> • As die program onmiddellik op die volgende allocation abort weens unsorted-bin checks, ondersoek weer of `victim->fd` steeds gelyk is aan die bin head en dat jou `TARGET` die presiese `victim` pointer bevat na die eerste write.
+
+## Unsorted Bin Infoleak Attack
+
+Dit is eintlik 'n baie basiese konsep. Die chunks in die unsorted bin gaan pointers hê. Die eerste chunk in die unsorted bin sal eintlik die **`fd`** en die **`bk`** links hê wat **wys na 'n deel van die main arena (Glibc)**.\
+Daarom, as jy **'n chunk in 'n unsorted bin kan sit en dit read** (use after free) of **dit weer kan allocate sonder om minstens een van die pointers oor te skryf** om dit daarna te **read**, kan jy 'n **Glibc info leak** hê.
+
+A similar [**attack used in this writeup**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html), was om 'n struktuur van 4 chunks (A, B, C en D - D is slegs om konsolidasie met die top chunk te voorkom) te misbruik, sodat 'n null byte overflow in B gebruik is om C te laat aandui dat B ongebruik was. Ook is in B die `prev_size` data gewysig sodat die grootte, in plaas daarvan om die grootte van B te wees, A+B was.\
+Daarna is C gedelf en gekonsolideer met A+B (maar B was steeds in gebruik). 'n Nuwe chunk van grootte A is gealloceer en toe is die libc leaked addresses in B geskryf vanwaar hulle geleak is.
 
 ## Verwysings & Ander voorbeelde
 
 - [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap)
-- Die doel is om 'n globale veranderlike met 'n waarde groter as 4869 te oorskry sodat dit moontlik is om die vlag te kry en PIE is nie geaktiveer nie.
-- Dit is moontlik om chunks van arbitrêre groottes te genereer en daar is 'n heap oorgang met die gewenste grootte.
-- Die aanval begin deur 3 chunks te skep: chunk0 om die oorgang te misbruik, chunk1 om oorgestroom te word en chunk2 sodat die boonste chunk nie die vorige een konsolideer nie.
-- Toe, chunk1 word vrygestel en chunk0 word oorgestroom sodat die `bk` pointer van chunk1 wys na: `bk = magic - 0x10`
-- Toe, chunk3 word toegeken met dieselfde grootte as chunk1, wat die ongeordende bin aanval sal aktiveer en die waarde van die globale veranderlike sal wysig, wat dit moontlik maak om die vlag te kry.
+- Die doel is om 'n globale veranderlike oor te skryf met 'n waarde groter as 4869 sodat dit moontlik is om die vlag te kry en PIE is nie aangeskakel nie.
+- Dit is moontlik om chunks van ewekansige groottes te genereer en daar is 'n heap overflow met die verlangde grootte.
+- Die aanval begin deur 3 chunks te skep: chunk0 om die overflow te misbruik, chunk1 om oorloop te word en chunk2 sodat die top chunk nie die vorige eenhede konsolideer nie.
+- Daarna word chunk1 vrygestel en chunk0 word oorloop na die `bk` pointer waarheen chunk1 wys: `bk = magic - 0x10`
+- Dan word chunk3 gealloceer met dieselfde grootte as chunk1, wat die unsorted bin attack sal aktiveer en die waarde van die globale veranderlike sal wysig, wat dit moontlik maak om die vlag te kry.
 - [**https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html**](https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html)
-- Die merge funksie is kwesbaar omdat as beide indekse wat oorgedra word dieselfde is, dit op dit sal heraansluit en dan vry sal stel, maar 'n pointer na daardie vrygestelde streek sal teruggee wat gebruik kan word.
-- Daarom, **2 chunks word geskep**: **chunk0** wat met homself saamgevoeg sal word en chunk1 om te voorkom dat dit met die boonste chunk konsolideer. Toe, die **merge funksie word met chunk0** twee keer aangeroep wat 'n gebruik na vry sal veroorsaak.
-- Toe, die **`view`** funksie word met indeks 2 (wat die indeks van die gebruik na vry chunk is) aangeroep, wat 'n **libc adres sal lek**.
-- Aangesien die binêre beskermings het om slegs malloc groottes groter as **`global_max_fast`** toe te laat, sodat geen fastbin gebruik word nie, sal 'n ongeordende bin aanval gebruik word om die globale veranderlike `global_max_fast` te oorskry.
-- Toe, dit is moontlik om die edit funksie met die indeks 2 (die gebruik na vry pointer) aan te roep en die `bk` pointer te oorskry om na `p64(global_max_fast-0x10)` te wys. Toe, die skep van 'n nuwe chunk sal die voorheen gecompromitteerde vry adres (0x20) gebruik wat die **ongeordende bin aanval** sal aktiveer wat die `global_max_fast` oorskry met 'n baie groot waarde, wat nou die skep van chunks in vinnige bins moontlik maak.
-- Nou word 'n **vinnige bin aanval** uitgevoer:
-- Eerstens word ontdek dat dit moontlik is om met vinnige **chunks van grootte 200** in die **`__free_hook`** ligging te werk:
+- Die merge-funksie is kwesbaar omdat as albei indekse dieselfde is, dit op dit self gaan realloc en dan vrylaat maar 'n pointer na daardie vrygemaakte gebied teruggee wat gebruik kan word.
+- Daarom word **2 chunks geskep**: **chunk0** wat met homself en chunk1 gesmelt gaan word om konsolidasie met die top chunk te voorkom. Dan word die **merge** funksie met chunk0 twee keer aangeroep wat 'n use after free veroorsaak.
+- Daarna word die **`view`** funksie aangeroep met index 2 (die index van die use after free chunk), wat 'n libc address sal leak.
+- Aangesien die binary beskermings het om slegs te malloc groottes groter as **`global_max_fast`** te laat, sodat geen fastbin gebruik word nie, gaan 'n unsorted bin attack gebruik word om die globale veranderlike `global_max_fast` oor te skryf.
+- Dan is dit moontlik om die edit funksie te noem met index 2 (die use after free pointer) en die `bk` pointer oor te skryf om te wys na `p64(global_max_fast-0x10)`. Daarna sal die skepping van 'n nuwe chunk die voorheen gekompromitteerde free address (0x20) gebruik en **die unsorted bin attack** trigger wat `global_max_fast` oorskryf tot 'n baie groot waarde, wat nou toelaat om chunks in fast bins te skep.
+- Nou word 'n **fast bin attack** uitgevoer:
+- Eerstens is gevind dat dit moontlik is om met fast **chunks van grootte 200** in die **`__free_hook`** ligging te werk:
 - <pre class="language-c"><code class="lang-c">gef➤  p &__free_hook
 $1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
 gef➤  x/60gx 0x7ff1e9e607a8 - 0x59
@@ -58,16 +114,20 @@ gef➤  x/60gx 0x7ff1e9e607a8 - 0x59
 0x7ff1e9e6076f <list_all_lock+15>:      0x0000000000000000      0x0000000000000000
 0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000      0x0000000000000000
 </code></pre>
-- As ons daarin slaag om 'n vinnige chunk van grootte 0x200 in hierdie ligging te kry, sal dit moontlik wees om 'n funksie pointer te oorskry wat uitgevoer sal word.
-- Hiervoor word 'n nuwe chunk van grootte `0xfc` geskep en die saamgevoegde funksie word twee keer met daardie pointer aangeroep, sodat ons 'n pointer na 'n vrygestelde chunk van grootte `0xfc*2 = 0x1f8` in die vinnige bin verkry.
-- Toe, die edit funksie word in hierdie chunk aangeroep om die **`fd`** adres van hierdie vinnige bin te wys na die vorige **`__free_hook`** funksie.
-- Toe, 'n chunk met grootte `0x1f8` word geskep om die vorige nuttelose chunk uit die vinnige bin te verkry, sodat 'n ander chunk van grootte `0x1f8` geskep word om 'n vinnige bin chunk in die **`__free_hook`** te kry wat oorgeskryf word met die adres van die **`system`** funksie.
-- En uiteindelik word 'n chunk wat die string `/bin/sh\x00` bevat, vrygestel deur die delete funksie aan te roep, wat die **`__free_hook`** funksie aktiveer wat na system met `/bin/sh\x00` as parameter wys.
+- As ons 'n fast chunk van grootte 0x200 in hierdie ligging kan kry, sal dit moontlik wees om 'n function pointer oor te skryf wat uitgevoer gaan word.
+- Hiervoor word 'n nuwe chunk van grootte `0xfc` geskep en die merge funksie met daardie pointer twee keer aangeroep; op hierdie manier kry ons 'n pointer na 'n vrygemaakte chunk van grootte `0xfc*2 = 0x1f8` in die fast bin.
+- Dan word die edit funksie op hierdie chunk aangeroep om die **`fd`** adres van hierdie fast bin te wysig om na die vorige **`__free_hook`** funksie te wys.
+- Daarna word 'n chunk met grootte `0x1f8` geskep om die vorige nuttelose chunk uit die fast bin te haal en nog 'n chunk van grootte `0x1f8` gealloceer om 'n fast bin chunk in die **`__free_hook`** te kry wat oor geskryf word met die adres van die **`system`** funksie.
+- En uiteindelik word 'n chunk met die string `/bin/sh\x00` vrygestel deur die delete funksie aan te roep, wat die **`__free_hook`** funksie trigger wat na system wys met `/bin/sh\x00` as parameter.
 - **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html)
-- Nog 'n voorbeeld van die misbruik van 'n 1B oorgang om chunks in die ongeordende bin te konsolideer en 'n libc inligtingslek te kry en dan 'n vinnige bin aanval uit te voer om die malloc hook met 'n een gadget adres te oorskry.
+- Nog 'n voorbeeld van die misbruik van 'n 1B overflow om chunks in die unsorted bin te konsolideer en 'n libc infoleak te kry en dan 'n fast bin attack uit te voer om malloc hook met 'n one gadget adres te oor skryf
 - [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/)
-- Ons kan slegs chunks van grootte groter as `0x100` toewys.
-- Oorskry `global_max_fast` met 'n Ongeordende Bin aanval (werk 1/16 keer as gevolg van ASLR, omdat ons 12 bits moet wysig, maar ons moet 16 bits wysig).
-- Vinnige Bin aanval om 'n globale array van chunks te wysig. Dit bied 'n arbitrêre lees/schrijf primitief, wat toelaat om die GOT te wysig en sommige funksies na `system` te laat wys.
+- Ons kan slegs chunks van grootte groter as `0x100` allokeer.
+- Oorskryf `global_max_fast` deur 'n Unsorted Bin attack (werk 1/16 keer weens ASLR, omdat ons 12 bits moet verander, maar ons moet 16 bits verander).
+- Fast Bin attack om 'n globale array van chunks te wysig. Dit gee 'n arbitrêre read/write primitive, wat toelaat om die GOT te wysig en 'n funksie na `system` te laat wys.
 
+## Verwysings
+
+- Glibc malloc unsorted-bin integrity checks (voorbeeld in 2.33 bron): https://elixir.bootlin.com/glibc/glibc-2.33/source/malloc/malloc.c
+- `global_max_fast` and related definitions in modern glibc (2.39): https://elixir.bootlin.com/glibc/glibc-2.39/source/malloc/malloc.c
 {{#include ../../banners/hacktricks-training.md}}