Ingeniería inversa de un código ensamblador x86

Hola a todos de nuevo!!

Hoy os traigo un tema que me quedaba pendiente desde hace tiempo y en un hueco he podido hacer algo rápido para poder explicarlo lo más claro posible.

El término reversing no es más que una adaptación del término reverse engineering que se lleva usando desde hace mucho tiempo y que principalmente nació en época de enfrentamientos bélicos como medio para investigar la tecnología enemiga. Aunque siempre se ha usado el término ingeniería inversa, en el campo aplicado fuera de la informática, con la llegada de esta, se adaptó al uso.

Reversing o reverse engineering es el término acuñado al proceso inverso aplicado a un producto final, es decir, partiendo de un diseño A para conseguir un producto B, este término es el proceso inverso, que partiendo de un producto B conseguir el preciado diseño A.

Esta tarea no es nada fácil, de hecho es una de las disciplinas más complejas en la ingeniería.

Para el caso de hoy, en el que nos centraremos en una pieza de código x86 procedente del lenguaje C/C++, me gustaría explicarlo claro para que podáis quedaros con el máximo detalle y aprender con ello algo nuevo, sin embargo, esto no pretende ser una guía y es que comprimir años de investigación, de diferentes arquitecturas, variantes, compiladores, optimizaciones, etc. en algo escueto es complicado. Si a alguien le gusta este tema, que para mí es muy interesante, hay bastantes libros muy interesantes por la red.

Hay que tener en cuenta un aspecto importante y es que a lo largo de la historia, desde el primer compilador hasta los más modernos de hoy día, ha habido muchos cambios, en todos los aspectos de de esta ingeniería (que hay que darle de comer a parte) y que seguirá avanzando a pasos cada vez mayores. Es dificil seguir el hilo, pero más difícil es estar al día; pero no preocuparse, salvo que te dediques o te quieras dedicar a esto, no tienes mayor problema, la teoría básica “sigue” siendo la misma.

El siguiente snippet de arquitectura x86 (32 bits) procede de un código C/C++, en el que lo analizaremos de forma estática con la sintáxis Intel y sin herramientas. La decisión de no utilizar herramientas recae en que las herramientas no siempre nos van a salvar en todos los casos y por ello en ciertas ocasiones habrá que usar los conocimientos propios para poder completar el puzzle. Con este ejemplo, repito, no da para mucho pero sí para ver un poco en detalle lo que podría ser un ejemplo real (muy resumido).

Vale tenemos el siguiente snippet:

Dump of assembler code for function main:
0x565561b9 <+0>: lea ecx,[esp+0x4]
0x565561bd <+4>: and esp,0xfffffff0
0x565561c0 <+7>: push DWORD PTR [ecx-0x4]
0x565561c3 <+10>: push ebp
0x565561c4 <+11>: mov ebp,esp
0x565561c6 <+13>: push ebx
0x565561c7 <+14>: push ecx
0x565561c8 <+15>: sub esp,0x10
0x565561cb <+18>: call 0x565560c0 <__x86.get_pc_thunk.bx>
0x565561d0 <+23>: add ebx,0x2e30
0x565561d6 <+29>: lea eax,[ebx-0x1ff8] ; "allhacked.com"
0x565561dc <+35>: mov DWORD PTR [ebp-0x10],eax
0x565561df <+38>: sub esp,0xc
0x565561e2 <+41>: push DWORD PTR [ebp-0x10]
0x565561e5 <+44>: call 0x56556040 <strlen@plt>
0x565561ea <+49>: add esp,0x10
0x565561ed <+52>: mov DWORD PTR [ebp-0x14],eax
0x565561f0 <+55>: sub esp,0xc
0x565561f3 <+58>: lea eax,[ebx-0x1fe8] ; "Spell your favourite cybersecurity website:"
0x565561f9 <+64>: push eax
0x565561fa <+65>: call 0x56556030 <puts@plt>
0x565561ff <+70>: add esp,0x10
0x56556202 <+73>: mov DWORD PTR [ebp-0xc],0x0
0x56556209 <+80>: jmp 0x56556229 <main+112>
0x5655620b <+82>: mov edx,DWORD PTR [ebp-0xc]
0x5655620e <+85>: mov eax,DWORD PTR [ebp-0x10]
0x56556211 <+88>: add eax,edx
0x56556213 <+90>: movzx eax,BYTE PTR [eax]
0x56556216 <+93>: movsx eax,al
0x56556219 <+96>: sub esp,0xc
0x5655621c <+99>: push eax
0x5655621d <+100>: call 0x56556060 <putchar@plt>
0x56556222 <+105>: add esp,0x10
0x56556225 <+108>: add DWORD PTR [ebp-0xc],0x1
0x56556229 <+112>: mov eax,DWORD PTR [ebp-0xc]
0x5655622c <+115>: cmp eax,DWORD PTR [ebp-0x14]
0x5655622f <+118>: jl 0x5655620b <main+82>
0x56556231 <+120>: mov eax,0x0
0x56556236 <+125>: lea esp,[ebp-0x8]
0x56556239 <+128>: pop ecx
0x5655623a <+129>: pop ebx
0x5655623b <+130>: pop ebp
0x5655623c <+131>: lea esp,[ecx-0x4]
0x5655623f <+134>: ret
End of assembler dump.

