Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
windows-x86-shellcode-poc — Windows x86 PoC: buffer overflow basato su stack con shellcode personalizzato su legacy Windows 32-bit. | Kitploit
Strumenti/GitHubGitHub/nataliadiak/windows-x86-shellcode-poc
Analisi delle VulnerabilitàReverse EngineeringShellcodeApprendimento e FormazioneSviluppo PayloadBinary Exploitation
GitHubnataliadiak/windows-x86-shellcode-poc

windows-x86-shellcode-poc

Windows x86 PoC: buffer overflow basato su stack con shellcode personalizzato su legacy Windows 32-bit.

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi
Vedi Repository
823 mesi faNon ancora revisionato

Proof of Concept di Buffer Overflow su Windows x86 per Principianti

Questo è un tutorial semplice e autonomo sugli exploit di buffer overflow basati sullo stack per Windows a 32 bit. Nessuna guida esterna necessaria: tutto ciò di cui hai bisogno è qui.

Cos'è questo repository?

  • vulnerable.c: Un programma semplice con una funzione gets() non sicura.
  • messageBox.asm: Un piccolo payload in assembly che verrebbe eseguito dopo l'overflow.
  • exploit.c: Un esempio di come l'overflow potrebbe essere innescato.

Questo progetto insegna un'idea centrale: la lettura di input non sicura può permettere a un attaccante di sovrascrivere l'indirizzo di ritorno e reindirizzare l'esecuzione.

La vulnerabilità: gets() non ha limiti di dimensione

In vulnerable.c, il programma fa questo:

root@kitploit:~
char buffer[32];
gets(buffer);

Il programma riserva 32 byte per buffer, poi chiama gets() per leggere l'input. Il problema: gets() non controlla la dimensione del buffer. Continua a leggere caratteri fino a quando non incontra un newline. Se l'utente digita 40 o 50 caratteri, i caratteri extra traboccano oltre il buffer di 32 byte.

Come è organizzata la memoria nello stack

Quando una funzione C viene eseguita, lo stack (una regione di memoria) memorizza:

  1. Variabili locali (come buffer)
  2. Il EBP salvato (base pointer della funzione chiamante)
  3. L'indirizzo di ritorno salvato (dove la CPU deve saltare quando la funzione ritorna)

Immaginalo così:

root@kitploit:~
Indirizzi più bassi (cima dello stack come disegnato)
[  buffer (32 byte)  ]
[    EBP salvato (4 byte)     ]
[  indirizzo di ritorno (4 byte)  ]
Indirizzi più alti (fondo)

Quando gets() trabocca buffer con troppo input, i byte extra sovrascrivono il EBP salvato e poi l'indirizzo di ritorno.

Se costruiamo attentamente l'overflow per piazzare un indirizzo specifico nel campo dell'indirizzo di ritorno, la CPU salterà a quell'indirizzo quando la funzione tenta di ritornare.

Come funziona l'exploit: passo dopo passo

  1. Il programma si avvia e alloca buffer[32] nello stack.
  2. Chiama gets(buffer) per leggere una riga di input dell'utente.
  3. Inviamo una stringa più lunga di 32 byte (ad esempio, 50 byte).
  4. gets() non ha controllo di dimensione, quindi scrive tutti i 50 byte nel buffer.
  5. I 18 byte extra traboccano oltre buffer e sovrascrivono il EBP salvato e l'indirizzo di ritorno.
  6. Costruiamo attentamente l'overflow in modo che l'indirizzo di ritorno punti allo shellcode nello stack.
  7. Quando la funzione ritorna, la CPU legge l'indirizzo di ritorno sovrascritto.
  8. La CPU salta allo shellcode.
  9. Lo shellcode viene eseguito con i permessi del programma.

Questa è la forma più semplice di esecuzione di codice tramite buffer overflow.

Cosa succede nello shellcode: Il payload

messageBox.asm è un piccolo pezzo di codice progettato per essere eseguito dopo l'overflow.

