Sto imparando sull'overflow del buffer dello stack. Una piccola informazione sul mio obiettivo: un piccolo computer basato su Intel x86, con una destinazione compilata con Compilatore TCC senza protezioni di alcun tipo eseguite su Windows XP.
Ho successo quando ho inviato uno shellcode di ~ 15 byte per attaccare il mio server di casa TCP. (Progettato da me stesso). Il buffer attaccato ha una lunghezza di 20 byte.
Ho preso precauzioni per inviare byte di trash per riempire gli spazi e per sovrascrivere EBP e associare un indirizzo hardcoded invertito a little endian.
Ma quando ho inviato lo stesso shellcode, ma per attaccare un buffer più grande sopra i 20-30 byte, fallisce, saltando su un addrore sconosciuto.
Il compilatore sta cambiando l'ordine delle variabili dello stack ??? Ho scritto prima un piccolo buffer e dopo un buffer più grande. Ho cambiato con una proporzione costante i due per essere in grado di adattarsi allo shellcode.
Il compilatore sta cambiando l'ordine, mettendo EIP o EBP in un altro punto dello stack ?? Ho disabilitato le protezioni del compilatore del compilatore TCC e la protezione del sistema siabled come DEP e ASLR.
Posso fornire più informazioni se è necessario, compresi i frammenti di codice breve, se me lo chiedi.
MODIFICA 1:
Ecco il mio codice server TCP di destinazione in un sito simile a pastebin:
Ecco il mio exploit:
EDIT 2:
La modifica può influenzare il mio exploit ??? Non ho molte competenze in questo settore. Ho scelto valori multipli di 4 (32 bit). Penso che non possa influire, qualcuno può chiarirmi ???
EDIT 3: Ho scoperto che uno shellcode leggermente modificato non funziona, ma più piccolo lo fa. FASM.
QUESTO NON FUNZIONA:
use32
mov eax, 0xDEADBEEF
mov ebx, 0xDEADBEEF
mov ecx, 0xDEADBEEF
mov edx, 0xDEADBEEF
int3
QUESTO LAVORO:
mov eax, 0xDEADBEEF
mov ebx, 0xDEADBEEF
mov ecx, 0xDEADBEEF
int3
Perché il primo, non funziona ??? Ho riempito lo spazio rimanente nel buffer con cestino. Non sembra avere byte null.