Antes de comenzar, realizaremos un vistazo rápido al código. Con este análisis conseguiremos ponernos en situación, como podría ser: el modo en el que se ha compilado, si tiene información de debug, alguna optimización, etc.

Se puede comprobar que se ha compilado en 32-bit ya que los registros utilizados son los que representan tamaño de 32-bit.
Estos registros de 32-bit son:

  • Registros de datos: EAX, EBX, ECX y EDX.
  • Registros de punteros: ESP y EBP.

Para dar un poco de sentido a estos registros, se muestra en la siguiente tabla, todos los registros que están interrelacionados.
Por tanto, se puede ver, por ejemplo, como el registro EAX de 32-bit está conformado por el registro AX de 16-bit y los registros de 8-bit AH y AL cada uno. Los registros de 16 y de 8 bit son específicos de las arquitecturas de 16 y 8 bit respectivamente. Siguiendo esta similitud se puede ver cómo están conformados los registros EBX, ECX y EDX.

Register 32 bit table.

Cada uno de estos registros tiene un uso específico.

  • El registro EAX (AX, AH y AL en su defecto en función de la arquitectura) es lo que se suele llamar como “acumulador primario” usado para operaciones entrada/salida y la mayoría de las operaciones aritméticas.
  • El registro EBX (BX, BH y BL) también conocido como registro base, ya que es usado en la indexación de direcciones.
  • El registro ECX (CX, CH y CL) es el registro contador, es decir, almacena la cuenta en operaciones iterativas cíclicas.
  • El registro EDX (DX, DH y DH) es el registro de datos, donde es usado en operaciones entrada/salida. Ya que su uso es de operaciones, en ocasiones es usado junto con el “acumulador primario” para operaciones de multiplicar y dividir que pueden dar a lugar a valores grandes.

De igual modo, los registros de punteros.

Pointer Register 32 bit table.
  • El registro ESP (SP para arquitectura de 16-bit) proporciona el valor de offset dentro de la pila de programa, es decir, este registro contiene el puntero a la cima de la pila de programa y es usado para acceder a la pila de programa usando el valor de este registro y un valor offset, para así poder acceder a diferentes partes de esta.
  • El registro EBP (BP en arquitectura de 16-bit) principalmente es usado para referenciar variables que pueden ser pasadas por parámetro a una subrutina, también es usado para almacenar variables. Apunta a la actual base del marco de pila.

Visto esto, seguimos analizando las instrucciones mnemotécnicas en general, del código ASM.

