Polypyus Historiador de Firmware

Polypyus aprende a localizar funciones en binarios sin procesar extrayendo funciones conocidas de binarios similares. Por lo tanto, es un historiador de firmware. Polypyus trabaja sin desensamblar estos binarios, lo cual es una ventaja para binarios complejos de desensamblar y donde las herramientas comunes pasan por alto funciones. Además, el enfoque exclusivamente binario lo hace muy rápido y se ejecuta en unos pocos segundos. Sin embargo, este enfoque requiere que los binarios sean de la misma arquitectura y tengan opciones de compilador similares.

Polypyus se integra en el flujo de trabajo de herramientas existentes como Ghidra, IDA, BinDiff y Diaphora. Por ejemplo, puede importar funciones previamente anotadas y aprender de ellas, y también exportar funciones encontradas para importarlas en IDA. Dado que Polypyus utiliza umbrales bastante estrictos, en nuestros experimentos solo encontró coincidencias correctas. Si bien esto genera menos resultados que en las herramientas existentes, es un buen punto de partida para cargar estas coincidencias en IDA para mejorar sus resultados de autoanálisis y luego ejecutar BinDiff sobre ellos.

Lo que resuelve Polypyus

Al trabajar con binarios de firmware sin procesar, concretamente varias versiones de firmware Bluetooth de Broadcom y Cypress, encontramos que el autoanálisis de IDA a menudo identificaba incorrectamente los inicios de funciones. En IDA Pro 6.8 el autoanálisis es un poco más agresivo, lo que genera más resultados pero también más falsos positivos. En general, IDA Pro 7.2 era más pesimista, pero pasaba por alto muchas funciones. Esto provocó que solo hubiera unas pocas coincidencias de BinDiff entre nuestros firmwares en IDA Pro 6.8 y ninguna coincidencia útil en IDA Pro 7.2.

Curiosamente, BinDiff a menudo fallaba al identificar funciones que, excepto por las ramas, eran idénticas en bytes. Tenga en cuenta que Polypyus busca exactamente estas funciones idénticas en bytes. Suponemos que BinDiff falla en estas funciones debido a un gráfico de llamadas diferente producido por funciones faltantes y falsos positivos. A veces, IDA ya reconocía estas funciones, pero a menudo IDA no las reconocía como código o no las marcaba como función. Tenga en cuenta que Diaphora tiene problemas similares, ya que exporta funciones identificadas por IDA antes de procesarlas posteriormente. A continuación se muestra un punto de referencia sobre el binario de firmware Bluetooth CYW20735B1 que compara varios desensambladores y cómo las fallas del desensamblador generan problemas de diferenciación posteriores.

Además, aunque descubrimos que Amnesia encuentra muchas funciones, también encuentra muchos falsos positivos. Sin embargo, muchas funciones tienen una configuración de marco de pila similar al principio. Por lo tanto, Polypyus tiene una opción para aprender inicios de funciones comunes a partir de los binarios de entrada anotados y aplicar esto a otros binarios para identificar funciones sin emparejar su nombre. Este paso opcional solo se aplica a las regiones en las que no se localizaron funciones previamente; de esta manera, el método de inicios de funciones comunes y la búsqueda principal de funciones no entran en conflicto.

Dado que estos emparejadores trabajan sobre el binario sin procesar, no dependen de un desensamblador. Esto también tiene un inconveniente importante: si hubiera diferentes opciones de compilador o una arquitectura de destino diferente, Polypyus no detectará funciones similares. Además, si bien las coincidencias identificadas son muy confiables, la identificación del inicio de función es un poco menos confiable, así que use esta última con cuidado. A continuación, puede ver que los kits de evaluación de Cypress son muy similares entre sí, pero el firmware de MacBook es muy diferente.

Cómo funciona

Polypyus crea emparejadores binarios difusos comparando funciones comunes en una colección de binarios de firmware anotados.

Actualmente, se admiten las siguientes anotaciones:

• Un archivo patch.elf de WICED Studio, que es un archivo ELF especial que contiene solo definiciones de símbolos.
• Un archivo .symdefs tal como lo producen la mayoría de los compiladores ARM.
• Un archivo .csv con un formato documentado en la carpeta firmware.

Estas anotaciones contienen la dirección, el tamaño y el nombre de las funciones conocidas. Cuantas más similitudes tengan los binarios de entrada en la colección de historial, mejor será el rendimiento y los resultados de Polypyus. Dadas varias funciones ligeramente diferentes, Polypyus crea emparejadores muy buenos.

Cómo instalarlo

Polypyus requiere Python 3 >= 3.6. Recomendamos el uso de un virtualenv para la siguiente instalación. Clone este repositorio y en esta carpeta ejecute:

pip install .

Cómo ejecutarlo

Después de la instalación, están disponibles los siguientes comandos:

• polypyus-gui
• polypyus-cli

Usando Polypyus

Polypyus está disponible a través de una interfaz gráfica y una de línea de comandos. Tanto la GUI polypyus-gui como la CLI polypyus-cli toman estos argumentos durante la invocación:

  --verbose es el nivel de verbosidad. Por defecto, muestra advertencias -v muestra información -vv muestra información de depuración.
  --project establece la ubicación del archivo de proyecto. Es una ruta de archivo o ":memory:".
  --help    Muestra el mensaje de ayuda.

La opción de proyecto le facilita almacenar su trabajo para diferentes contextos en diferentes archivos y también volver a abrirlos.

Usando la GUI

El flujo de trabajo general de la GUI va del lado izquierdo de la ventana al derecho. Primero, se agregan binarios al historial. Luego, siguen las anotaciones de símbolos para las entradas en el historial. Después, se pueden agregar binarios de destino. Para el emparejamiento, presione Create matchers from history. Una vez creados los emparejadores, se pueden seleccionar destinos individuales o se pueden emparejar todos los destinos seleccionando batch match. Finalmente, los hallazgos se pueden exportar a un archivo .csv.

A continuación, puede ver un video de demostración donde Polypyus solo toma unos segundos para aprender de dos binarios de entrada, anotarlos, crear emparejadores y aplicar coincidencias a un nuevo binario.

Usando la CLI

La ventaja de usar la CLI es su capacidad para automatizarse. Por ahora, el formato de salida de la CLI está sujeto a cambios. Sin embargo, aquí hay un ejemplo de su invocación:

polypyus-cli --history firmware/history/20819-A1.bin --annotation firmware/history/20819-A1_patch.elf --history firmware/history/20735B1.bin --annotation firmware/history/20735B1_patch.elf --project test.sqlite
polypyus-cli --target firmware/history/20739B1.bin --project test.sqlite

El primer comando crea test.sqlite como un nuevo archivo de proyecto e importa 20819-A1.bin y 20735B1.bin con sus respectivos archivos patch.elf. La segunda invocación reutiliza el mismo archivo de proyecto y empareja contra el binario 20739B1.bin. Para cada comando, el número de --history y --annotation debe coincidir. Estos dos comandos también podrían combinarse en uno solo agregando el argumento --target al primer comando.

¿Cómo funciona internamente?

Un artículo que explica los detalles internos se publicó en el Workshop on Binary Analysis Research (BAR) 2021 con el título Polypyus - The Firmware Historian. Algunos detalles más también se incluyen en la presentación final de la tesis de maestría de Jan, que cubre los problemas encontrados al trabajar con enfoques de diferenciación binaria convencionales en modo ARM Thumb2, y cómo funciona el enfoque alternativo solo binario.

Información adicional de exportación e importación de tipo PDOM

Los símbolos filtrados en formato patch.elf o .symdefs solo contienen nombres de funciones y variables globales. Sin embargo, también hay un par de archivos de proyecto .pdom de Eclipse en WICED Studio 6.2 y 6.4. Estos contienen información de tipo adicional. Eclipse los usa internamente para autocompletado, búsqueda de funciones, etc., y podemos utilizarlos en la ingeniería inversa para agregar información de tipos. Dado que los archivos .pdom solo contienen información parcial y en caché, puede ser útil combinar varios de ellos.

En un primer paso, exportamos la información de tipo .pdom a una base de datos SQLite. La exportación lleva un tiempo, pero incluso se puede abortar y continuar más tarde. La exportación funciona de la siguiente manera:

java -jar pdom/export/export.jar -P BCM20739-B0.1462220149391.pdom

La importación PDOM busca nombres de funciones en una base de datos de IDA, los busca en el PDOM para buscar información de tipo y luego aplica esa información de tipo en la base de datos de IDA. Por lo tanto, la base de datos de IDA debe contener nombres de funciones correctos de antemano. En principio, estos se pueden crear con los scripts import_export de Polypyus. Sin embargo, los scripts algo más avanzados que admiten la importación PDOM también pueden manejar secciones patch.elf. Ejecute el importador de la siguiente manera:

• Abra el binario de firmware en IDA.
• Establezca el modo Thumb en T=0x1 (Alt-g).
• Establezca las opciones del compilador (Options -> Compiler...) en GNU C++.
• Ejecute el archivo de script pdom/import/main.py (File -> Script file).
• Seleccione un archivo patch.elf (Select file).
• Impórtelo (Import ELF). Después de unos segundos, tendrá secciones y nombres de funciones.
• Seleccione una base de datos de referencia, que debe ser el PDOM que pertenece a su binario de firmware.
• Seleccione múltiples bases de datos adicionales, y el importador elegirá las mejores coincidencias combinadas.
• Impórtelo (Import PDOM). Esto llevará un tiempo.
• También puede importar un archivo de registro de hardware 20739mapb0.h para nombrar registros de hardware (Import map.h).

Este script fue probado en IDA Pro 7.4 y 7.5.

Flujo de trabajo recomendado para IDA Pro

Después de algunas pruebas internas, podemos recomendar el siguiente flujo de trabajo al trabajar con IDA Pro y Polypyus:

• Cree una base de datos nueva. ARM v7 little endian, ARM Cortex M para el firmware Bluetooth.
• Marque la posición 0x0 como Thumb (Alt-g, T=0x1).
• Cree segmentos ROM y RAM. ROM en 0x0 con rx, RAM en 0x200000 con rwx (al menos para el firmware Bluetooth).
• Cree offsets de tabla de vectores en ROM, al menos para el vector de reinicio, que es un offset de 4 bytes en 0x4 (o). En el firmware CYW20735 apunta a 0x3bc+1. Retroceda un byte y cree una función (p).
• Espere a que termine el autoanálisis.
• Importe los resultados de Polypyus.
• Ejecute los scripts Thumbs Up.
• Ejecute tanto BinDiff como Diaphora. Este último idealmente en una versión de IDA con descompilador. Use ambos, ya que usan heurísticas diferentes.

...ahora su base de datos de IDA podría ser algo útil :) Aún hay muchas cosas en las que el desensamblador falla dentro de ARM Thumb2, pero mucho mejor que cualquier cosa que IDA haga por sí solo.

Historial de firmware Bluetooth de Broadcom

La carpeta firmware contiene varios firmware con y sin símbolos. Todo en el historial contiene símbolos, todo en targets está sin símbolos.

Historial

Destinos

Para la serie Samsung, el S8 también incluye Note 8 y S8+, etc., y el S10/S20 también incluye todo desde el S10e hasta el Note 20 5G.

La calidad del volcado puede variar, algunos incluyen RAM y otros son solo ROM. Tenemos acceso a la mayoría de los dispositivos en esta lista. Si necesita un volcado con los niveles de parche más recientes e incluyendo RAM, no dude en contactarnos.

Algunos dispositivos mencionados en el artículo no se incluyen aquí, ya que podrían no ser dispositivos solo de investigación, etc. También faltan algunos iPhones y MacBooks, ya que los tenemos como dispositivos solo de investigación pero el volcado original no lo era. Estos dispositivos se agregarán pronto :)

Contribuir

Hay un archivo .editorconfig en este repositorio. Configura el estilo de sangría, el juego de caracteres y los separadores de línea. Siga esta configuración al contribuir, lo que puede ser más fácil si usa un complemento de IDE para .editorconfig.

Cómo instalar dependencias de prueba y desarrollo

Para instalar las dependencias de prueba, ejecute

pip install '.[test]'

esto instalará paquetes que solo son necesarios para ejecutar casos de prueba.

Las dependencias de desarrollo proporcionan, por ejemplo, stubs para tipos de paquetes. Para instalarlas, ejecute

pip install '.[development]'

Pruebas

pytest ejecutará todas las pruebas.

Pruebas locales con diferentes versiones de Python

El proyecto usa tox para ejecutar localmente las pruebas con diferentes versiones de Python. Tox está configurado para probar con las versiones 3.6, 3.7, 3.8 y 3.9. Para ejecutar tox, instale las dependencias de prueba e instale estas 4 versiones de Python mencionadas. Nuestra forma recomendada de instalar y gestionar varias versiones de Python es pyenv.

Pasos:

1. Instale Pyenv
2. Instale Pyenv virtualenv
3. Ejecute
   root@kitploit:~

   pyenv install 3.9.1
   pyenv install 3.8.6
   pyenv install 3.7.9
   pyenv install 3.6.12
   pyenv virtualenv 3.9.1 polypyus
   penv local polypyus 3.8.6 3.7.9 3.6.12
   pip install '.[test]'
   pip install '.[development]'
   

4. Ejecute tox

Automatización local

Polypyus utiliza GitHub Actions para ejecuciones de prueba automatizadas y algo de linting. Si lo desea, puede ejecutar los pasos de linting localmente con hooks de pre-commit de git.

Cada vez que se crea un nuevo commit, esto activará el linting y mostrará los problemas que impedirían que este código tenga éxito en el paso de linting de GitHub Actions. También formateará los archivos modificados con black.

pip install '.[development]'
pre-commit install

Licencia y créditos

Agradecemos a Anna Stichling por crear el logotipo de Polypyus. También agradecemos a Christian Blichmann y Joxean Koret por sus comentarios.

Polypyus es de código abierto y está licenciado bajo GPLv3.