Reverse engineering of x86 Assembler code

Hello everybody!!

Today I bring you a topic that had been pending for some time and in a short time I was able to do something fast to be able to explain it as clearly as possible.

The term reversing is nothing more than an adaptation of the term reverse engineering that has been used for a long time and was mainly born in times of military confrontations as a means to investigate enemy technology. Although the term reverse engineering has always been used, in the field applied outside computer science, with the arrival of this, it was adapted to use.

Reversing or reverse engineering is the term coined to the reverse process applied to a final product, that is, starting from a design A to get a product B, this term is the reverse process, which starting from a product B to get the precious design A.

This task is not easy, in fact, it is one of the most complex disciplines in engineering.

For today’s case, in which we will focus on a piece of x86 code from the C/C++ language, I would like to explain it clearly so that you can stay with the maximum detail and learn something new, however, this is not a guide because compressing years of research, different architectures, variants, compilers, optimizations, etc. in something brief it is complicated. If someone likes this topic, which for me is very interesting, there are quite a few very interesting books on the net.

We must keep in mind an important aspect and that is that throughout history, from the first compiler to the most modern today, there have been many changes, in all aspects of this engineering (which must be fed to part) and that will continue advancing in increasing steps. It’s hard to follow the thread, but it’s harder to keep up; but don’t worry, unless you dedicate yourself or want to dedicate yourself to this, you have no major problem, the basic theory “remains” the same.

The next x86 (32 bit) architecture snippet comes from a C/C++ code, in which we will analyze it statically with Intel syntax and without tools. The decision not to use tools lies in the fact that the tools aren’t always going to save us in all cases and therefore on certain occasions, we will have to use our own knowledge to complete the puzzle. With this example, I repeat, it doesn’t go far, but to see a little in detail what could be a real example (very summarized).

Ok, we have the following 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.

Before we begin, we will take a quick look at the code. With this analysis we will get into a situation, such as: the way in which it has been compiled, if it has debug information, some optimization, etc.

You can verify that it has been compiled in 32-bit because the registers used are 32-bit of size.
These 32-bit registers are:

  • Data registers: EAX, EBX, ECX and EDX.
  • Pointer registers: ESP and EBP.

To give some sense to these records, all the registers that are interrelated are shown in the following table.
For example, you can see how the 32-bit EAX register is made up of the 16-bit AX register and the 8-bit AH and AL registers each. The 16 and 8-bit registers are specific to the 16 and 8-bit architectures respectively. Following this similarity, you can see how the EBX, ECX and EDX registers are formed.

Register 32 bit table.

Each of these registers has a specific use.

  • The EAX register (AX, AH and AL depending on the architecture) is usually called the “primary accumulator” used for input/output operations and most arithmetic operations.
  • The EBX register (BX, BH and BL) also known as the base register, as it is used in address indexing.
  • The ECX register (CX, CH and CL) is the counter register, and stores the account in cyclic iterative operations.
  • The EDX register (DX, DH and DH) is the data register, and it is used in input/output operations. Its use is for operations and sometimes is used together with the “primary accumulator” for multiply and divide operations that can result in large values.

Similarly, the pointer registers.

Pointer Register 32 bit table.
  • The ESP register (SP for 16-bit architecture) provides the offset value within the program stack, that is, this register contains the pointer to the top of the program stack and is used to access the program stack using the value of this register and an offset value, in order to access different parts of it.
  • The EBP register (BP in 16-bit architecture) is mainly used to reference variables that can be passed by parameter to a subroutine, it is also used to store variables. Point to the current base of the stack frame.

After this, we continue to analyze the mnemonic instructions in general, of the ASM code.

As you can see, there are different calls to subroutines (using the CALL instruction).

  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.

Leave a Reply

Your email address will not be published. Required fields are marked *