Como se puede apreciar, hay diferentes llamadas a subrutinas (usando la instrucción CALL).

  1. La primera llamada a la subrutina es la de <__x86.get_pc_thunk.bx>.
    0x565561cb <+18>: call 0x565560c0 <__x86.get_pc_thunk.bx>
    0x565561d0 <+23>: add ebx,0x2e30

    Esta subrutina es bastante llamativa y desconcertante a la vez. La causa de esto es debido a que se ha compilado (por defecto) con Position-Independent Executables (PIE), no es ni más que una protección que se ha añadido al momento de compilar el código. Esta protección PIE previene ataques en memoria conocida, es decir, un código cualquiera sin esta protección se alojará (por defecto) en una posición concreta de memoria y por tanto unos atacantes sabrían donde se está ejecutando dicho binario y con algún exploit se podría explotar la estructura del binario y ser comprometido. Al tener esta protección, el binario podrá alojarse en cualquier posición de la memoria (“aleatoriamente”) evitando así poder tener acceso a los bloques del binario alojado en memoria y su composición.
    Esta subrutina es elegida según conveniencia del compilador ya que puede usar <__x86.get_pc_thunk.XX> donde XX puede ser ax, bx, cx y dx donde al usarse .ax afectará a los registros pertinentes de la arquitectura, EAX, AX. En este caso, es .bx por lo que se puede observar que la siguiente instrucción usa el registro EBX.
    El compilador selecciona al momento de aplicar esta protección, la función apropiada, que usará uno de los 4 registros anteriormente mencionados.

  2. La segunda llamada es la de strlen@plt.
    0x565561e5 <+44>: call 0x56556040 <strlen@plt>
    Esta subrutina toma como argumento una string y devuelve su longitud, el valor retornado es un long int es decir DWORD. Esta subrutina está declarada en el header . El “@plt” no es más que un identificador que indica que para llamar a srtlen tiene que pasar por la “Procedure Linkage Table es decir, srtlen estará definida en el .h como external y por tanto, en una shared library. A diferencia de srtlen una función que no sea external no tendría el identificador “@plt”.

  3. La tercera llamada es la de puts@plt.
    0x565561fa <+65>: call 0x56556030 <puts@plt>
    Esta subrutina toma un solo argumento, la dirección que apunta al inicio de una cadena y la imprime por pantalla. Esta subrutina hace lo mismo que printf, a diferencia que puts imprime tal cual la cadena sin aplicar modificaciones sobre la misma al encontrar un %. De igual forma pasa por el PLT.

  4. La tercera llamada es la de putchar@plt.
    0x5655621d <+600>: call 0x56556060 <putchar@plt>
    Esta subrutina toma un solo argumento, la dirección que apunta a un caracter y la imprime por pantalla. Esta subrutina es muy parecida a puts solo que con un caracter.

Desde una vista global, si dividimos el código en bloques significativos podría quedar algo parecido a esto.

Basic blocks.

Ahora, para convertir el código ASM en código C, teniendo en cuenta todo lo anteriormente mencionado, hará falta especificar todo el proceso seguido por las instrucciones y porqué se están usando, qué están haciendo y a qué repercute. Teniendo todo esto se podrá hacer un código C que se adapte al completo. Teniendo en cuenta que al volver a compilar con GCC para x86 el código deberá de parecerse mucho, pero es posible que algunas direcciones de memoria usadas cambien, ya que todo esto es elegido por compilador según conveniencia.

 

Dump of assembler code for function main:

 

Dadas las siguientes instrucciones, parece ser al compilar con GCC (por ejemplo), tenía por defecto activada la característica de, protección PIE y alineamiento a 16 bytes.
Para la primera instrucción (en la que todavía no se ha llamado al main), el compilador antes de todo quiere alinear la pila a un alineamiento de 16-byte antes de insertar algo (push) en ella.
La explicación de por qué el compilador quiere alinear a 16-byte (128 bit) aunque es un poco más extenso, a groso modo es porque las instrucciones SSE2 (Single Instruction Multiple Data) especialmente usadas en computación avanzada (gráficos, codificación, decodificación, etc) están basadas en las instrucciones predecesoras SSE y MMX las cuales usaban paquetes de coma flotantes de 128 bit, es por lo que, el acceso a memoria de estas instrucciones necesita estar alineado de esta manera.
Por tanto, para alinear, primero guarda el offset de ESP (+4) en el registro ECX.
Al finalizar el programa se devolverá el valor de ECX a ESP.

0x565561b9 <+0>: lea ecx,[esp+0x4]

 

Segundo, se realiza una operación AND sobre el registro ESP con el valor de 0xfffffff0 y es que se busca mantener los 4 bits menos significativos a 0, esto es porque busca tener desplazamientos múltiplos de 16 bytes y para ello debe tener los 4 bits menos significativos a 0 (2^4 = 16).

0x565561bd <+4>: and esp,0xfffffff0

 

