Mapeamento de Pinouts UART em Placas Mistério com Multímetro e Analisador Lógico — Sem Silkscreen Necessário
Você acabou de receber um alvo de hardware através de um programa de bug bounty — um roteador IoT compacto, um hub de casa inteligente ou um gateway industrial.
Available in English
Mapeamento de Pinouts UART em Placas Mistério com Multímetro e Analisador Lógico — Sem Silkscreen Necessário
Legal & Ethical Disclaimer
This content is provided for EDUCATIONAL and AUTHORIZED SECURITY TESTING purposes only.
- •Use these techniques on systems you own or have explicit written permission to test
- •Practice in authorized lab environments (VulnHub, HackTheBox, DVWA, etc.)
- •Follow responsible disclosure practices when finding vulnerabilities
- •Use knowledge for defensive security and authorized penetration testing
- •Access systems without explicit authorization
- •Use these techniques for malicious purposes
- •Deploy exploits against production systems you don't own
- •Share working exploits for unpatched vulnerabilities
Legal warning
Unauthorized access to computer systems is illegal in most jurisdictions (e.g. CFAA in the US, Computer Misuse Act in the UK). Violators may face criminal prosecution and civil liability. The author and publisher assume no liability for misuse of this information. By continuing, you agree to use this knowledge ethically and legally.
Hook & Contexto
Você acabou de receber um alvo de hardware através de um programa de bug bounty — um roteador IoT compacto, um hub de casa inteligente ou um gateway industrial. Não há datasheet, sem rótulos no silkscreen, e o fabricante certamente não imprimiu "DEBUG AQUI" ao lado do conector de quatro pinos na borda da placa. O que você sabe é que em algum lugar dessa PCB, quase com certeza, há um console de debug UART esperando para lhe entregar um shell root — ou no mínimo um log de boot cheio de inteligência útil.
UART (Universal Asynchronous Receiver-Transmitter) continua sendo a interface de debug dominante na engenharia de firmware incorporado. É barato de implementar, não requer linha de clock externa e tem sido a interface de console padrão desde os dias dos computadores de placa única nos anos 1980. Devido a essa onipresença, engenheiros de hardware deixam headers UART em placas de produção muito mais frequentemente do que você esperaria — às vezes deliberadamente para diagnósticos de campo, às vezes porque remover os pontos de teste exigiria um novo spin da PCB. Para um pesquisador de segurança de hardware, esse header esquecido é um presente.
O desafio não é se UART existe. Quase sempre existe. O desafio é encontrá-lo rapidamente, confirmá-lo de forma confiável e conectar-se a ele com segurança sem danificar o alvo ou desperdiçar uma hora adivinhando baud rates. Esta metodologia lhe dá um processo repetível de três fases — rastreamento de terra, perfilamento de voltagem quiescente e captura lógica — que o leva a um console de boot em menos de 30 minutos em quase qualquer placa que você encontrar.
TL;DR
| Fase | Ferramenta | Objetivo |
|---|---|---|
| 1. Identificação de Terra | Multímetro (continuidade) | Encontrar pino(s) GND |
| 2. Perfilamento de Voltagem Quiescente | Multímetro (voltagem DC) | Distinguir TX de RX, encontrar VCC |
| 3. Confirmação de Taxa de Baud | Analisador lógico + PulseView | Medir largura de bit, validar antes de conectar |
| 4. Acesso ao Console | USB-para-serial + minicom | Obter o shell |
Fundações & Teoria
Antes de tocar uma sonda, entenda como UART se parece eletricamente para saber o que você está procurando.
UART em repouso está ocioso-alto. Na lógica UART padrão, a linha fica em VCC (lógica 1) quando nada está sendo transmitido. No momento em que uma transmissão começa, a linha cai para baixo por exatamente um período de bit (o bit de início), depois entrega bits de dados e depois retorna ao alto. Este comportamento ocioso-alto é sua impressão digital primária.
Um header UART típico em uma placa embarcada tem entre 3 e 5 pinos:
- GND — terra de referência, sempre presente
- TX — transmite dados do dispositivo (isto é o que você lê)
- RX — recebe dados no dispositivo (isto é o que você escreve)
- VCC — referência 3.3V ou 5V, frequentemente presente mas nem sempre necessária
- GND duplicado ou blindagem — às vezes repetido em headers maiores
A armadilha crítica de nomenclatura: rótulos TX e RX são sempre da perspectiva do dispositivo. O TX do dispositivo se conecta ao RX do seu adaptador e vice-versa. Este é o erro de fiação mais comum que iniciantes cometem.
Por que UART sobrevive em placas de produção? Remover interfaces de debug custa tempo de engenharia, adiciona respins de PCB e remove a capacidade de diagnóstico de campo na qual as equipes de suporte dependem. A pressão regulatória não determina sua remoção. A pressão econômica vence e o header UART fica.
Onde Se Encaixa no Fluxo de Trabalho
Esta metodologia se encaixa bem na fase de reconhecimento e acesso inicial do trabalho de segurança de hardware. Uma vez que você tem um console de boot, fases subsequentes — extraindo o filesystem via dd, lendo /proc/mtd ou explorando serviços não autenticados — se tornam dramaticamente mais fáceis. O acesso ao console nem sempre é o objetivo final, mas quase sempre acelera todos os outros objetivos.
Conceitos-Chave em Profundidade
1. Inspeção Visual: Encontre os Candidatos Primeiro
Antes de qualquer medição, gaste cinco minutos olhando. Você está procurando por headers não populados, clusters de pontos de teste e pads através-furo perto do SoC ou perto da borda da placa.
Sinais visuais comuns:
- Um header através-furo de 4 pinos (populado ou apenas pads) perto do processador principal
- Rótulos de silkscreen como
J1,P2,TP1-TP4,CON1ouDEBUG - Pads que são maiores que os traços de sinal circundantes — estes foram projetados para sondagem
- Grupos de 4–6 vias em uma linha sem óbvia função de potência ou RF
Fotografe cada cluster candidato. Numere-os. Você pode ter dois ou três headers candidatos e quer rastrear qual é qual conforme você sonda.
2. Fase 1 — Identificação de Terra com Modo de Continuidade
Configure seu multímetro para modo de continuidade (o símbolo do diodo soando). Toque uma sonda em uma referência de terra conhecida — a blindagem metálica de uma porta USB, a perna negativa de um capacitor perto da entrada de potência ou o plano de terra exposto na borda da PCB. Toque a outra sonda em cada pino do seu header candidato.
Um bip significa que o pino está conectado à terra. Marque esse pino GND.
Por que começar com terra? Porque GND é a referência comum para cada medição de voltagem subsequente. Sem um GND confirmado, suas leituras de voltagem não têm significado. GND também é tipicamente o pino mais fácil de confirmar, uma vez que quase sempre está ligado ao plano de terra do chassis da placa, que tem dezenas de pontos de conexão.
⚠️ Faça isto com a placa desligada. Modo de continuidade injeta uma pequena corrente para testar resistência. Fazer isto em uma placa viva arrisca injetar essa corrente em um nó de circuito ativo.
3. Fase 2 — Perfilamento de Voltagem Quiescente
Agora ligue a placa. Configure seu multímetro para voltagem DC, com a sonda preta em seu pino GND confirmado. Meça cada pino desconhecido restante e anote a voltagem em repouso (antes do boot completar) e durante o boot.
Aqui está o que você observará:
Comportamento de TX: Ocioso-alto (3.3V típico), com flutuação de voltagem visível ou comutação rápida durante a sequência de boot. Se você observar a agulha do multímetro ou a leitura digital, verá uma breve queda e cintilação durante o boot — esse é o processador despejando mensagens do kernel.
Comportamento de RX: Também ocioso-alto (o dispositivo mantém RX alto esperando entrada), mas será completamente estável porque nada o está acionando durante o boot normal. Parece quase idêntico a VCC à primeira vista — é aqui que a maioria dos iniciantes fica confusa.
O diferenciador chave: Desligue e ligue brevemente a placa e observe os pinos durante os primeiros 2–5 segundos do boot. TX flutuará visivelmente até em um multímetro básico. RX permanecerá plano. VCC também permanecerá plano, mas é tipicamente em um trilho de potência dedicado, não um pino de header adjacente ao SoC.
Registre seus achados: você deve agora ter GND confirmado, TX suspeito, RX suspeito e opcionalmente VCC identificado.
4. Fase 3 — Confirmação de Taxa de Baud com um Analisador Lógico
Nunca conecte um adaptador USB-para-serial a uma UART não confirmada em uma taxa de baud desconhecida. Voltagens incompatíveis (sinal de 5V em um adaptador de 3.3V) podem danificar hardware. Voltagem correta mas taxa de baud errada apenas lhe dá lixo — mas desperdiça tempo e cria dúvida desnecessária. Confirme ambos antes de conectar.
Conecte seu analisador lógico:
- Analisador lógico GND → placa GND (confirmado na Fase 1)
- Analisador lógico Canal 0 → pino TX suspeito
Abra PulseView. Configure a taxa de amostragem para pelo menos 10× sua taxa de baud esperada — para um alvo de 115200 baud, use 1 MHz ou superior. Desligue e ligue a placa e capture 2–4 segundos de tráfego de boot.
Medindo taxa de baud a partir da largura de bit: Faça zoom no sinal capturado até poder ver bits individuais. Encontre o pulso mais estreito que você pueda identificar (um único período de bit). Meça sua largura em microssegundos.
Taxa de Baud = 1 / Largura de Bit (em segundos)
Exemplo: Uma largura de bit de ~8.68 µs → 1 / 0.00000868 = 115.207 baud → 115200 baud (valor padrão).
Taxas de baud padrão comuns para comparar: 9600, 19200, 38400, 57600, 115200, 230400, 460800, 921600.
✅ PulseView também tem um decodificador UART integrado. Adicione-o via Decode → UART, configure a taxa de baud para seu valor medido, aponte para o Canal 0 e veja-o decodificar texto ASCII do log de boot em tempo real. Se você ver strings reconhecíveis (versão do kernel Linux, nome do bootloader, endereços IP), você confirmou TX, taxa de baud e o fato de que isso é um console UART real — tudo em um passo.
Verificação de nível de voltagem: Enquanto seu analisador está conectado, verifique a voltagem lógica alta no pino TX. A maioria dos sistemas embarcados modernos usa lógica de 3.3V. Placas mais antigas ou industriais podem usar 5V. Seu adaptador USB-para-serial deve corresponder — ou você precisa de um conversor de nível. CH340, CP2102 e FTDI FT232RL todos suportam 3.3V; muitos suportam ambos via jumper.
5. A Árvore de Decisão: De Zero ao Console
Alternativas & Comparação
| Método | Velocidade | Custo de Equipamento | Funciona Sem Atividade de Boot | Risco para o Alvo |
|---|---|---|---|---|
| Multímetro + Analisador Lógico (este guia) | Rápido (< 30 min) | Baixo ($15–$150) | Não (precisa de tráfego de boot para ID de TX) | Muito baixo |
| Varredura de limite JTAG/SWD | Médio | Médio ($50–$500) | Sim | Baixo |
| Leitura direta de chip flash (SOIC clip) | Lento (setup) | Médio ($30–$100) | Sim | Médio |
| Descoberta automática de Bus pirate | Rápido | Baixo ($30) | Parcial | Baixo |
| Apenas osciloscópio | Médio | Alto ($200+) | Não | Muito baixo |
Bus Pirate (buspirate) tem um modo UART scan que varre taxas de baud comuns e relata saída legível — um atalho razoável se você tiver um disponível. No entanto, ele se conecta ao alvo antes de confirmar níveis de voltagem, o que adiciona risco marginal em hardware desconhecido.
JTAG/SWD é a ferramenta certa quando não há atividade UART visível, quando a placa está em estado bloqueado ou quando você precisa de acesso completo de debug (pausar CPU, ler registros, flash de firmware). UART e JTAG se complementam — UART é mais rápido de encontrar e explorar para recon inicial.
Leitura direta de flash (ex: usando programador CH341A com SOIC-8 clip no chip flash NOR) ignora a necessidade de qualquer interface de debug entirely. Isto é o fallback quando UART está desabilitado em firmware ou o bootloader tem uma senha. É mais lento de configurar, mas sempre funciona se você puder identificar o chip flash.
Aprendizados & Leitura Adicional
Leitura Adicional & Referências
- Hackaday: How to find a UART on a mystery board
- PulseView Documentation — UART Protocol Decoder
- OpenWrt Wiki: UART serial console access for embedded routers
- Flashback Team: Extracting Firmware from IoT Devices (UART focus)
- Craig Heffner — binwalk and firmware analysis workflows
- Saleae Logic 2 — Getting Started Guide
- OWASP Firmware Security Testing Methodology (FSTM)
- Joe Grand — Hardware Hacking: Have Fun While Voiding Your Warranty (book)