Cuando uno apuesta a buscar en internet el firmware del dispositivo que intenta analizar, ya sea en el sitio del fabricante del microcontrolador, Google + Dorks o en repositorios de GitHub sin resultados positivos, hay que buscar alternativas.

En el anterior articulo sobre hardware hacking habíamos mencionado diversas características sobre la extracción de firmware con el foco en las virtudes y limitación de utilizar JTAG para extraer firmware. Existen otros métodos que son interesantes considerar a la hora de lograr nuestro propósito. 

Veamos ahora que otras opciones para cumplir este fin.

1.Interfaz UART/SWD/SPI/I2C

UART:

Es un protocolo de comunicación serie muy utilizado y puede permitir acceso a consolas de debugging, lo que a veces facilita la extracción de firmware, o acceso al sistema operativo del dispositivo.

Las interfaces UART son algo común en los dispositivos IoT y suelen dejarse accesibles para realizar diagnósticos. Al acceder a estos puertos UART, a veces se puede obtener acceso a la consola ( shell raíz/gestor de arranque), solo es cuestión de identificar los pines TX, RX y GND y, luego, usar un convertidor serial a USB y un emulador para comunicarse con el dispositivo. Este método puede ser una forma sencilla y eficaz de comenzar a desentrañar el funcionamiento interno de un dispositivo IoT entre otros.

SWD (Serial Wire Debug):

El SWD es otra interfaz común de depuración para microcontroladores, especialmente en dispositivos ARM. Proporciona acceso a la memoria y registros del dispositivo, permitiendo potencialmente la extracción de firmware.

SPI/I2C:

Tanto SPI como I2C son protocolos de comunicación entre chips. Con herramientas específicas (como un programador SPI o I2C), es posible leer y extraer firmware almacenado en memorias flash o EEPROM.

Los chips flash se comunican con las CPU, MCU y SoC mediante protocolos como SPI, cuando se enciende un dispositivo, su CPU lee la memoria flash, el momento perfecto para rastrear datos mediante un analizador lógico, y aquí está el punto clave, dependiendo del dispositivo podemos leer solo una parte del firmware. Aunque es posible que necesitemos obtener un control total del chip para leerlo.

Sin dudas un chip flash necesita energía para funcionar, si no lo desoldamos y le damos energía a una de las patas del chip, podríamos estar activando toda la PCB, lo que generaría un tire y afloje por la memoria flash entre nosotros y la CPU., Una solución alternativa es desoldar la pata VCC que nos dará menos trabajo pero tenemos más posibilidades de dañar el chip. Si disponemos de buenas herramientas otra opción es desoldar todo el chip lo que también hará que sea más cómodo usarlo en un programador flash, estas alternativas por supuesto estarán condicionadas por el tipo de dispositivo y microcontrolador que estemos analizando.

2. Lectura directa de memoria Flash

Si el firmware está almacenado en una memoria Flash, se puede desoldar el chip (usando una estación de soldadura o aire caliente) y leer su contenido usando un programador flash. Existen también técnicas in-circuit donde el chip se lee directamente sin necesidad de desoldarlo, usando herramientas como el Bus Pirate.

En el caso de una memoria flash en un encapsulado QFP (Quad Flat Package), el proceso implica calentar con cuidado la soldadura para retirar el chip sin dañar la PCB ni el chip en sí. Una vez que se retira el chip, se puede leer su contenido mediante un programador de memoria flash.

Uno de los trucos es utilizar una aleación con un punto de fusión bajo. Esta técnica implica aplicar una aleación especial a las patas del chip. Esta aleación se mezcla con la soldadura estándar, lo que reduce su punto de fusión general. Permite levantar el chip de la placa sin convertir toda la zona en un verdadero caos.

En cuanto a las memorias flash eMMC en encapsulados BGA (Ball Grid Array) presentan sus propios desafíos: desoldar un encapsulado BGA requiere precisión y habilidad, ya que las soldaduras están debajo del chip, lo que dificulta calentarlas de manera uniforme sin dañar el chip o la placa. Después de la extracción, se utiliza un adaptador de zócalo BGA o un método de soldadura directa en un lector de memoria flash para interactuar con el chip.

Este enfoque requiere equipo especializado y una mano firme, pero es una forma confiable de acceder al firmware directamente. Otro caso considerable es cuando tenemos UFS flash en un encapsulado BGA donde es incluso más complicado que el anterior, UFS es un protocolo nuevo y mucho más rápido para la memoria flash haciendo que los programadores de memoria flash UFS sean mucho más raros y mucho más caros.

3. Ataques de arranque/carga (Bootloader Exploitation)

Algunos dispositivos embebidos tienen bootloaders vulnerables que permiten la carga de firmware sin las debidas protecciones. Aprovechar vulnerabilidades en el proceso de arranque puede permitir acceder al firmware, por ejemplo, a través de comandos específicos que no están bloqueados.

4. Reversing de actualizaciones de firmware (OTA o USB)

Actualizaciones OTA (Over-the-Air)

Si el dispositivo recibe actualizaciones de firmware, estas actualizaciones a veces se distribuyen sin encriptación o con una seguridad débil. Capturar el tráfico de red durante una actualización puede permitir obtener el firmware.

Actualizaciones vía USB

En algunos dispositivos, las actualizaciones se hacen por USB o tarjetas de memoria. Al analizar el contenido de estas actualizaciones, se puede obtener el firmware.

MITMing en el proceso de actualización

Si el dispositivo que estamos analizando tiene la opción, ya sea por hardware o software, para instalar actualizaciones podemos aplicar esta instalación, pero no antes de haber iniciado un MITM adecuado con captura de tráfico. Hay una variedad de opciones de herramientas, desde Bettercap hasta Mitm-proxy.

La idea aquí es que, a pesar de la adopción generalizada de HTTPS, algunos desarrolladores aún pueden usar CDN HTTP simples para distribuir actualizaciones. Luego, el paquete de actualización se puede extraer fácilmente del tráfico o se puede capturar la URL y seguirla.

Pero supongamos que el destino utiliza HTTPS. En ese caso, tenemos dos caminos. Si el objetivo es independiente y no tiene ninguna aplicación móvil o cliente de escritorio para controlar, aún puedes intentar que use tu certificado HTTPS autofirmado, con probabilidades decentes de éxito. Otro camino se da cuando los dispositivos no tienen su propia interfaz de usuario y requieren una aplicación para smartphone para su control.

En algunos casos, la descarga del firmware puede estar implementada en la propia aplicación y luego poodemos instalar un certificado raíz autofirmado en el smartphone o emulador que estemos usando, en este punto si las funciones de conectividad a Internet de la aplicación dejan de funcionar, esto indica que se está utilizando la función de SSL Pinning y por supuesto existen varias técnicas para evitar esto como usar Frida.

Conclusiones

Tal como podemos advertir cada una de estas técnicas tiene sus desafíos, y la elección de la adecuada depende del tipo de dispositivo y de las medidas de seguridad implementadas por el fabricante. En algunos casos, los fabricantes implementan medidas de seguridad adicionales, -como protección de lectura, cifrado de firmware en reposo o mecanismos de protección exclusivos- que requieren un enfoque más matizado. Cada uno de estos casos extremos requiere un enfoque único, que a menudo implica una combinación de habilidades de ingeniería inversa de hardware y software para eludir estas protecciones.

Por supuesto los propósitos de nuestro objetivo marcaran los límites y alcances ya que no es lo mismo querer realizar un auditoria de seguridad, que no necesariamente implica la explotación de vulnerabilidades, que querer realizar una investigación profunda sobre el funcionamiento de un dispositivo y sus características de seguridad.

Hoy día podemos decir que la seguridad de los sistemas embebidos aún se encuentra en pañales. La mayoría de los fabricantes no utilizan buenas prácticas de seguridad y en muchos casos ni siquiera las contemplan, como sucede en una gran cantidad de dispositivos IoT cada vez más utilizados por la comunidad.

Será curioso ver que suceda con la incorporación cada vez más voluminosa de sistemas embebidos en distintas áreas de la vida cotidiana, y sin dudas es un buen momento para que sea cual sea el lugar que ocupemos consideremos con atención la seguridad de los dispositivos que estamos utilizando puesto que hoy día no hay dispositivo que no guarde información suficiente para ser utilizada por una persona con malas intenciones.