Una vez que ha realizado el correspondiente alineamiento, guarda en la pila el valor de offset que se guardó en la primera instrucción, para poder recuperarlo al final del programa y restablecer todos los cambios.

0x565561c0 <+7>: push DWORD PTR [ecx-0x4]

 

Guarda el valor del registro EBP en la pila de programa actual para poder recuperarlo al final de programa. En definitiva, está haciendo un backup de los registros que va a usar durante la ejecución del programa dado que no se quiere perder su valor.

0x565561c3 <+10>: push ebp

 

Una vez que ya ha guardado la dirección que contenía el registro EBP en la pila, ahora guardará el puntero a la pila de programa en EBP, y podrá utilizarlo como offset en las instrucciones a lo largo del programa.

0x565561c4 <+11>: mov ebp,esp

 

Guarda en la pila el valor de EBX y ECX para poder usar el registro durante el programa.
Ambos registros se reestablecerán al final de la ejecución del programa.

0x565561c6 <+13>: push ebx
0x565561c7 <+14>: push ecx

 

Una vez realizado el “backup” de los valores de los registros, empieza reservando el espacio en la pila para las variables locales que a continuación se declararán. Esta reserva es de 16 bytes, aunque no por eso signifique que se utilizará en su totalidad, es decir, sabemos que el compilador quiere que haya alineamiento en 16 bytes y, por tanto, puede quedar espacio sin usar. Dado que la pila “crece” hacia abajo (downwards) es por lo que usa la instrucción SUB. Dado que ESP va variando durante la ejecución, se usa el registro EBP (instrucción +11) para servir de ayuda, por tanto, cuando EBP = ESP la pila deja de tener memoria reservada.

0x565561c8 <+15>: sub esp,0x10

 

En este punto, utiliza la siguiente instrucción para satisfacer la protección PIE. Para ello, llama a <__x86.get_pc_thunk.bx> alojada en la dirección 0x565560c0 y guarda en EBX el valor del contador de programa de la siguiente instrucción, esto es: 0x565561d0 <+23>

0x565561cb <+18>: call 0x565560c0 <__x86.get_pc_thunk.bx>

 

Con la siguiente instrucción, EBX pasa de tener 0x565561d0 a 0x56559000, es decir, (0x565561d0 + 0x2e30).

0x565561d0 <+23>: add ebx,0x2e30

 

Carga la dirección efectiva de [EBX-0x1ff8], es decir setea la dirección de memoria de la cadena almacenada en dicha posición, esto es la dirección de memoria que apunta al primer caracter, al registro EAX. Recordando que EBX a su vez depende el PC (Program Counter) . Este registro es usado para operaciones aritméticas (probablemente se haga alguna operación con dicha cadena); de este modo, se usará más adelante como puntero que apunta al inicio de la cadena. Comienza el main.
Tenemos probablemente un char *.

0x565561d6 <+29>: lea eax,[ebx-0x1ff8] ; "allhacked.com"

 

Mueve la dirección de memoria (puntero) donde se encuentra la cadena anterior y lo almacenada en relación con el registro EBP.

0x565561dc <+35>: mov DWORD PTR [ebp-0x10],eax

 

Vuelve a reservar memoria en la pila. Un total de 12 bytes.

0x565561df <+38>: sub esp,0xc

 

Al reservar este espacio, puede meter en la pila el valor de EBP-0x10, que contiene el puntero a la cadena anterior. Esto debido a que varias convecciones de la arquitectura x86 pasan los valores de argumentos a través de la pila.

0x565561e2 <+41>: push DWORD PTR [ebp-0x10]

 

Llama a srtlen para calcular la longitud de la cadena, utilizando como parámetro de entrada el valor que acaba de ser metido en la pila. El valor 0x56556040 es una dirección absoluta donde estará la función.
El valor devuelto por strlen, se almacena en el registro EAX.

0x565561e5 <+44>: call 0x56556040 <strlen@plt>

 

Libera memoria de la pila, un total de 16 bytes. En este punto, ha liberado los 12 bytes que había reservado en <+38> +4 bytes del puntero (EBP-0x10). En este punto, el puntero ESP está como estaba después de <+41>, y además en EAX el valor de longitud devuelto por strlen.

0x565561ea <+49>: add esp,0x10

 

