fundamentos de ingeniería inversa joxean · pdf filefundamentos de ingeniería...

Fundamentos de Ingeniería InversaJoxean Koret

Fundamentos de ingeniería inversa

Introducción Herramientas y puesta a punto del laboratorio Análisis estático

Introducción REconstrucción de código Búsqueda de vulnerabilidades

Análisis dinámico Malware Funcionalidades

Automatización

Introducción ¿Qué es la ingeniería inversa? Wikipedia:

”El objetivo de la ingeniería inversa es obtener información a partir de un producto accesible al público, con el fin de determinar de qué está hecho, qué lo hace funcionar y cómo fue fabricado.”

”La ingeniería inversa es un método de resolución. Aplicar ingeniería inversa a algo supone profundizar en el estudio de su funcionamiento, hasta el punto de que podamos llegar a entender, modificar y mejorar dicho modo de funcionamiento.”

”En el caso concreto del software, se conoce por ingeniería inversa a la actividad que se ocupa de descubrir cómo funciona un programa, función o característica de cuyo código fuente no se dispone, hasta el punto de poder modificar ese código o generar código propio que cumpla las mismas funciones.”

Legalidad

¿Es legal la ingeniería inversa? Varía según el país. Generalmente, si se dispone del producto

legalmente, la respuesta es sí. De todos modos, repito, depende del país. http://en.wikipedia.org/wiki/Reverse_engineering#Legality

http://en.wikipedia.org/wiki/Reverse_engineering#Legality

Fundamentos de Ingeniería Inversa

Herramientas más comunes

Herramientas más comunes

General Compiladores, intérpretes, monitores de procesos,

máquinas virtuales, emuladores, etc..

Análisis dinámico GNU Debugger OllyDbg IDA Pro

Análisis estático IDA Pro


Puesta en marcha de un laboratorio de ingeniería inversa

¿Qué necesitaremos?

Compiladores e intérpretes Python y C

Debuggers GDB, OllyDbg, IDA Pro

Desensamblador IDA Pro

Máquinas Virtuales VirtualBox

Herramienta: IDA Pro

Análisis estático: Breve introducción al uso de dicha herramienta.


Breve introducción a la teoría de grafosAnálisis Estático

Teoría de grafos

Breve iniciación

Teoría de grafos

¿Qué es un grafo? Wikipedia: ”Un grafo es un conjunto de objetos llamados

vértices o nodos unidos por enlaces llamados aristas o arcos, que permiten representar relaciones binarias entre elementos de un conjunto”.

Tipos de grafos Dirigidos y no dirigidos. En nuestro caso, nos interesan los dirigidos.

Teoría de grafos

¿Qué es un grafo dirigido? Un grafo en el que se conoce la dirección de relación entre nodos Definición de andar por casa.

Grafo dirigido:

Grafo no dirigido:

Teoría de grafos

¿Qué es un nodo (vértice)? La unidad fundamental de la que

están formados los grafos.

¿Qué es una arista? Corresponde a la relación entre

vértices.

Teoría de grafos

¿Qué tiene que ver la teoría de grafos con la ingeniería inversa de software? Mucho, como vamos a ver ahora mismo...

Teoría de grafos

Una función o conjunto de funciones se puede representar como un grafo dirigido. Callgraph (en inglés), o grafo de llamadas:

Cada nodo es una función de un programa y cada arista una unión que determina que una función llama a otra.

Flowgraph (en inglés), o grafo de flujo: Cada nodo es un bloque básico de una función y

cada arista determina el flujo de ejecución basado en tomas de deciciones.

Teoría de grafos: Flowgraph

Cada nodo es un bloque básico. ¿Qué es un bloque básico?

El conjunto de instrucciones contiguas hasta una toma de decisión.

¿Qué es una arista? Determinan las relaciones entre bloques básicos,

es decir, el flujo que tomará la ejecución del programa tras una toma de decisión.

Teoría de grafos: Flowgraph

Teoría de grafos: Callgraph

Teoría de grafos

Fin de la breve introducción Preguntas? Dudas?

Suficiente teoría? Empecemos con la práctica ;)

Análisis Estático

¿Qué es? Extraído de wikipedia: ”Static code analysis is the analysis of computer

