Rhinoceros dentro del gato: ejecute el firmware en el emulador Kopycat

En el marco de la reunión 0x0A DC7831 DEF CON Nizhny Novgorod el 16 de febrero, presentamos un informe sobre los principios básicos de la emulación de código binario y nuestro propio desarrollo: un emulador de plataformas de hardware Kopycat .

En el artículo, describiremos el lanzamiento del firmware del dispositivo en el emulador, demostraremos la interacción con el depurador y realizaremos un pequeño análisis dinámico del firmware.

Antecedentes

Hace mucho tiempo en una galaxia muy muy lejana

Hace un par de años en nuestro laboratorio era necesario estudiar el firmware del dispositivo. El firmware fue comprimido, descomprimido por el gestor de arranque. Lo hizo de una manera muy confusa, varias veces cambiando datos en la memoria. Sí, y el firmware en sí mismo interactuó activamente con los periféricos. Y todo esto en el núcleo de MIPS.

Por razones objetivas, los emuladores existentes no nos convenían, pero aún así quería ejecutar el código. Luego decidimos hacer nuestro propio emulador, que hará un mínimo y permitirá descomprimir el firmware principal. Lo intentamos, resultó. Pensamos, ¿y si agregamos periféricos para también realizar el firmware principal? No fue muy doloroso, y también funcionó. Pensamos de nuevo y decidimos hacer un emulador completo.

El resultado fue un emulador de sistemas informáticos Kopycat .

Kopycat

Al crear el emulador, se establecieron objetivos absolutamente específicos:

• la capacidad de crear rápidamente una nueva periferia, módulo, núcleo de procesador;
• la capacidad de ensamblar un dispositivo virtual desde varios módulos;
• la capacidad de cargar cualquier dato binario (firmware) en la memoria del dispositivo virtual;
• la capacidad de trabajar con instantáneas (instantáneas del estado del sistema);
• la capacidad de interactuar con el emulador a través del depurador incorporado;
• Agradable lenguaje moderno para desarrollar.

Como resultado, Kotlin fue elegido para la implementación, la arquitectura del bus (esto es cuando los módulos se comunican entre sí a través de buses de datos virtuales), JSON como el formato de descripción del dispositivo y GDB RSP como el protocolo para interactuar con el depurador.

El desarrollo ha estado ocurriendo durante un poco más de dos años y está en curso. Durante este tiempo, se implementaron los núcleos de procesador MIPS, x86, V850ES, ARM, PowerPC.

El proyecto está creciendo y es hora de presentarlo al público en general. Haremos una descripción detallada del proyecto más adelante, pero ahora nos centraremos en usar Kopycat.

Para los más impacientes: la versión promocional del emulador se puede descargar aquí .

Rhino en el emulador

Recuerde que anteriormente para la conferencia SMARTRHINO-2018, se creó un dispositivo de prueba "Rhinoceros" para la capacitación en habilidades de ingeniería inversa. El proceso de análisis de firmware estático se describió en este artículo .

Ahora intentemos agregar "altavoces" y ejecutar el firmware en el emulador.

Necesitaremos:
1) Java 1.8
2) Python y el módulo Jep para usar Python dentro del emulador. El ensamblaje WHL del módulo Jep para Windows se puede descargar aquí .

Para Windows:
1) com0com
2) PuTTY

Para Linux:
1) socat

Puede usar Eclipse, IDA Pro o radare2 como cliente GDB.

Como funciona

Para realizar el firmware en el emulador, debe "ensamblar" un dispositivo virtual, que es un análogo de un dispositivo real.

El dispositivo real ("rinoceronte") se puede mostrar en un diagrama de bloques:

El emulador tiene una estructura modular y el dispositivo virtual final se puede describir en un archivo JSON.