Fa quanto segue:

  1. Carica USER32.DLL: Chiama LoadLibraryA con la stringa "USER32.DLL" per assicurarsi che la libreria sia in memoria.
  2. Prepara gli argomenti per MessageBoxA: Spinge quattro argomenti sullo stack (handle della finestra, testo del messaggio, titolo, tipo di pulsante).
  3. Chiama MessageBoxA: Chiama la funzione API di Windows per visualizzare una finestra di messaggio con il testo "POSSO HACKERARE IL PC?".
  4. Esce pulitamente: Chiama ExitProcess per terminare il programma in modo sicuro.

Il punto chiave: questo è codice eseguibile che viene eseguito dopo che l'overflow ha reindirizzato l'esecuzione su di esso. Quando la finestra di messaggio appare sullo schermo, prova tre cose:

  1. Il buffer overflow ha funzionato e ha riscritto l'indirizzo di ritorno.
  2. L'esecuzione è saltata allo shellcode sullo stack.
  3. Lo shellcode è stato eseguito con successo e ha effettuato chiamate alle API di Windows.

In un attacco reale, questo payload potrebbe fare qualsiasi cosa: rubare dati, creare un utente, scaricare malware, ecc. La finestra di messaggio è solo un modo visibile e sicuro per dimostrare che è avvenuta l'esecuzione di codice arbitrario.

Questo payload specifico utilizza indirizzi di memoria hardcodati per MessageBoxA (0x751D8830) e ExitProcess (0x7437ADB0). Questi indirizzi sono specifici per un sistema. Il payload dovrebbe essere adattato per una versione o sistema Windows diverso.

MessageBoxA

Come compilare ed eseguire la demo

Passo 1: Disabilitare le protezioni

Windows moderno ha molteplici funzionalità di sicurezza che impediscono questo exploit:

  • Stack Canaries (flag GS): rilevano sovrascritture dello stack.
  • ASLR (DYNAMICBASE): randomizza gli indirizzi di memoria quindi gli indirizzi hardcodati non funzionano.
  • DEP/NX (NXCOMPAT): marca lo stack come non eseguibile per impedire l'esecuzione di codice lì.

Per questo esercizio didattico, le disabilitiamo tutte.

Passo 2: Compilare su Windows

Usa MSVC (Microsoft Visual C++) con flag specifici:

root@kitploit:~
cl /c /GS- /W3 /Zl vulnerable.c
link /SUBSYSTEM:CONSOLE /DYNAMICBASE:NO /NXCOMPAT:NO vulnerable.obj /OUT:vulnerable.exe

Significato dei flag:

  • /GS- disabilita la protezione da sovrascrittura del buffer dello stack.
  • /DYNAMICBASE:NO disabilita l'Address Space Layout Randomization (ASLR).
  • /NXCOMPAT:NO disabilita DEP, permettendo l'esecuzione di codice sullo stack.

Se hai già l'eseguibile, puoi disabilitare le protezioni con editbin:

root@kitploit:~
editbin /NXCOMPAT:NO /DYNAMICBASE:NO vulnerable.exe

Passo 3: Eseguirlo

  1. Avvia vulnerable.exe.
  2. Quando richiesto, inserisci una stringa lunga (più di 32 caratteri).
  3. Se l'overflow funziona, l'indirizzo di ritorno salvato viene sovrascritto.
  4. Il programma potrebbe crashare, saltare a memoria casuale, o (in un exploit reale con shellcode appropriato) eseguire il payload.

Perché il README è completo

Questo README spiega:

  1. Cos'è gets() e perché non è sicuro (nessun limite di dimensione).
  2. Come lo stack memorizza variabili locali, registri salvati e indirizzi di ritorno.
  3. Come un overflow può sovrascrivere l'indirizzo di ritorno.
  4. Come la CPU usa l'indirizzo di ritorno quando una funzione ritorna.
  5. Come lo shellcode può essere eseguito quando l'indirizzo di ritorno punta ad esso.
  6. Quali protezioni esistono e perché le disabilitiamo.
  7. Come compilare ed eseguire l'esempio.

Ora comprendi l'intero flusso dell'exploit di buffer overflow. Leggi i file di codice e confrontali con questa spiegazione per consolidare la tua comprensione.

Avviso importante sulla sicurezza

Questo esempio è solo per scopi didattici. Non utilizzare questa tecnica contro sistemi di cui non possiedi o non hai esplicito permesso di testare. L'accesso non autorizzato a sistemi informatici è illegale.

Scarica lo strumento