software that is performed without actually executing programs built from that software”

Es decir, el medio de averiguar como funciona un software sin llegar a ejecutar el mismo, solamente leyendo el código del que dispongamos.

Ensamblador, generalmente. Empecemos ya a ver un poco de ensamblador ;)

Análisis estático: Ejemplo 1

¿Cómo quedaría en ensamblador x86 el siguiente código C?

#include <stdio.h>

int main(int argc, char **argv)

{

printf(”Hello world!\n”);

}

Ejemplo 1

Ejemplo 1: Análisis

Partes del código Prólogo de función: Indica la convención de

llamadas y el espacio reservado para variables locales.

Cuerpo: Establece una constance como argumento 1 ([esp]) y después llama a la función 'puts'.

Epílogo: Restaura la pila y retorna a la función llamada



#include <stdio.h>


{

printf(”Hello %s!\n”, argv[1]);

}

Ejemplo 2


Prólogo y epílogo: Igual que antes. Cuerpo:

Mueve la dirección en ebp+arg4 (argv) al registro EAX y le incrementa 4 (argv[1]). El contenido de EAX se mueve a EDX.

Mueve a EAX la dirección de una constante ('Hello World!\n').

Establece como argumento 2 EDX y como argumento 1 EAX (es decir, argv[1] y ”Hello World!”).

Llama a la función _printf.

Ejemplo 2: Notas

Se utiliza la convención de llamadas ”cdecl”. Los argumentos a funciones se pasan en la pila

de derecha a izquierda. Se utiliza ESP para ”envíar” argumentos y EBP para ”recoger” argumentos. Ejemplos: Para poner argumentos

mov [esp+4], eax → Argumento 2 mov [esp], eax → Argumento 1

Para leer argumentos mov eax, [ebp+4] → Argumento 2 mov eax, [ebp] → Argumento 1



#include <stdio.h>


{

if (argc > 1)


}

Ejemplo 3


Se compara si [ebp+arg_0] es menor o igual que 1 y de ser así se salta a una etiqueta (locret_XXX) donde simplemente se restaura la pila y se retorna.

De lo contrario, hace lo mismo que en el ejemplo 2.

Al final, llega a la misma zona de código anterior, la marcada por la etiqueta locret_XXX.

Ejemplo 3: x86_64

¿Cómo se vería el mismo ejemplo en ensamblador AMD64 (x86_64)?

Ejemplo 3 x86_64



#include <stdio.h>

void foo(char *arg)

{

char buf[24];

strcpy(buf, arg);

printf(”Hello %s!\n”, buf);

}

Ejemplo 4

Ejemplo 4: Análisis (Parte 1)

Mueve el argumento [ebp+src] a EAX y el registro se pone como argumento 2 a función ([esp+4]).

Carga la dirección de la variable local [ebp+dest] y la pone como argumento 1 a función ([esp]).

Llama a strcpy. ...


Mueve a EAX la constante (”Hello World!\n”). Carga la dirección de la variable local

[ebp+dest] en EDX. Establece EDX como argumento 2 ([esp+4]) y

EAX como argumento 1 ([esp]). Es decir: Argumento 1 → Constante ”Hello World!\n” Argumento 2 → Variable local [ebp+dest]

Llama a la función printf.

Análisis estático: Ejemplo 5#include <stdio.h>

int foo(char *arg)

{

char buf[24];

if (strlen(arg) > 23)

return 0;

strcpy(buf, arg);


return 1;

}


Calcula el tamaño (strlen) del argumento src (ebp+src). El valor de retorno está guardado en EAX.

Si EAX es menor o igual (Bellow or equal) salta a loc_XX1D. Sino, establece EAX a 0 y salta incondicionalmente (JMP) a loc_XX48.

En loc_XX48 simplemente restaura la pila y retorna.

...

Ejemplo 5: Anaĺisis (Parte 2)

En loc_XX1D copia el argumento src (ebp+src) a la variable local dest (ebp+dest).

Después, muestra llama a la función printf pasando como argumentos la variable local dest y la cadena de formato ”Hello %s!\n”.

Tras hacer esto, establece EAX a 1 y continúa en loc_XX84.

EAX contiene el valor de retorno de la función foo: 0 si el argumento es muy grande o 1 si es correcto.