Guarda en memoria el valor de EAX que contiene la longitud en EBP-0x14, es decir, el tamaño de la cadena.

0x565561ed <+52>: mov DWORD PTR [ebp-0x14],eax

 

Vuelve a reservar memoria en la pila. Un total de 12 bytes.

0x565561f0 <+55>: sub esp,0xc

 

Carga la dirección efectiva de [EBX-0x1fe8], es decir setea la dirección de memoria de la cadena almacenada en dicha posición, esto es la dirección de memoria que apunta al primer caracter, al registro EAX. En definitiva igual que en <+29>. Como el valor de EAX pasó a la pila, ahora está libre.
Tenemos probablemente un char *.

0x565561f3 <+58>: lea eax,[ebx-0x1fe8] ; "Spell your favourite cybersecurity website:"

 

Guarda en la pila el valor de EAX, de igual forma, este método es usado para pasar por parámetro el valor a la subrutina puts.

0x565561f9 <+64>: push eax

 

Llama a la subrutina puts para imprimir por consola el valor pasado por la pila que contendrá el puntero apuntando al primer caracter del char*, se encargará de imprimir por consola toda la cadena hasta encontrar el \0.

0x565561fa <+65>: call 0x56556030 <puts@plt>

 

Vuelve a liberar memoria un total de 16 bytes.

0x565561ff <+70>: add esp,0x10

 

Guarda en memoria el valor 0 en EBP-0xc.

0x56556202 <+73>: DWORD PTR [ebp-0xc],0x0

 

Salto incondicional a <main+112>. Viendo la estructura de forma general se puede observar que que estamos en un bucle for, donde evaluará primero la condición y posteriormente ejecutará las intrucciones del cuerpo del bucle.

0x56556209 <+80>: jmp 0x56556229 <main+112>

 

Mueve el valor 0, 1, 2, etc. almacenado en EBP-0xc al registro EDX, este valor es el que se irá aumentando a lo largo del bucle.

0x5655620b <+82>: mov edx,DWORD PTR [ebp-0xc]

 

Tras mover en <+35> el valor de EAX (la longitud de la cadena), ahora se puede utilizar el registro, y en este punto, vuelve a mover a EAX el valor del puntero que apunta a la cadena “allhacked.com”.

0x5655620e <+85>: mov eax,DWORD PTR [ebp-0x10]

 

Al realizar la siguiente adición, donde a EAX (que tiene el puntero que apunta a la cadena “allhacked.com”) el valor de EDX (el acumulador del bucle for), lo que se consigue gracias a la aritmética de punteros, es desplazarnos por cada uno de los caracteres de la cadena.

0x56556211 <+88>: add eax,edx

 

Cargará un byte en AL el registro de 8 bits que conforma EAX y setea el resto de EAX a 0, en definitiva, en este caso, dejará todos los bits a 0 salvo el registro AL. Esta operación es sin signo.

0x56556213 <+90>: movzx eax,BYTE PTR [eax]

 

Y aquí, el valor de AL lo vuelve a mover a EAX, pero dejando el resto a 1, esta operación es con signo. Es lo mismo que derefenciar.
El tener ambas instrucciones juntas no aporta mucho sentido, probablemente porque el compilador no ha optimizado (probablemente sobre la primera instrucción).

0x56556216 <+93>: movsx eax,al

 

Vuelve a reservar memoria en la pila. Un total de 12 bytes.

0x56556219 <+96>: sub esp,0xc

 

Guarda en la pila el valor de EAX, de igual forma, este método es usado para pasar por parámetro el valor a la subrutina putchar.

0x5655621c <+99>: push eax

 

Llama a la subrutina putchar para imprimir por consola el caracter que es apuntado por la dirección EAX pasado por la pila, en cada vuelta este valor irá cambiando debido a las operaciones anteriores (desreferenciación) apuntando en cada momento a un caracter del char*.

0x5655621d <+100>: call 0x56556060 <putchar@plt>

 

Libera memoria un total de 16 bytes.

0x56556222 <+105>: add esp,0x10

 

Suma 1 al iterador del bucle.

0x56556225 <+108>: add DWORD PTR [ebp-0xc],0x1

 

