Desvendando Placas 'Caixa-Preta': Conheça Ghidra, a Ferramenta Gratuita que Pode Revolucionar o Reparo de MCUs | Notícias Climatrônico

INTRODUÇÃO

Pega essa visão: você recebe uma placa de ar-condicionado com um microcontrolador sem silk, sem esquema, com o fabricante se negando a fornecer firmware e o aparelho faz ciclos estranhos — compressor liga por 3 segundos e desliga, ou o display fica mudo. O caminho fácil é trocar componentes à prova de balas (capacitores eletrolíticos, MOSFETs, reguladores), mas às vezes não adianta. Já vi muita placa “caixa-preta” voltar e a única diferença entre conserto e sucata ser entender o que o software está mandando o hardware fazer. Eletrônica é uma só — hardware e software se falam, e ignorar um é dar as costas para metade do problema.

Recentemente li uma referência interessante no Electronics Weekly sobre o livro/curso sobre o Ghidra (Gadget Book: The Ghidra Book for reverse engineering). Isso me fez pensar: não estamos falando só de literatura — estamos falando de uma ferramenta poderosa, gratuita e madura que pode mudar o jogo para quem trabalha com climatização e manutenção eletrônica. Eu sou Lawhander, da Academia da Manutenção Eletrônica (AME), e neste artigo vou mostrar por que você, técnico de bancada, precisa conhecer o Ghidra e a engenharia reversa de firmware, como isso se aplica diretamente a placas de ar-condicionado (Midea, Gree, LG, Carrier e outras), e dar um roteiro prático para começar.

No decorrer do texto vou explicar os fundamentos (o que é disassembler e decompiler), apresentar o Ghidra (origem, arquitetura e por que ele é gratuito e profissional), e detalhar aplicações práticas: identificar pinagens desconhecidas, mapear rotinas de controle do compressor, diagnosticar falhas de software e como extrair firmware de flashes e MCUs. Bora nós — tamamo junto, meu patrão — que tem muito conteúdo técnico útil aqui.

CONTEXTO TÉCNICO

O que é engenharia reversa de firmware (disassembler vs decompiler)

Engenharia reversa de firmware é o processo de pegar o conteúdo binário que roda em um microcontrolador (o firmware) e analisar seu comportamento sem ter acesso ao código-fonte original. Existem duas ferramentas conceituais principais:

Disassembler: converte instruções binárias em assembly (por exemplo, ARM, MIPS, 8051, PIC). A saída é legível por humanos, mas em baixo nível. Ex.: 0x08000100 -> MOV R0, #1. Disassembly permite seguir saltos, interrupts, tabelas de vetores e ver onde funções são chamadas.
Decompiler: tenta reconstruir uma representação de alto nível (C-like) a partir da assembly. Não é perfeita, mas acelera muito a compreensão de estruturas, loops, condições e chamadas de funções. O Ghidra possui um decompiler muito robusto para várias arquiteturas.

Por que isso interessa a um técnico de climatização? Porque muitos defeitos em ar-condicionados não são eletricamente óbvios: firmware mal calibrado, flags de proteção que impedem acionamento do compressor, watchdog mal configurado ou tabelas de compensação de temperatura corrompidas. Entendendo o firmware você pode:

Identificar lógica que força bloqueios por segurança (prot. de alta pressão ou comunicação).
Localizar rotinas que testam sensores e entender thresholds (por ex.: 50°C = erro).
Detectar falhas lógicas que causam ciclos curtos, travamentos ou resets contínuos.

Fundamentos que o técnico precisa dominar

Para aplicar engenharia reversa em bancada, você precisa dominar alguns conceitos e ferramentas de hardware:

Arquitetura do MCU: saber identificar se é ARM Cortex-M (STM32), MIPS, Tensilica (ESP8266/ESP32), PIC, Renesas, Nuvoton etc. Cada arquitetura tem convenções diferentes de ABI, vetores de interrupção e mapeamento de memória.
Interfaces de debug/programação: JTAG, SWD, UART bootloader, ISP (In-System Programming via SPI/I2C), protocolos de memória externa (SPI NOR, eMMC). Conhecer como acessar a flash é essencial.
Memória e mapeamento: região de boot (bootloader), vectors, RAM/Flash, EEPROM/FRAM. Ter noção de offsets e endereços base (ex.: STM32 flash em 0x08000000).
Sinais elétricos e níveis: detectar pinos de comunicação (UART TTL 3.3V/5V), linhas I2C/SPI, clocks. Uso de osciloscópio e analisador lógico para capturar tráfego.

Historicamente, técnicos dependiam de esquemas, datasheets e suporte do fabricante. Hoje muitos MCUs têm proteção contra leitura (read-out protection) e há também placas com firmware em flashes externas (SPI NOR) que são acessíveis com hardware barato. Ferramentas como o Ghidra mudam o paradigma: se você consegue ler o binário, você consegue entender e, muito possivelmente, reparar.

APRESENTAÇÃO DO GHIDRA

O que é Ghidra e por que ele importa

Ghidra é um framework de engenharia reversa desenvolvido pela NSA e liberado como software livre (open-source). É uma suíte completa: disassembler, decompiler, análise estática, visualização de fluxo, suporte a múltiplas arquiteturas e um sistema de scripting. A comunidade tem desenvolvido plugins e scripts que complementam o fluxo de trabalho. Referência: artigo do Electronics Weekly sobre o Ghidra Book (https://www.electronicsweekly.com/blogs/gadget-master/general/gadget-book-the-ghidra-book-for-reverse-engineering-2026-03/).

Por que é tão relevante para técnicos?

É grátis e profissional: não precisa desembolsar IDA Pro para começar.
Suporta ARM Cortex-M, MIPS, RISC-V, x86, PIC e muitas outras arquiteturas usadas em HVAC.
Possui decompiler que transforma código assembly em pseudocódigo C, acelerando a compreensão lógica.
Scripting em Python/Java permite automatizar buscas por strings, padrões de função (p.ex.: handlers de UART, conversão ADC->temperatura).

Arquitetura e recursos essenciais do Ghidra

Sleigh: linguagem para descrever a semântica de instruções de uma arquitetura. Permite estender e setar novas arquiteturas/customizações.
Decompile: gera pseudocódigo; bom para identificar loops, switches e estruturas de dados.
Function signatures e tipos: você pode definir tipos, renomear funções e variáveis, facilitando documentação.
Program tree e Data Type Manager: possibilitam mapear memória, estruturas (structs) e tabelas de dados (lookup tables, curvas de termistores).
Scripting: use Jython/Java para extrair strings, localizar padrões de bootloader e automatizar análise de múltiplos firmwares.

Ghidra não faz milagres: depende da qualidade do binário (se o MCU estava protegido, você vai bater no muro), mas na maioria dos casos em placas de ar-condicionado você consegue extrair bastante informação.

ANÁLISE APROFUNDADA

Como identificar a função de pinos de um MCU desconhecido

Pega essa visão prática: você remove a placa, identifica o MCU (pela serigrafia ou pelo encapsulamento) — se houver — e quer mapear quais pinos controlam o relé do compressor, o sensor de pressão, o backlight do display etc.

Fluxo prático:

Inspeção física: siga trilhas, veja componentes conectados ao MCU: MOSFETs, drivers, transceivers. Isso dá pistas iniciais (ex.: MCU -> driver de MOSFET via resistor indica pino PWM).
Sinalização ao vivo: com a placa em operação, use o osciloscópio/analisador lógico para mapear pinos com atividade quando o compressor deveria ligar. Capture PWM e níveis TTL.
Dump do firmware: se possível, extraia o binário via SWD/JTAG (STM32), bootloader UART (ESP), ou lendo o SPI NOR com CH341A/Bus Pirate/flashrom. Se o MCU tiver read-out protection, talvez a flash externa contenha o firmware.
Análise no Ghidra:
- Importe o binário e selecione a arquitetura.
- Procure por strings: mensagens de erro, nomes de funções (às vezes há logs simples como “COMP ERR”).
- Localize tabelas de interrupção/boot vectors (em ARM Cortex-M, o vetor inicia em 0x08000000) para achar a rotina de reset e handlers.
- Identifique funções que manipulam GPIO registers (em STM32: escrever em GPIOx->ODR/BSRR). No decompiler essas escritas aparecem como atribuições a endereços mágicos — crie símbolos (p.ex.: GPIOB_ODR) e renomeie.

Dados técnicos úteis:

Níveis comuns: 3.3V para MCU modernos (STM32, ESP), 5V em designs mais antigos. Atenção ao medir: usar divisor/sonda adequada.
PWM para compressors/controles: muitas placas usam frequências na faixa de 1kHz–20kHz para drivers; relés/contatores são acionados via GPIO com driver de potência (transistor/MOSFET).
Endereços típicos: STM32 flash 0x08000000, RAM 0x20000000. Reconhecer esses padrões acelera o trabalho.

Exemplo prático: numa placa Midea comum, encontrei uma rotina que lia ADC de termistor, aplicava uma tabela de compensação e, se temperatura > X, setava um bit em um registrador que ativava o relé. Renomeando as funções no Ghidra e rastreando as leituras ADC, determinamos que o termistor era lido com um divisor que tinha resistor R=10k — concluímos que um mal contato num via do resistor causava leituras erráticas. Toda placa tem reparo.

Entendendo a lógica do compressor e diagnósticos de software

Muitos problemas de compressor não são elétricos: são flags internas no firmware (proteção de sobrecorrente, ciclo curto, erro de comunicação entre PCB indoor/outdoor). Com o firmware em mãos, é possível:

Identificar condições de bloqueio: procure por constantes e comparações que resultam em “disable compressor”. No pseudocódigo você verá if(temp > LIMIT) return ERROR_COMP.
Detectar timers e watchdog: rotinas que reiniciam MCU via NVIC_SystemReset() (em STM32) ou escrevem no registrador de watchdog (IWDG) indicam reset por falha de supervisão.
Localizar rotinas de comunicação: funções que acessam UART/SPI/I2C para comunicação com a placa externa ou painel. Se a placa indoor não responde, pode ser porque o firmware espera handshake específico.
Confirmar tabelas de curva: look-up tables usadas para conversão ADC->°C (NTC) podem estar corrompidas ou com offset. Ajustá-las ou restaurar valores pode resolver problemas de leitura.

Ferramentas complementares:

Analisador lógico para capturar frames UART entre indoor/outdoor (tipicamente 3.3V TTL).
Osciloscópio para medir sequência de partida do compressor (sequência de relés, delays).
Multímetro para verificar rails: 5V/12V/3.3V e tensões de mosfet/power stage.

⚠️ Atenção: mexer em firmware e alterar tabelas sensíveis pode afetar segurança (proteção contra alta pressão, sobrecorrente). Teste sempre com bancada e cargas simuladas.

Lidando com MCUs protegidos ou com flash externo

Nem sempre você consegue ler o conteúdo do MCU. Muitos fabricantes usam proteção de leitura (RDP em STM32). Nesses casos:

Verifique se existe memória externa (SPI NOR). Muitos designs colocam firmware em flash externa porque é mais barato e facilita atualizações e recuperação.
Ferramentas para ler SPI NOR: CH341A (barato), Bus Pirate, flashrom em Linux, ou programadores SOIC-8 com clip SOIC. Use adaptadores SOIC8 e software adequado (ex.: flashrom + chiplist).
Se o MCU estiver protegido e não houver flash externa, alternativas avançadas incluem ataques físicos (decapping, microprobing) — porém são complexos, caros e muitas vezes ilegais/antiéticos. Sempre respeite a legislação e acordos.

💡 Dica prática: antes de tirar a memória da placa, procure por vias que levem a um conector de programação (test pads). Muitas placas têm pads de SWD/JTAG escondidos sob conformal coating — você pode raspá-lo com cuidado.

APLICAÇÃO PRÁTICA

Como isso muda o dia-a-dia do técnico de bancada

Com Ghidra e fluxo de firmware você pode:

Diagnosticar antes de substituir: identificar se o problema é software (p.ex.: bootloader corrompido) e regravar firmware em vez de trocar MCU ou placa.
Recuperar parâmetros de calibração perdidos e restaurar curvas de termistores ou offsets da EEPROM/FRAM.
Implementar “workarounds” temporários: se uma entrada digital está invertida por defeito de hardware, você pode alterar a lógica no firmware (quando autorizado) para reverter comportamento.
Documentar e criar base de conhecimento: salvar funções renomeadas e comentários no Ghidra para o próximo técnico.

Ferramentas e setup recomendado para bancada:

Computador com Ghidra (Java 11+).
Programadores: ST-Link, J-Link, CH341A, Bus Pirate.
OpenOCD/pyOCD para conexão com SWD/JTAG.
Adaptadores SOIC clip, estação de solda e dessoldagem.
Osciloscópio (2 canais ou mais) e analisador lógico (Saleae ou clone).
Cabos FTDI (USB-UART) para monitoramento de bootloader.

Procedimento passo-a-passo (resumido)

Inspeção visual e levantamento de componentes. Identifique MCU e memórias.
Medidas elétricas das rails e sinais de I/O com o aparelho ligado (segurança!).
Tentar conexão por UART/SWD/JTAG — ver se o fabricante deixou debug desativado.
Se houver flash externo, fazer dump com CH341A/flashrom.
Importar binário no Ghidra, configurar arquitetura e executar análise automática.
Procurar strings e vetores de interrupção; mapear funções críticas.
Renomear símbolos, identificar pinos e rotinas de controle.
Testar hipóteses no hardware (por ex.: forçar flag de erro lendo_o_adc) e validar.

💡 Dica: use scripts Ghidra para procurar padrões de acesso a registradores comuns (por exemplo, em STM32: buscas por endereços de GPIO, RCC, TIMx). Isso acelera achar a função que gera PWM.

CONCLUSÃO

Engenharia reversa de firmware não é esoterismo de laboratório secreto — é uma habilidade prática que pode transformar a forma como consertamos equipamentos HVAC. O Ghidra, embora nascido em um contexto militar (NSA), é um presente para a manutenção eletrônica: é gratuito, poderoso e extensível. Referência: vi a discussão sobre o Ghidra book no Electronics Weekly (https://www.electronicsweekly.com/blogs/gadget-master/general/gadget-book-the-ghidra-book-for-reverse-engineering-2026-03/), e isso confirma que a ferramenta já tem aceitação divulgada na área.

Resumo das ações que você, técnico, pode tomar:

Familiarizar-se com os fundamentos: arquitetura de MCU, JTAG/SWD, leitura de SPI NOR.
Montar um kit básico de bancada: ST-Link/J-Link, CH341A, adaptador SOIC, osciloscópio e analisador lógico.
Instalar e praticar com Ghidra em firmwares simples (por ex.: firmwares de ESP8266/ESP32 disponíveis).
Documentar análises e criar biblioteca de padrões para modelos comuns (Midea, Gree, LG, Carrier).

Toda placa tem reparo — e agora temos ferramentas para ir além da troca cega de componentes. Pega essa visão e comece devagar: leia um dump, abra no Ghidra, tente entender uma função. É trabalhoso no começo, mas o ganho técnico e econômico em poder recuperar placas antes consideradas inreparáveis é enorme. Show de bola — tamamo junto nessa jornada. Se quiser, eu posso montar um roteiro prático com links de ferramentas, scripts Ghidra úteis e um exemplo passo a passo com um dump real (sem violar propriedade intelectual). Meu patrão, bora nós: conhecimento aplicado é o que separa quem troca placa por placa de quem salva equipamentos.