Ejercicio 1

¿Qué hace el programa? ¿Cuántos argumentos recibe? ¿Cuáles son los tipos de datos de los

argumentos esperados?

Ejercicio 1: Solución

¿Qué hace el programa? Imprimir el nombre y la edad dados y retornar el

número de años.

¿Cuántos argumentos recibe? 2 argumentos: El nombre y la edad.

¿Cuáles son los tipos de datos de los argumentos esperados? char* para el nombre e int para la edad.

Ejercicio 2

Un ejemplo más real: Solo tenemos el IDB ¿Qué hace el programa udt_signal?

Ejercicio 2: Solución

¿Qué hace el programa udt_signal? Verifica que reciba como mínimo 2 argumentos. El argumento 1 es el PID de un proceso. El resto de argumentos se desechan. Intenta cambiar al usuario root (setuid(0)). Envía la señal SIGUSR2 al proceso especificado.

ARM

Ya hemos visto unos cuántos ejemplos básicos con x86

¿Habrá mucha diferencia con ARM? El ensamblador no es lo importante.

Análisis estático: Ejemplo ARM 1

¿Cómo quedaría en ensamblador ARM el siguiente código C?

#include <stdio.h>


{


}

Ejemplo ARM 1

Ejemplo ARM 1

¿Cómo funciona? Igual que x86, pero con otro juego de instrucciones Se guarda en la pila la dirección desde donde se ha

llamado a main (LR, Link Register) y se reserva espacio para variables locales (PUSH, SUB, ADD, STR, STR)

Se pone como argumento 1 a función (R0) la constante ”Hello World!\n”

Se llama a la función puts (BLX, Branch with Link) Se restaura la pila y se sale (ADD.W, MOV, POP)

retornando a la dirección que estaba en LR (PC)

Ejemplo ARM 1

¿Qué diferencias vemos en ARM respecto de x86? Los argumentos se pasan por registros:

R0 → Argumento 1 R1 → Argumento 2

Las llamadas a función se hacen con BLX. La dirección de la función que nos llama se

almacena en LR (Link Register). Para retornar, esa dirección se pasa a PC

(Program Counter).



#include <stdio.h>


{

if (argc > 1)


}

Ejemplo ARM 2

Ejemplo ARM 2

¿Qué diferencias vemos? Los argumentos a la función main se están