En este punto del programa, mueve el valor de EBP-0xc al registro EAX para realizar operaciones aritméticas. En este caso, para realizar una comparación. En este punto, se ha podido llegar desde la ejecución normal de las instrucciones anteriores o desde el salto incondicional de <+80>.

0x56556229 <+112>: mov eax,DWORD PTR [ebp-0xc]

 

Al tener el valor en EAX se puede realizar la comparación con EBP-0x14 (la longitud de la cadena). La instrucción CMP realiza la resta de EAX – [EBP-0x18], si el resultado (que no afecta a los operandos) es negativo se activará el flag correspondiente, es decir, sería lo mismo que decir que A < B; en caso contrario, si el resultado es positivo significa que A > B.
Por tanto, si A < B el flag CF=1, si A > B, el flag CF=0.
Además, la instrucción CMP, activa otro flag llamado ZF, en el que, si los operandos son iguales, entonces el ZF=0, en caso contrario, ZF=1.
Ambos flags son valores de un registro específico que es usado como auxiliar en este tipo de operaciones. CF es el flag de llevada (Carry Flag) y ZF es el flag de cero (Zero Flag)

0x5655622c <+115>: cmp eax,DWORD PTR [ebp-0x14]

 

Finalmente, la instrucción JL (Jump if Less) se fijará en ambos registros (CF y ZF) y si A < B en el que tiene en cuenta el signo, saltará a <main+82>. En caso de que sea A >= B no saltará.

0x5655622f <+118>: jl 0x5655620b <main+82>

 

Vacía el registro EAX. Ya no se usará más.

0x56556231 <+120>: mov eax,0x0

 

Restaura ESP. Ahora apunta a lo que apuntaba en un principio.

0x56556236 <+125>: lea esp,[ebp-0x8]

 

Restaura todos los registros empezando por ECX ya que fue el último en guardarse en la pila, será el primero en salir y así sucesivamente.

0x56556239 <+128>: pop ecx
0x5655623a <+129>: pop ebx
0x5655623b <+130>: pop ebp

 

Se deshace los cambios que se hicieron al principio de la ejecución del programa y devuelve el control ret(urn).

0x5655623c <+131>: lea esp,[ecx-0x4]
0x5655623f <+134>: ret
End of assembler dump.

 

Finalmente ya hemos realizado el análisis del código ASM, ahora con esto falta montar el código C que al compilar volverá a dar este ASM.

El código C resultante sería:

#include <stdio.h>
#include <string.h>

int main()
{
    const char * website = {"allhacked.com"};
long int length = strlen(website);
printf("Spell your favourite cybersecurity website: \n");
for(long int i = 0; i < length; ++i)
{
printf("%c", website[i]);
}
return 0;
}

Para volver a compilar, y poder comparar (ensamblador-ensamblador) y ver si estamos en lo correcto, podemos hacer:

 $ gcc code.c -o code.out -m32

Para analizar dicho ejecutable, podríamos utilizar el conjunto de herramientas GDB (The GNU Debugger) y analizar dicho binario, pero podéis usar otros depuradores (hay bastantes muy buenos).

Los pasos con GDB sería:

 $ gdb
(gdb) file code.out
(gdb) break main
(gdb) set disassembly-flavor intel
(gdb) run
(gdb) disassemble

Al comparar pensad que algunas direcciones de memoria podrán cambiar ya que depende de varios factores, entre ellos de la versión de la compilador que se esté usando.

Todo esto es la “teoría” con un ejemplo muy pequeño (y fijáos si se ha alargado la cosa), pero en todo reversing influyen muchos factores que, para tanto al humano como a las herramientas, este análisis sea bastante complicado. Estos factores pueden ser optimizaciones, código inservible (de relleno)… y el peor, el ofuscamiento, ya sea con herramientas para ello o que el mismo programador inserte código ofuscado (algunas veces queriendo y otras no…).

Espero haberme explicado con claridad, que os haya gustado y que hayáis aprendido algo nuevo. Si alguien ve, que se me ha bailiado algo, ya sea una expresión o que he indicado que se hacía tal cosa en algún apunte, decidmelo. Siempre puedo corregirlo! 😉

Nos vemos en el siguiente post!

¡Feliz año 2020! 🎉 🎊



Happy Hacking!



Entra al grupo de allhacked!

Autor: Rafael Moreno López.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *