Write up Missile Launch – Reversing con un toque estegano

Write up realizado por Javi Tallón (jtsec.es). Enlace del reto

Descripción del reto:
El equipo reverser PKTeam del país Fwhibbit ha podido obtener un binario del país enemigo Vulpensa. Según la información obtenida el binario oculta la flag con una pequeña ofuscación provocando que nadie obtenga acceso sin autorización a los códigos de lanzamientos de misiles del ejercito de Vulpensa. 
Ayuda al equipo reverser a poder dar con la flag que será vital para la vida del los fwhibbitenses y evitar un conflicto!

Cuando Naivenom prometió a través del grupo de Telegram de la Comunidad Fwhibbit una camiseta de los Conejos al primero que resolviera este reto no dudé ni un momento, solté en lo que estaba trabajando y me puse manos a la obra: ¡necesitaba esa camiseta!

Llevando ya más de una década trabajando en ciberseguridad, es una verdadera alegría descubrir como este grupo de gente se esfuerza por hacer más accesible a todo el mundo un conocimiento que antaño era tratado bajo un halo de secretismo y mística, como si fuesen artes oscuras y gracias a iniciativas como este blog el nivel de los profesionales en ciberseguridad en España no deja de subir. ¡Al final ganamos todos!

¡Pero basta de palabrería y pongámonos manos a la obra! El reto consistía en un reversing de un binario en ARMv7, el procesador de la Raspberry Pi 2. Yo tengo un par de ellas en casa, haciendo funciones de Media Center con Kodi, y la verdad me daba bastante pereza desarmar el tinglado para ponerme a hacer el reto. 

Afortunadamente ya había emulado con anterioridad binarios de ARM en mi máquina y era bastante sencillo montar un entorno con qemu.

Examinando el fichero con file era posible ver que efectivamente se trataba de un binario compilado para ARM, que poseía símbolos y que lamentablemente estaba compilado dinámicamente, así que es posible que nos diera algún problemilla con las librerías:

Así que, sin más dilación, instalamos qemu con soporte para ARM:

Así como el paquete qemu-user que nos proporciona emulación de manera transparente, permitiendo la ejecución de binarios no nativos como el que tenemos que analizar.

Ahora sí ya podíamos intentar ejecutar el binario emulado en nuestro sistema:

Lamentablemente como habíamos predicho, al estar el binario enlazado dinámicamente, necesita la presencia de ciertas librerías en el sistema, y puesto que nuestra máquina corre bajo una arquitectura x86, estas no están disponibles.

Para solucionar este inconveniente utilizaremos la herramienta apt-file que nos dirá si el fichero que nos falta se encuentra disponible en algún paquete de nuestra distribución de Linux. Cruzamos los dedos y…:

Bingo! Instalamos el paquete para tener la librería que nos falta que como podéis ver es el enlazador dinámico de Linux pero para la arquitectura ARM:

Normalmente un binario compilado dinámicamente no solo necesita el enlazador dinámico, sino que utilizará otras muchas librerías, o como mínimo, si se trata de un binario sencillo, la libc. Podemos comprobar que librerías están enlazadas usando objdump:

Donde vemos que la única necesaria es libc.so.6, que ya es proporcionada por el paquete que recién acabamos de instalar.

De esta manera, únicamente tendremos que decirle a qemu que se ejecute usando como path la ruta donde se encuentran los binarios de las bibliotecas de ARM que acabamos de instalar:

Yuju! ¡Ya no tendré que desmontar mi Media Center!