recogiendo con STR REG, [R7, #argumento]. Utiliza R3 como registro de proposito general para

guardar la dirección de la constante. Carga la dirección de argv (LDR) en R2 Mueve R3 a R0, la cadena de formato,

estableciéndola como argumento 1 a función Mueve R2 a R1(argv[1]) y llama a la función printf.

Análisis estático: Ejemplo ARM 3


#include <stdio.h>

void foo(char *arg)

{

char buf[24];

strcpy(buf, arg);


}

Ejemplo ARM 3

Ejemplo ARM 3

Se compara si R3 ([R7, argc]) es menor o igual que 1 (BLE) y de ser así se salta a una etiqueta (loc_XXX) donde simplemente se restaura la pila y se retorna.

De lo contrario, hace lo mismo que en el ejemplo anterio.

Al final, llega a la misma zona de código anterior, la marcada por la etiqueta loc_XXX.

Como se puede ver, escasas diferencias con x86.

Análisis estático: Ejemplo ARM 4#include <stdio.h>

int foo(char *arg)

{

char buf[24];

if (strlen(arg) > 23)

return 0;

strcpy(buf, arg);


return 1;

}

Ejemplo ARM 4: Análisis I

Estable src como argumento a función y llama a strlen (BL). El valor de retorno (R0) lo almacena en R3.

Compara (CMP) si es menor que 0x17 (BLS) salta a loc_83FA, de lo contrario mueve 0 a R3 y salta incondicionalmente (B) loc_841E.

En loc_841E, establece el valor de retorno de función (R0) al valor de R3, restaura la pila y retorna.

...

Ejemplo Arm 4: Análisis II

En loc_1A, carga en R3 una variable local (R7, #dest) y mueve R3 a R0. Como segundo argumento a función pone la dirección del argumento dest y llama a la función strcpy.

Establece R3 a la dirección de la constante, mueve la variable dest a R2, y pone R3 como el argumento 1 (R1) y la variable dest como el argumento 2 (R2). Tras esto, llama a la función printf.

Para finalizar mueve 1 a R3 y continúa en loc_841E.

Análisis estático

Preguntas, dudas?


REconstrucción de código

Guión

• Introducción

• Fundamentos

• Construcciones típicas– Variables

– Llamadas a funciones

– Sentencias condicionales

– Bucles

• Ejemplos

– Durante la charla se irá reconstruyendo un sencillo programa

Introducción

• ¿Para qué hace falta?– Para recuperar código fuente perdido

– Para duplicar (y extender) algoritmos

– Para entender al completo un algoritmo

• Decompilación ¿Hasta qué punto es posible?

– Pérdida de información

– Optimizaciones del compilador

Fundamentos

• Compiladores y dialectos de ensamblador– Cada compilador genera un código diferente

– Cada compilador utiliza sus propias convenciones de llamadas

– Cada compilador se basa en «estándares» diferentes

• Sin embargo, todos llevan al final la misma lógica

– Una acción se puede hacer de mil modos pero sigue siendo la misma acción

Convenciones de llamadas

• Llamadas a función– Las típicas:

• cdecl

• stdcall

• fastcall

• pascal

– Cada compilador utiliza una convención por defecto diferente

• Típicamente, en C, se utiliza cdecl (funciones normales) y stdcall (funciones exportadas)

Convenciones de llamadas

• Cdecl– Los argumentos se pasan en la pila de derecha a izquierda y se arregla

la pila dentro de la función llamada

• Stdcall– Exactamente igual pero se arreglan por la función que llama, no por la

función invocada

• Fastcall– Los argumentos se pasan en registros y utilizando la pila. Se pasan de

derecha a izquierda:

• ECX, EDX, PILA

• Pascal

Igual que fastcall pero se utiliza como primer registro EDX

Otras convenciones de llamadas

• Thiscall– Es la convención de llamadas de C++

– Es igual que cdecl pero siempre se pasa en ECX el puntero a this, es decir, un puntero al objeto

• En esta charla se excluyen ejemplos en C++

– Al igual que en Visual Basic, Pascal, etc...

– Solo hablaremos de C

Construcciones típicas

• Variables– Stack, heap y globales

• Llamadas a funciones

– Con los diferentes tipos de convenciones de llamadas

• Sentencias condicionales

– If, else, switch, etc...

• Bucles

– For y while

• Estructuras

– ¿Cómo es una estructura en ensamblador?

Variables y llamadas a funciónStack y cdecl

Variables y llamadas a funciónStack y cdecl

• En este ejemplo se utilizan:– Variables de stack

• SUB ESP, 0x100 ; 255 bytes de memoria en ESP

• LEA ECX, [EBP+TEXT] ; Se carga la dirección

– Llamada a una función cdecl desde ”foo”

Call _strcpy ; Se llama a la función Add esp, 8; Y luego se arregla la pila Los argumentos se recogen de la pila

Reconstrucción de código

• ¿Qué hemos aprendido?– Sabemos cuanto espacio se ha reservado para variables

locales

– Sabemos el tamaño de las variable estáticas

– Sabemos la convención de llamadas

• Por lo cual, sabemos que argumentos se le han pasado a la función

– Ya sabemos reconstruir simples llamadas a función

• Veamos el ejemplo

Este código entonces ...

...quedaría entonces así

void __cdecl foo(int *arg)

{

int buf[0x100]; strcpy(buf, arg);

MessageBoxA(0, buf, buf, 0);

}

void __cdecl foo(char *arg)

{

char buf[0x100]; strcpy(buf, arg);


}

Más con variables

• ¿Y si la variable fuera local pero dinámica y no estática?

Código


{

int *buf; strcpy(buf, arg);


}


{

char *buf; strcpy(buf, arg);


}

Más con variables

• ¿Y si la variable fuera global?– Veríamos un «offset dword_address» en el IDA

– O con símbolos un offset a la variable:

Código

int buf[255];


{ strcpy(buf, arg);


}

char buf[255];


{ strcpy(buf, arg);


}

Sentencias condicionales

• ¿Cómo se representa una construcción IF/ELSE o SWITCH en ensamblador?– Cada compilador hace lo que le da la gana

– Pero en general, todos siguen la misma forma

– A la hora de reconstruir el código tomaremos la siguiente norma:

• Utilizar GOTOs inicialmente

• Y, lo más importante, invertir la operación

• Quedará más claro en el siguiente ejemplo....

Sentencias condicionales

Código

if (argc == 1)

{

_usage(argv[0]);

_exit(1);

}

else

{

goto loc_40106C;

}

loc_40106C:

_foo(argv[1]);

if (argc == 1)

{

usage(argv[0]);

exit(1);

}

else

{

foo(argv[1]);

}

Más sentencias condicionales

Código

if (argc == 1) {

_usage(argv[0]);

_exit(1);

}

If (argc > 2)

goto loc_40106C;

_printf(“Tu madre...”);

_exit(2);

loc_40106C:

_foo(argv[1]);

if (argc == 1)

{

usage(argv[0]);

exit(1);

} else if (argc > 2) {

foo(argv[1]);

} else {

printf(“Tu madre...”);

exit(2);

}

Bucles

• ¿Cómo se crean los bucles (for, while) en ensamblador?– Pocas veces se utilizan las construcciones que un

“humano” usaría:

• LOOP, LOOPE, etc...

– Normalmente se utilizan saltos al igual que con las sentencias condicionales

• LOC_XXX:

• <<STUFF>>

• CMP EAX, 1

• JNZ LOC_XXX

– Veamos un ejemplo...

Más sentencias condicionales

Código: Normalizando

void _foo(int arg_0, int arg_4) {

int var_4;

var_4 = 0;

goto loc_401016

loc_40100D:

var_4++;

loc_401016:

if (arg_0 < var_4) {

_printf("Arg %d: %s\n", arg_0,

arg_4[var_4]);

}

goto loc_40100D;

}

void _foo(int arg_0, int arg_4)

{

int var_4;

for (var_4 = 0;

var_4 < arg_0;

var_4++)

{

_printf("Arg %d: %s\n",

arg_0, arg_4[var_4]);

}

}

Ejercicio

Reconstruir el código C del programa 'reco01' Se puede elegir el ELF x86, ARM o el PE x86 No hemos visto como hacerlo en ARM pero...

¿Será muy diferente? ;)

Punto adicional: ¿Qué es lo que hace?

Soluciones: x86 y ARM

Demo(Son iguales)

Reconstrucción de código

Preguntas, dudas?


Búsqueda de vulnerabilidades en binarios

Búsqueda de vulnerabilidades

¿Qué es una vulnerabilidad? Wikipedia: Es una debilidad que permite a un atacante reducir

la seguridad de la información de un sistema.

Tipos de vulnerabilidades Memory safety violations Input validation errors Race conditions Privilege escalation ...


Vulnerabilidades a identificar: Desbordamientos de buffer (stack y heap)

Escritura más allá de los límites de ”variables”. Cadenas de formato

Abuso de modificadores de cadenas de formato. Desbordamiento de enteros

Cambio de tamaño de ”variables”. Escaladas de privilegios locales en Win32 y Linux

Privilegios en subprocesos y librerías. Fallas lógicas

¡Hay tantos tipos!

Buffer overflows (stack)

El siguiente es un ejemplo de buffer overflow de stack:

void foo(char *data)

{

char buf[8];

strcpy(buf, data);

}

Ejemplo 1

En este ejemplo, la función ”foo” recibe un argumento ”data” de tipo char *.

Este argumento se copia en una variable local (guardada en el stack) con tamaño 8.

Si el tamaño de ”data” es mayor que 8 se sobreescribirán otros datos que estén en la pila Como la dirección de retorno de la función, por

ejemplo.

Ejemplo 1

Ver una vulnerabilidad de este tipo en código fuente suele ser simple

¿Cómo se puede identificar una falla de este tipo en ensamblador?

Veamos el ejemplo con un programa simple en C compilado para x86 y ARM.

Ejemplo 1: Código C

void doprintf(char *data)

{

char buf[255];

strcpy(buf, data);

printf(data);

}

Ejemplo 1: Código ASM x86

Ejemplo 1: Código ASM x86

La variable local ”dest” tiene tamaño 0x107 según el desensamblador.

Se substraen 0x118 bytes de la pila, para uso local.

Se carga la dirección de la variable local ”dest” en el registro de uso general EAX.

Esta variable se pasa como argumento 1 a la función strcpy.

Ejemplo 1

¿Cuántos bytes tenemos que sobreescribir para desbordar la variable ”dest”? Mínimo, 0x107 bytes.

¿Cuántos bytes tendríamos que sobreescribir para cambiar todo el espacio reservado por la función? Mínimo, 0x118 bytes.

Ejemplo 1

$ ./test1-x86 `perl -e 'print "a"x 0x106;'`

aaa...

$ ./test1-x86 `perl -e 'print "a"x 0x107;'`

Segmentation fault

$ gdb ./test1-x86

(gdb) r `perl -e 'print "a"x 0x107;' `

Program received signal SIGSEGV, Segmentation fault.

0x61616161 in ?? ()

Buffer overflows (heap)

void foo(char *arg)

{

char *buf;

buf = malloc(255);

strcpy(buf, arg);

free(buf);

}

Ejemplo 2 La vulnerabilidad está muy clara en el código

fuente. ¿Será tan clara en ensamblador x86?

Ejemplo 2

En este caso, el tamaño de la variable queda más claro: El argumento a malloc.

Vemos que trabaja con punteros, moviendo el resultado de malloc a ”ptr”.

¿Cuántos bytes necesitaremos escribir para desbordar la variable ptr? Más de 255 byte(s).

Cadenas de formato

Ejemplo de función vulnerable a cadenas de formato:

void dolog(char *msg)

{

printf(msg);

} Bastante obvio, verdad? Y en ensamblador?

Ejemplo 3

Ejemplo 3

¿Qué necesitamos para identificar una vulnerabilidad de cadena de formato? Identificar llamadas a funciones printf (sprintf,

vsprintf, …). Identificar el primer argumento: Si la cadena de

formato no es una constante, podríamos estar ante una de estas fallas ancestrales.

Desbordamiento de enteros


¿Dónde está la vulnerabilidad? ¿Nadie la ha visto? ;)

Veamos, ¿Qué lo que hace? Recibe una cadena y un tamaño. Si el tamaño de la cadena es mayor que el tamaño

especificado, muestra un error. Aquí está el error.

De lo contrario, reserva el tamaño especificado y copia la cadena recibida en una variable local.


Hagamos una prueba:

$ ./test5 1234 4

(OK)

$ ./test5 1234 0

Too big!

$ ./test5 1234 -1

Segmentation fault ¿Qué ha pasado? Promoción de enteros.

Promoción de enteros

Cuando se compara 2 enteros de diferente tipo (un entero con signo y otro con signo) se convierten ambos elementos al de mayor tamaño (unsigned).

El argumento arg_size tiene signo (int es signed int) mientras que el tamaño (size_t) es unsigned.

La conversión provoca que el valor de arg_size se cambie de ”-1” a su representación como unsigned: 0xFFFFFFFF.

¿Cuál sería el tamaño del malloc? 4GB.


Una vez que se conoce este tipo de vulnerabilidad se hace relativamente fácil identificarla teniendo el código.

¿Cómo se puede identificar esta vulnerabilidad en código ASM x86?

Ejemplo 4 (Parte I)

La función ”atoi” devuelve un ”signed integer”

Ejemplo 4 (Parte II)

La función ”strlen” devuelve un ”unsigned”. La instrucción ”jbe” hace una comparación a ”unsigned” mezclando ”signed” e ”unsigned”

