Voltar aos artigos
Beginner

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.

@0xrafasecFebruary 18, 2026hardware_and_firmware

Available in English

Share:

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.

DO
  • 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
DO NOT
  • 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

FaseFerramentaObjetivo
1. Identificação de TerraMultímetro (continuidade)Encontrar pino(s) GND
2. Perfilamento de Voltagem QuiescenteMultímetro (voltagem DC)Distinguir TX de RX, encontrar VCC
3. Confirmação de Taxa de BaudAnalisador lógico + PulseViewMedir largura de bit, validar antes de conectar
4. Acesso ao ConsoleUSB-para-serial + minicomObter 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

Loading diagram…

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, CON1 ou DEBUG
  • 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á:

Loading diagram…

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 baud115200 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

Loading diagram…

Alternativas & Comparação

MétodoVelocidadeCusto de EquipamentoFunciona Sem Atividade de BootRisco 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/SWDMédioMédio ($50–$500)SimBaixo
Leitura direta de chip flash (SOIC clip)Lento (setup)Médio ($30–$100)SimMédio
Descoberta automática de Bus pirateRápidoBaixo ($30)ParcialBaixo
Apenas osciloscópioMédioAlto ($200+)NãoMuito 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

Achou este artigo interessante? Siga-me no X e no LinkedIn.