El binario parece que pide una flag por pantalla, cuando introducimos un valor erroneo, nos contesta con un “Nope:(.” mientras que supuestamente, si metemos el valor bueno, nos devolverá la flag que da solución al reto.

Además, qemu nos permite realizar debugging con gdb siempre que tengamos instalado el paquete gdb-multiarch. Para ello lanzamos el ejecutable de la siguiente manera, especificando el puerto de escucha:

Mientras que en otra consola ejecutamos gdb-multiarch (apt-get install gdb-multiarch) y realizamos los siguientes pasos:

• Especificamos la arquitectura (ser arch arm)
• Especificamos la ruta donde están las bibliotecas dinámicas (set sysroot /usr/arm-linux-gnueabihf/)
• Cargamos el fichero (file rev3_fwr)
• Nos conectamos a qemu en el puerto que está escuchando (target remote localhost:1234).

Podemos probar que todo va correctamente poniendo un breakpoint en la dirección de main:

Otra opción muy interesante que nos puede proporcionar información es el uso del strace integrado en qemu, al que podemos acceder pasando a qemu-arm el parámetro -strace.

Para la parte de análisis estático me hubiera encantado poder usar IDA Pro, el entorno con el que me encuentro más cómodo, sin embargo, la versión free no soporta la arquitectura ARM, así que, puesto que se debía tratar de un binario sencillo, decidí darle una oportunidad a Hopper, cuya versión demo si que soporta tanto x86 como ARMv7, aunque tiene la peculiaridad de que se cierra a los 30 minutos de uso, así que tendremos que ser rápidos 😀

Descargando Hopper de su web y ejecutándolo, pasamos a abrir el fichero que queremos analizar. La pestaña Procs nos permite acceder fácilmente a la lista de procedimientos que el desensamblador ha encontrado en el binario, así que vamos a ver qué encontramos en el main del programa:

Hopper por defecto muestra una vista del código desensamblado, pero pulsando espacio nos mostrará un diagrama de bloques básicos como hace el viejo IDA.

ARM se caracteriza por ser una arquitectura de tipo RISC (Reduced Instruction Set Computer) en contraposición a X86, que es de tipo CISC (Complex Instruction Set Computer), y por ello podemos observar fácilmente que el número de diferentes instrucciones es mucho menor en ARM que en x86.  Es por esto que los binarios de ARM suelen ocupar más que los mismos compilados para x86.

En ARM básicamente encontraremos funciones para cargar/guardar valores de memoria a registro (LDR/STR), y las ya conocidas funciones de acceso a la pila (PUSH/POP), aritmética (ADD/SUB/MUL/…) o lógicas y de salto (B/BL). El cheatsheet que acompaña al reto es muy útil y me lo guardo para la colección!

Otra característica de los procesadores ARM es la presencia de dos modos de operación, el normal de 32 bits, o el llamado thumb-mode de 16 bits. Es posible saltar de un modo a otro con los mnemónicos BX o BLX y podemos fácilmente saber si estamos en thumb mode o no porque en thumb mode las direcciones de memoria son impares. Afortunadamente parece que todo el código que nos afecta está en modo normal (instrucciones de memoria pares :D).

Podemos también observar que el número de registros es mucho mayor en la arquitectura ARM que en x86, contando con 16 registros (r0-r15), siendo r15 el que se utiliza como contador de programa mientras que r14 es usado para almacenar la dirección desde la que se ejecutó el último BL y poder continuar la ejecución fácilmente tras una llamada a función.  R11 es usado como frame pointer y aparece nombrado como fp en Hopper.

Según la convención de llamada usada en ARM 32 bits los argumentos de las funciones van por orden en los primeros registros de propósito general r0 a r3 (caller saved) mientras que los registros r4 a r11 (callee saved) se usan para alojar las variables locales y el valor de retorno se devuelve en los registros r0 a r3.

Sabiendo esto y dando un vistazo de alto nivel al primer bloque básico es posible observar cómo:

• 0x104c0 llama a la función puts para mostrar la cadena “M i s s i l e  l a u n c h  c o d e   by @n4ivenom fwr{} Rev”
• 0x104c4 se carga en R14 (LR) la dirección 0x106d8 y se van inicializando una serie de variables locales que apuntan a direcciones a partir 0x106d8, o dicho de otra manera, se inicializan de manera estática.
• 0x104ec idem pero inicializando a partir de 0x106ec. Probablemente se estén creando dos vectores de bytes estáticos en #0x20 y #0x34 respectivamente. 
• 0x10518 llama a la función printf para pintar “>>>”
• 0x10524 llama a gets para obtener la entrada del usuario con la flag
• 0x10528 carga en una variable local (#-0x8) el valor apuntado por el vector de #0x34
• 0x10530 salta de manera incondicional a 0x10550

Además, es posible ver un par de bucles que seguramente sean los responsables de que la solución no aparezca como una cadena de texto…

El siguiente bloque básico interesante es el que comienza en 0x10560 y en él se llama a la función strcmp utilizando la entrada del usuario y el valor correcto de la flag calculado en el anterior bloque básico.

strcmp devuelve en r0 el resultado y el compilador lo ha movido a r3 antes de compararlo con cero, de manera que si la respuesta es incorrecta se saltará a 0x105cc donde se mostrará el mensaje “Nope:(.” y si es correcta se continuará la ejecución. 

Una aproximación rápida para resolver el reto sería modificar el resultado del strcmp para que nos devolviera la flag poniendo un breakpoint en la dirección dónde se compara el resultado devuelto por la comparación (break *main+204) y redirigiendo el flujo a donde se pinta el flag (set $pc=0x10580), sin embargo, el resultado no es el esperado:

Parece que nos va a tocar profundizar en el análisis estático…

En ARM es muy frecuente encontrar indirecciones cortas como las que hemos visto ya que normalmente las constantes se almacenan al final de cada función donde se usan en unas estructuras llamadas pool de constantes o de literales.

En concreto, como hemos visto, los datos sobre los que se realizan las operaciones son cargados desde 0x106d8 y desde 0x106ec, y el desensamblador los detecta como enteros de 4 bytes (dd). Puesto que probablemente se trate uno de una serie de enteros sino de una cadena de bytes vamos pidiéndole a Hopper que los ponga como bytes (db). 

Por suerte los shortcuts son los mismos que en IDA Pro y podemos conseguirlo pulsando sobre la letra ‘d’.

De esta manera nos queda el siguiente array de datos:

0x106d8 = C6 D7 D2 DB A9 CC C9 CB C5 BF C3 CF C4 C5 AD AC DD 00 00 00 –>#0x20
0x106ec = B4 C8 C9 D3 A9 D3 B4 C8 C5 BF B0 C1 D3 D3 B7 A4 B4 00 00 00 –> #0x34

A partir de ahí podemos observar un bucle que itera utilizando como contador la variable local #-0x8 que recordemos apuntaba al vector en #0x34 hasta que encuentre un 0 en la memoria apuntada, y va incrementando de uno en uno, mientras que realiza una transformación de los valores incrementando cada byte en 0x60 y quitándole el resto (extendiendo a cero):

R3 = [#0x08]
R3 = Byte([R3])

Si es 0 para, si no:

R3 = [#0x08]
R2 = R3+1
[#0x08] = R2
R2 = Byte([R3])
R2 = R2+0x60
R2 = ZeroExtendByte(R2)
[R3] = R2

Luego se realiza el strcmp y en el caso de que la solución sea correcta, se realiza un bucle equivalente al que hemos visto antes pero usando como puntero la variable en #0x0c y con el contenido almacenado en #0x20, que recordemos era inicializado a partir de lo que vemos en 0x106d8 y que finalmente dará como resultado que se muestre la flag que resuelve el reto: