Quando você tenta encontrar o firmware do dispositivo que está analisando, seja no site do fabricante do microcontrolador, utilizando Google Dorks ou explorando repositórios do GitHub, mas não obtém resultados positivos, é hora de considerar alternativas.

No artigo que publicamos anteriormente sobre hardware hacking, destacamos várias características da extração de firmware, com foco nas vantagens e limitações do uso de JTAG. No entanto, existem outros métodos interessantes que devem ser considerados para alcançar nosso objetivo. Vamos explorar agora outras opções disponíveis para esse fim.

1. Interface UART/SWD/SPI/I2C

#UART

O protocolo de comunicação serial UART é bastante utilizado e pode proporcionar acesso a consoles de depuração, facilitando, assim, a extração de firmware ou o acesso ao sistema operacional do dispositivo.

As interfaces UART são comuns em dispositivos IoT e costumam estar disponíveis para diagnósticos. Ao acessar essas portas UART, é possível obter acesso à consola (shell root/gerenciador de boot). Basta identificar os pinos TX, RX e GND, e em seguida, utilizar um conversor serial para USB e um emulador para se comunicar com o dispositivo. Esse método pode ser uma maneira simples e eficaz de começar a desvendar o funcionamento interno de um dispositivo IoT, entre outros.

#SWD (Serial Wire Debug)

O SWD (Serial Wire Debug) é outra interface comum de depuração para microcontroladores, especialmente em dispositivos baseados em ARM. Ele oferece acesso à memória e aos registros do dispositivo, permitindo, potencialmente, a extração de firmware.

#SPI/I2C

Tanto o SPI quanto o I2C são protocolos de comunicação entre chips. Com ferramentas específicas, como um programador SPI ou I2C, é possível ler e extrair firmware armazenado em memórias flash ou EEPROM.

Os chips flash se comunicam com as CPUs, MCUs e SoCs por meio de protocolos como SPI. Quando um dispositivo é ligado, sua CPU lê a memória flash, o que representa um momento ideal para rastrear dados usando um analisador lógico. É importante ressaltar que, dependendo do dispositivo, podemos conseguir ler apenas uma parte do firmware, e pode ser necessário obter controle total do chip para realizar uma leitura completa.

Sem dúvida, um chip flash precisa de energia para funcionar. Se não o desoldarmos e fornecermos energia a uma das pernas do chip, poderíamos acabar ativando toda a placa, resultando em um "tira e afrouxa" entre a memória flash e a CPU. Uma solução alternativa é desoldar a perna VCC, o que requer menos trabalho, mas aumenta as chances de danificar o chip. Se tivermos boas ferramentas, outra opção é desoldar todo o chip, o que também facilitará seu uso em um programador flash. Essas alternativas, é claro, dependerão do tipo de dispositivo e do microcontrolador que estamos analisando.

2. Leitura direta da memória Flash

Quando o firmware está armazenado em uma memória Flash, é possível desoldar o chip usando uma estação de solda ou um soprador térmico e, em seguida, ler seu conteúdo com um programador de memória flash. Existem também técnicas in-circuit que permitem a leitura do chip diretamente, sem a necessidade de desoldá-lo, utilizando ferramentas como o Bus Pirate.

Para memórias flash em encapsulamentos QFP (Quad Flat Package), o processo envolve aquecer cuidadosamente as soldas para remover o chip sem danificar a placa de circuito impresso (PCB) nem o próprio chip. Após a remoção, é possível ler seu conteúdo por meio de um programador de memória flash.

Uma técnica útil é a aplicação de uma aleação com baixo ponto de fusão. Essa abordagem consiste em aplicar uma aleação especial nas pernas do chip, que se mistura com a solda padrão, reduzindo seu ponto de fusão. Isso facilita a remoção do chip da placa, evitando uma grande desordem na área.

As memórias flash eMMC em encapsulamentos BGA (Ball Grid Array) apresentam desafios específicos. Desoldar um chip BGA exige precisão e habilidade, uma vez que as soldas estão localizadas abaixo do chip, dificultando o aquecimento uniforme sem danificar o chip ou a PCB. Após a extração, um adaptador de soquete BGA ou um método de soldagem direta em um leitor de memória flash pode ser utilizado para interagir com o chip.

Esse método exige equipamento especializado e habilidade manual, mas é uma maneira confiável de acessar o firmware diretamente. Um outro aspecto a considerar são as memórias UFS flash em encapsulamentos BGA, onde o processo se torna ainda mais complexo. O UFS é um protocolo recente e muito mais rápido para memórias flash, o que torna os programadores de memória flash UFS raros e significativamente mais 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. Reversão de atualizações de firmware (OTA ou USB)

#Atualizações OTA (Over-the-Air)

Quando um dispositivo recebe atualizações de firmware, essas atualizações podem ser distribuídas sem criptografia ou com segurança fraca. Capturar o tráfego de rede durante o processo de atualização pode facilitar a obtenção do firmware, permitindo a análise do conteúdo transferido.

#Atualizações via USB

Em alguns dispositivos, as atualizações são realizadas por meio de USB ou cartões de memória. Analisando o conteúdo dessas atualizações, é possível extrair o firmware. Essa abordagem pode ser uma alternativa eficaz quando as atualizações OTA não estão disponíveis ou quando se deseja uma análise mais profunda do firmware atualizado.

#MITM no processo de atualização

Se o dispositivo que estamos analisando oferece a opção, seja por hardware ou software, de instalar atualizações, podemos aplicar essa instalação após realizar um ataque Man-in-the-Middle (MITM) adequado para capturar o tráfego. Existem várias ferramentas disponíveis para essa tarefa, desde Bettercap até Mitmproxy.

A ideia aqui é que, apesar da adoção generalizada do HTTPS, alguns desenvolvedores ainda podem utilizar redes de entrega de conteúdo (CDN) HTTP simples para distribuir atualizações. Nesse caso, o pacote de atualização pode ser facilmente extraído do tráfego ou podemos capturar a URL e segui-la.

Agora, suponhamos que o destino utilize HTTPS. Nesse cenário, temos duas abordagens possíveis. Se o dispositivo é independente e não possui um aplicativo móvel ou cliente de desktop para controle, ainda é possível usar um certificado HTTPS autoassinado, com boas chances de sucesso. A segunda abordagem ocorre quando os dispositivos não têm sua própria interface de usuário e requerem um aplicativo para smartphone para controle.

Em alguns casos, a descarga do firmware pode estar implementada no próprio aplicativo. Nesse caso, podemos instalar um certificado raiz autoassinado no smartphone ou emulador que estamos usando. Se, neste ponto, as funções de conectividade à Internet do aplicativo deixarem de funcionar, isso indica que a função de SSL Pinning está em uso. Existem várias técnicas para contornar essa proteção, como o uso de Frida.

Conclusões

Como podemos observar, cada uma dessas técnicas apresenta desafios únicos, e a escolha da abordagem adequada depende do tipo de dispositivo e das medidas de segurança implementadas pelo fabricante. Em alguns casos, os fabricantes adotam medidas adicionais de segurança, como proteção contra leitura, criptografia de firmware em repouso ou mecanismos de proteção exclusivos, que exigem uma abordagem mais cuidadosa. Cada um desses cenários extremos requer uma estratégia singular, frequentemente envolvendo uma combinação de habilidades de engenharia reversa de hardware e software para contornar essas proteções.

Além disso, os objetivos da nossa análise determinarão os limites e escopos da investigação. Não é o mesmo realizar uma auditoria de segurança, que não necessariamente implica a exploração de vulnerabilidades, do que conduzir uma investigação aprofundada sobre o funcionamento de um dispositivo e suas características de segurança.

Atualmente, podemos afirmar que a segurança dos sistemas embarcados ainda está em um estágio inicial. A maioria dos fabricantes não adota boas práticas de segurança, e em muitos casos, nem sequer as considera, como é evidente em uma grande quantidade de dispositivos IoT que estão cada vez mais presentes na vida cotidiana da comunidade.

Seremos testemunhas do que acontecerá com a crescente incorporação de sistemas embarcados em diversas áreas do nosso dia a dia. Sem dúvida, é um momento oportuno para que, independentemente de nossa posição, consideremos cuidadosamente a segurança dos dispositivos que utilizamos. Hoje em dia, não há dispositivo que não armazene informações suficientes para ser exploradas por pessoas com más intenções.