Ejemplo 4

Esta vulnerabilidad no es tan simple de identificar a primera vista, verdad ;)

Sin embargo, una vez conocida, se hace más simple.

Existen otros tipos de promoción de enteros: Signed y unsigned char, por ejemplo.

La regla principal a recordar: Siempre se convierte al tipo más grande.

Ejercicio 1: MySQL Client

¿Cuántas fallas podéis encontrar en 5 minutos con lo aprendido hasta ahora? ;)

Utilizad solo el binario, no busquéis el código Luego veremos el archivo mysql.cc y

compararemos resultados.

Lo principal: No intentéis entender línea por línea que hace, obtener una visión global. Lo importante es leer el ensamblador teniendo

siempre en cuenta que es lo que quieres hacer, ceñirte a tu tarea, en este caso, buscar fallas.


Preguntas, dudas?

Análisis Dinámico

Breve introducción Uso del depurador del IDA

No utilicéis aún malware :) Usaremos el notepad o el calc, por ejemplo.

Packers y protectores ¿Qué es un packer? ¿Qué es un protector?

Descubrimiento de funciones con depuración Motor JavaScript de Acrobat Reader 9

Packers y protectores

¿Qué es un packer? Un packer es un software encargado de cifrar y/o

comprimir un programa. El objetivo puede ser reducir su tamaño y/o

esconder la verdadera naturaleza del software.

¿Qué es un protector? Lo mismo que un packer pero se añaden

”protecciones” para hacer más difícil la ingeniería inversa.

Antidebug, antiemulación, antidesensamblado, etc...

Packers y protectores

Algunos ejemplos fáciles: UPX FSG Petite

Packers: UPX

UPX es un packer open source muy popular y muy simple de desempaquetar.

En muchos packers simples, mirando el grafo de flujo de la función inicial se puede determinar cuando termina la tarea de descompresión y/o descifrado. Es decir, tenemos que buscar un nodo de salida.

UPX: Flowgraph

UPX

En IDA podemos ver, más o menos, claramente cuál es el punto de salida de la función de descompresión de UPX. Cuando llegue a ese nodo, el ejecutable estará

desempaquetado en memoria y podremos analizarlo.

Solo faltaría reconstruir la tabla de importación. Las funciones de librería que utiliza el ejecutable

empaquetado. No reconstruiremos el ejecutable original, solo su

visualización en ASM.

DEMO

Packers: FSG

Otro packer sencillito, freeware. ¿Será muy diferente de desempacar?

Veámoslo ;)

FSG: Flowgraph

FSG

Se ve claramente cuál es el punto de salida de esta función.

¿Bastará la misma técnica utilizada anteriormente con UPX?

DEMO

Petite

Misma estrategia: Buscamos el punto de salida de la función principal. Ponemos un breakpoint en ese bloque básico. Buscamos las llamadas a funciones no resueltas. Creamos la tabla de importación. Guardamos una imagen de la memoria. Detenemos y analizamos. Ya está!

Petite: Flowgraph

Petite

¿Parece que no es tan sencillo, verdad? Utiliza excepciones para desempaquetarse. ¿Qué podemos hacer?

Ignorar las excepciones y utilizar el plugin de IDA Univer PE Unpacker (UUPE).

Ejercicio: ASPack

Desempaquetar un archivo con ASPack. Es un poco diferente, pero igual de fácil. NO utilicéis el Universal PE Unpacker.

Intentad hacerlo a mano ;)

Análisis de Malware

¿Somos capaces con lo qué hemos aprendido hasta ahora de analizar un malware real? Sí :)

Está empacado (sorpresa). Utiliza trucos anti-desensamblado. La estrategia de desempaquetado es diferente ;)

Pero muy fácil Veamos un ejemplo muy simple: Trj/FlyStudio.BQ

Es un malware bastante ”inocuo”, no os preocupéis en meter la pata ;)

Necesita una librería que no tenéis. Ejercicio: ¿Qué hace el malware?

Análisis de Malware: MyTob

Analizaremos un malware clásico: MyTob Está empaquetado (MEW).

Ejercicio: ¿Qué hace este malware? El comportamiento es algo ”más” complejo, pero

poco más. Fácil de leer, una vez desempaquetado ;)

Análisis Dinámico


Análisis Dinámico

Análisis del motor JavaScript de AcroReader ¿Sabríais encontrar dónde está el código de la función

App.alert? Primer ejercicio, estáticamente se puede encontrar ;)

¿Sabríais decir como se determina si una función es privilegiada o no?

Segundo ejercicio, aquí si que hace falta análisis dinámico.

¿Podéis encontrar alguna función oculta no documentada que debería ser privilegiada y no lo es?

Esta parte la hacemos entre todos.


FINMuchas gracias a tod@s!

fundamentos de ingeniería inversa joxean · pdf filefundamentos de ingeniería...

Documents