{ "top": true, // Plugin name should be the same as file name (or full path from library start) "plugin": "rhino", // Directory where plugin places "library": "user", // Plugin parameters (constructor parameters if jar-plugin version) "params": [ { "name": "tty_dbg", "type": "String"}, { "name": "tty_bt", "type": "String"}, { "name": "firmware", "type": "String", "default": "NUL"} ], // Plugin outer ports "ports": [ ], // Plugin internal buses "buses": [ { "name": "mem", "size": "BUS30" }, { "name": "nand", "size": "4" }, { "name": "gpio", "size": "BUS32" } ], // Plugin internal components "modules": [ { "name": "u1_stm32", "plugin": "STM32F042", "library": "mcu", "params": { "firmware:String": "params.firmware" } }, { "name": "usart_debug", "plugin": "UartSerialTerminal", "library": "terminals", "params": { "tty": "params.tty_dbg" } }, { "name": "term_bt", "plugin": "UartSerialTerminal", "library": "terminals", "params": { "tty": "params.tty_bt" } }, { "name": "bluetooth", "plugin": "BT", "library": "mcu" }, { "name": "led_0", "plugin": "LED", "library": "mcu" }, { "name": "led_1", "plugin": "LED", "library": "mcu" }, { "name": "led_2", "plugin": "LED", "library": "mcu" }, { "name": "led_3", "plugin": "LED", "library": "mcu" }, { "name": "led_4", "plugin": "LED", "library": "mcu" }, { "name": "led_5", "plugin": "LED", "library": "mcu" }, { "name": "led_6", "plugin": "LED", "library": "mcu" }, { "name": "led_7", "plugin": "LED", "library": "mcu" }, { "name": "led_8", "plugin": "LED", "library": "mcu" }, { "name": "led_9", "plugin": "LED", "library": "mcu" }, { "name": "led_10", "plugin": "LED", "library": "mcu" }, { "name": "led_11", "plugin": "LED", "library": "mcu" }, { "name": "led_12", "plugin": "LED", "library": "mcu" }, { "name": "led_13", "plugin": "LED", "library": "mcu" }, { "name": "led_14", "plugin": "LED", "library": "mcu" }, { "name": "led_15", "plugin": "LED", "library": "mcu" } ], // Plugin connection between components "connections": [ [ "u1_stm32.ports.usart1_m", "usart_debug.ports.term_s"], [ "u1_stm32.ports.usart1_s", "usart_debug.ports.term_m"], [ "u1_stm32.ports.usart2_m", "bluetooth.ports.usart_m"], [ "u1_stm32.ports.usart2_s", "bluetooth.ports.usart_s"], [ "bluetooth.ports.bt_s", "term_bt.ports.term_m"], [ "bluetooth.ports.bt_m", "term_bt.ports.term_s"], [ "led_0.ports.pin", "u1_stm32.buses.pin_output_a", "0x00"], [ "led_1.ports.pin", "u1_stm32.buses.pin_output_a", "0x01"], [ "led_2.ports.pin", "u1_stm32.buses.pin_output_a", "0x02"], [ "led_3.ports.pin", "u1_stm32.buses.pin_output_a", "0x03"], [ "led_4.ports.pin", "u1_stm32.buses.pin_output_a", "0x04"], [ "led_5.ports.pin", "u1_stm32.buses.pin_output_a", "0x05"], [ "led_6.ports.pin", "u1_stm32.buses.pin_output_a", "0x06"], [ "led_7.ports.pin", "u1_stm32.buses.pin_output_a", "0x07"], [ "led_8.ports.pin", "u1_stm32.buses.pin_output_a", "0x08"], [ "led_9.ports.pin", "u1_stm32.buses.pin_output_a", "0x09"], [ "led_10.ports.pin", "u1_stm32.buses.pin_output_a", "0x0A"], [ "led_11.ports.pin", "u1_stm32.buses.pin_output_a", "0x0B"], [ "led_12.ports.pin", "u1_stm32.buses.pin_output_a", "0x0C"], [ "led_13.ports.pin", "u1_stm32.buses.pin_output_a", "0x0D"], [ "led_14.ports.pin", "u1_stm32.buses.pin_output_a", "0x0E"], [ "led_15.ports.pin", "u1_stm32.buses.pin_output_a", "0x0F"] ] } 

Un dispositivo virtual y su interacción con el sistema operativo principal se pueden representar de la siguiente manera:

La instancia de prueba actual del emulador implica la interacción con los puertos COM del sistema operativo principal (depuración UART y UART para el módulo Bluetooth). Estos pueden ser puertos reales a los que están conectados los dispositivos o puertos COM virtuales ( com0com / socat es solo para esto ) .

Actualmente hay dos formas principales de interactuar con el emulador desde el exterior:

• Protocolo GDB RSP (respectivamente, compatible con este protocolo, herramientas: Eclipse / IDA / radare2);
• línea de comando interna del emulador (Argparse o Python).

Puertos COM virtuales

Para interactuar con el UART del dispositivo virtual en la máquina local a través del terminal, debe crear un par de puertos COM virtuales conectados. En nuestro caso, un puerto usa un emulador y el segundo un programa de terminal (PuTTY o pantalla):

Usando com0com

Los puertos COM virtuales se configuran con la utilidad de configuración del kit com0com (la versión de la consola es C: \ Archivos de programa (x86) \ com0com \ setup.exe, o la versión de la GUI es C: \ Archivos de programa (x86) \ com0com \ setupg.exe ) :

Marque las casillas de verificación de desbordamiento del búfer de habilitación para todos los puertos virtuales creados; de lo contrario, el emulador esperará una respuesta del puerto COM.

Usando socat

En los sistemas UNIX, el emulador crea automáticamente puertos COM virtuales utilizando la utilidad socat, para esto es suficiente especificar el prefijo socat: en el nombre del puerto al iniciar el emulador.

Interfaz de línea de comando interna (Argparse o Python)

Como Kopycat es una aplicación de consola, el emulador proporciona dos opciones para que la interfaz de línea de comandos interactúe con sus objetos y variables: Argparse y Python.

Argparse es la CLI integrada en Kopycat, siempre está disponible para todos.

Una CLI alternativa es el intérprete de Python. Para usarlo, debe instalar el módulo Jep Python y configurar el emulador para que funcione con Python (se utilizará el intérprete de Python instalado en el sistema principal del usuario).

Instalar el módulo Python Jep

Bajo Linux, Jep se puede instalar a través de pip:

 pip install jep 

Para instalar Jep en Windows, primero debe instalar el SDK de Windows y el Microsoft Visual Studio correspondiente. Simplificamos un poco su tarea e hicimos ensamblajes WHL JEP para las versiones actuales de Python para Windows, para que el módulo se pueda instalar desde un archivo:

 pip install jep-3.8.2-cp27-cp27m-win_amd64.whl 

Para verificar la instalación de Jep, debe ejecutar la línea de comando:

 python -c "import jep" 

En respuesta, se debe recibir un mensaje:

 ImportError: Jep is not supported in standalone Python, it must be embedded in Java. 

En el archivo por lotes del emulador para su sistema ( kopycat.bat para Windows, kopycat para Linux) agregue el parámetro adicional Djava.library.path a la lista de parámetros DEFAULT_JVM_OPTS ; debe contener la ruta al módulo Jep instalado.

Como resultado, para Windows, debería obtener una línea como esta:

 set DEFAULT_JVM_OPTS="-XX:MaxMetaspaceSize=256m" "-XX:+UseParallelGC" "-XX:SurvivorRatio=6" "-XX:-UseGCOverheadLimit" "-Djava.library.path=C:/Python27/Lib/site-packages/jep" 

Lanzamiento de Kopycat

El emulador es una aplicación JVM de consola. El lanzamiento se realiza a través de la secuencia de comandos de la línea de comandos del sistema operativo (sh / cmd).

Comando para ejecutar bajo Windows:

 bin\kopycat -g 23946 -n rhino -l user -y library -p firmware=firmware\rhino_pass.bin,tty_dbg=COM26,tty_bt=COM28 

El comando para ejecutar en Linux usando la utilidad socat:

 ./bin/kopycat -g 23946 -n rhino -l user -y library -p firmware=./firmware/rhino_pass.bin,tty_dbg=socat:./COM26,tty_bt=socat:./COM28 

• -g 23646 : puerto TCP que estará abierto para acceder al servidor GDB;
• -n rhino : el nombre del módulo principal del sistema (ensamblaje del dispositivo);
• -l user : el nombre de la biblioteca para buscar el módulo principal;
• -y library : la ruta para buscar los módulos incluidos en el dispositivo;
• firmware\rhino_pass.bin - ruta al archivo de firmware;
• COM26 y COM28 son puertos COM virtuales.

El resultado será el Argparse > Python > (o Argparse > ):

 18:07:59 INFO [eFactoryBuilder.create ]: Module top successfully created as top 18:07:59 INFO [ Module.initializeAndRes]: Setup core to top.u1_stm32.cortexm0.arm for top 18:07:59 INFO [ Module.initializeAndRes]: Setup debugger to top.u1_stm32.dbg for top 18:07:59 WARN [ Module.initializeAndRes]: Tracer wasn't found in top... 18:07:59 INFO [ Module.initializeAndRes]: Initializing ports and buses... 18:07:59 WARN [ Module.initializePortsA]: ATTENTION: Some ports has warning use printModulesPortsWarnings to see it... 18:07:59 FINE [ ARMv6CPU.reset ]: Set entry point address to 08006A75 18:07:59 INFO [ Module.initializeAndRes]: Module top is successfully initialized and reset as a top cell! 18:07:59 INFO [ Kopycat.open ]: Starting virtualization of board top[rhino] with arm[ARMv6Core] 18:07:59 INFO [ GDBServer.debuggerModule ]: Set new debugger module top.u1_stm32.dbg for GDB_SERVER(port=23946,alive=true) Python > 

Interacción con IDA Pro

Para simplificar las pruebas, utilizamos el firmware de Rhino como un archivo ELF (la metainformación se guarda allí) como el archivo fuente para el análisis en IDA.

También puede usar el firmware principal sin metainformación.

Después de iniciar Kopycat en IDA Pro, en el menú Depurador, vaya al elemento " Cambiar depurador ... " y seleccione " Depurador de GDB remoto ". A continuación, configure la conexión: Menú del depurador - Opciones de proceso ...

Establecer los valores:

• Aplicación - cualquier valor
• Nombre de host: 127.0.0.1 (o la dirección IP de la máquina remota donde se ejecuta Kopycat)
• Puerto: 23946

Ahora el botón de inicio de depuración está disponible (tecla F9):

Presiónelo: se conecta al módulo depurador en el emulador. IDA entra en modo de depuración, ventanas adicionales están disponibles: información sobre registros, sobre la pila.

Ahora podemos usar todas las características estándar de trabajar con el depurador:

• ejecución paso a paso de instrucciones ( Paso a paso y Paso a paso - teclas F7 y F8, respectivamente);
• iniciar y pausar la ejecución;
• creando puntos de interrupción tanto en código como en datos (tecla F2).

Conectarse al depurador no significa iniciar el código de firmware. La posición actual para la ejecución debe ser la dirección 0x08006A74 , el comienzo de la función Reset_Handler . Si se desplaza hacia abajo en la lista a continuación, puede ver la llamada a la función principal . Puede colocar el cursor en esta línea (dirección 0x08006ABE ) y ejecutar la operación Ejecutar hasta el cursor (tecla F4).

A continuación, puede presionar F7 para ingresar a la función principal .

Si ejecuta el comando Continuar proceso (tecla F9), la ventana "Espere" aparecerá con un solo botón Suspender :

Cuando se presiona Suspender , la ejecución del código de firmware se suspende y puede continuar desde la misma dirección en el código donde se interrumpió.

Si continúa ejecutando el código, en las terminales conectadas a los puertos COM virtuales, puede ver las siguientes líneas:

La presencia de la cadena "omisión de estado" indica que el módulo Bluetooth virtual ha cambiado al modo de recepción de datos desde el puerto COM del usuario.

Ahora en el terminal Bluetooth (en la figura - COM29) puede ingresar comandos de acuerdo con el protocolo Rhino. Por ejemplo, la cadena "mur-mur" vuelve al comando "MEOW" en el terminal Bluetooth:

Emularme no completamente

Al construir un emulador, puede elegir el grado de detalle / emulación de un dispositivo. Entonces, por ejemplo, el módulo Bluetooth se puede emular de diferentes maneras:

• dispositivo completamente emulado con un conjunto completo de comandos;
• Los comandos AT se emulan y el flujo de datos se recibe desde el puerto COM del sistema principal;
• dispositivo virtual proporciona redirección de datos completa a un dispositivo real;
• como un trozo simple que siempre devuelve "OK".

En la versión actual del emulador, se utiliza el segundo enfoque: el módulo Bluetooth virtual realiza la configuración, luego de lo cual cambia al modo "proxy" de datos desde el puerto COM del sistema principal al puerto UART del emulador.

Considere la posibilidad de instrumentación simple del código si alguna parte de la periferia no está implementada. Por ejemplo, si no se crea un temporizador que controle la transferencia de datos en DMA (la verificación se realiza en la función ws2812b_wait ubicada en 0x08006840 ), el firmware siempre esperará a que el indicador de ocupado ubicado en 0x200004C4 restablezca la línea de datos DMA:

Podemos sortear esta situación restableciendo manualmente el indicador de ocupado inmediatamente después de configurarlo. En IDA Pro, puede crear una función de Python y llamarla en punto de interrupción, y el punto de interrupción debe establecerse en el código después de escribir el valor 1 en el indicador ocupado .

Controlador de punto de interrupción

Primero, cree una función Python en la IDA. Menú Archivo - Comando de script ...

Agregue un nuevo fragmento en la lista de la izquierda, asígnele un nombre (por ejemplo, BPT ),
En el cuadro de texto a la derecha, ingresamos el código de función:

 def skip_dma(): print "Skipping wait ws2812..." value = Byte(0x200004C4) if value == 1: PatchDbgByte(0x200004C4, 0) return False 

Después de eso, haga clic en Ejecutar y cierre la ventana del script.

Ahora vamos al código en 0x0800688A , establezca el punto de interrupción (tecla F2), 0x0800688A ( Editar punto de interrupción ... menú contextual), no olvide establecer el tipo de script - Python:

Si el valor actual de la bandera de ocupado es 1, entonces la función skip_dma debe ejecutarse en la línea de script:

Si ejecuta el firmware para su ejecución, el código del controlador de punto de interrupción se puede ver en el IDA en la ventana Salida en la línea Skipping wait ws2812... Ahora el firmware no esperará para restablecer el indicador de ocupado .

Interacción del emulador

La emulación por el bien de la emulación es poco probable que cause deleite y alegría. Es mucho más interesante si el emulador ayuda al investigador a ver los datos en la memoria o a establecer la interacción de los flujos.

Mostramos cómo establecer dinámicamente la interacción de las tareas RTOS. Primero, pause la ejecución del código si se está ejecutando. Si cambia a la función bluetooth_task_entry en la rama de procesamiento de comandos "LED" (dirección 0x080057B8 ), puede ver lo que se creó primero y luego se envía un mensaje a la cola del sistema ledControlQueueHandle .

Debe establecer el punto de interrupción para acceder a la variable ledControlQueueHandle ubicada en 0x20000624 y continuar ejecutando el código:

Como resultado, al principio se detendrá en la dirección 0x080057CA antes de llamar a la función osMailAlloc , luego a 0x08005806 antes de llamar a la función osMailPut , luego después de un tiempo en la dirección 0x08005BD4 (antes de llamar a la función osMailGet ), que pertenece a la función leds_task_entry (tarea LED), es decir hubo un cambio de tarea, y ahora el control ha recibido la tarea LED.

De una manera tan simple, puede establecer cómo las tareas RTOS interactúan entre sí.

Por supuesto, en realidad, la interacción de tareas puede ser más complicada, pero usar un emulador para rastrear esta interacción se vuelve menos difícil.

Aquí puede ver un breve video del lanzamiento del emulador y la interacción con IDA Pro.

Lanzamiento con Radare2

No puede ignorar una herramienta tan universal como Radare2.

Para conectarse al emulador usando r2, el comando se verá así:

 radare2 -A -a arm -b 16 -d gdb://localhost:23946 rhino_fw42k6.elf 

Ahora el inicio ( dc ) y la ejecución de pausa (Ctrl + C) están disponibles.

Desafortunadamente, en este momento en r2 hay problemas al trabajar con un servidor gdb de hardware y marcado de memoria, debido a esto, los puntos de interrupción y los Pasos (el comando ds ) no funcionan. Esperamos que esto se solucione en el futuro cercano.

Lanzamiento con Eclipse

Una de las opciones para usar el emulador es depurar el firmware del dispositivo en desarrollo. Para mayor claridad, también utilizaremos el firmware de Rhino. Puede descargar las fuentes de firmware desde aquí .

Utilizaremos el Eclipse del System Workbench para la suite STM32 como IDE.

Para que el firmware compilado directamente en Eclipse se cargue en el emulador, debe agregar el parámetro firmware=null al comando de inicio del emulador:

 bin\kopycat -g 23946 -n rhino -l user -y library -p firmware=null,tty_dbg=COM26,tty_bt=COM28 

Configuración de depuración

En Eclipse, seleccione el menú Ejecutar - Configuraciones de depuración ... En la ventana que se abre, en la sección Depuración de hardware de GDB , debe agregar una nueva configuración y luego especificar el proyecto y la aplicación actual para la depuración en la pestaña "Principal":

En la pestaña Depurador, debe especificar el comando GDB:
${openstm32_compiler_path}\arm-none-eabi-gdb

Y también ingrese los parámetros para conectarse al servidor GDB (host y puerto):

Los siguientes parámetros deben especificarse en la pestaña "Inicio":

• active la casilla de verificación Cargar imagen (para que la imagen de firmware ensamblada se cargue en el emulador);
• active la marca de verificación Cargar símbolos ;
• agregue un comando de inicio: set $pc = *0x08000004 (establezca el valor de la memoria en el registro de la PC en la dirección 0x08000004 : la dirección de 0x08000004 se almacena allí).

Tenga en cuenta que si no desea descargar el archivo de firmware de Eclipse, no necesita especificar los parámetros Cargar imagen y Ejecutar comandos .

Después de hacer clic en Depurar, puede trabajar en modo de depuración:

• ejecución de código paso a paso
  
• interacción con puntos de interrupción
  

Nota Eclipse tiene, hmm ... algunas características ... y tienes que vivir con ellas. Por ejemplo, si aparece el mensaje "No hay fuente disponible para" 0x0 "" al iniciar el depurador, ejecute el comando Paso (F5)

En lugar de una conclusión

La emulación de código nativo es algo muy interesante. Para un desarrollador de dispositivos, es posible depurar el firmware sin un dispositivo real. Para el investigador: la capacidad de realizar análisis de código dinámico, que no siempre es posible incluso con un dispositivo.

Queremos proporcionar a los especialistas una herramienta que sea conveniente, moderadamente simple y que no requiera mucho esfuerzo y tiempo para configurar e iniciar.

Escriba en los comentarios sobre su experiencia con el uso de emuladores de hardware. Te invitamos a una discusión y estaremos encantados de responder preguntas.