Monitorar, snifar, depurar e registrar a porta serial

Nesta página você vai aprender três maneiras de analisar a comunicação serial entre dispositivos (PC, controladores, placas embarcadas) e por que o COM Sniffer do SerialTool costuma ser a melhor solução: somente software, sem cabeamento, transparente e adequado para uso como monitor/sniffer/depurador/registrador até por vários dias.

O que você vai encontrar

• Capítulo 1: o que significa monitorar uma porta COM, como bytes/bits são estruturados e como o serial os envia (start/data/parity/stop), além de TX/RX e taxa de baud.
• Capítulo 2: o método clássico de sniffer físico com dois adaptadores USB↔serial: conecte apenas o RX às linhas TX dos dois dispositivos e compartilhe os terras. Perfeito para um monitor/registrador simples.
• Capítulo 3: o mesmo conceito aplicado a um PC Mestre conversando com um Dispositivo Alvo via conversores USB↔serial/RS-232/RS-485 (mesmo protocolo, níveis físicos diferentes). Inclui uma visão geral de Modbus RTU/ASCII e casos de uso industriais/CNC/embarcados (depuração, firmware, engenharia reversa).
• Capítulo 4: por que muitas vezes vale a pena usar o COM Sniffer do SerialTool: um monitor de porta serial baseado em um driver de kernel do Windows que intercepta dados, IOCTL, sinais e parâmetros de portas já abertas por outro software. Sem cabos, filtros precisos, exportação para pcap/pcapng (por exemplo, para o Wireshark) e estabilidade para capturas longas.

Se seu objetivo é analisar rapidamente um software de terceiros ou monitorar continuamente sua aplicação, comece pelo Capítulo 4 – COM Sniffer: é a forma mais rápida de monitorar, snifar, depurar e registrar sem montar uma bancada de testes.

Capítulo 1 – Monitorando dados da porta COM

1.1 O que significa “monitorar uma porta serial”

Monitorar uma porta COM (serial) significa observar em tempo real os bytes que viajam nas linhas de comunicação entre o PC e o dispositivo. No monitoramento normalmente distinguimos as duas direções: TX (transmissão do PC para o dispositivo) e RX (recepção do dispositivo para o PC). Um bom monitor exibe dados tanto como texto (interpretação ASCII/UTF-8) quanto em hexadecimal (HEX), ou seja, os bytes brutos.

1.2 Bytes e bits: representação lógica vs. transmissão serial

Quando escrevemos o texto Hello, os cinco caracteres são convertidos em cinco bytes ASCII: 48 65 6C 6C 6F em hexadecimal. Um visualizador de bytes como o do SerialTool permite ver a forma de onda lógica dos bits individuais dentro de cada byte.

Como ler bytes na visão lógica

• O gráfico destaca 8 bits de dados para cada byte (b7…b0). Em memória podemos listá-los como MSB→LSB (do mais significativo ao menos significativo).
• Essa representação ainda não inclui elementos do protocolo serial (start, paridade, stop) e não reflete a ordem de transmissão no fio.

Como os bytes são transmitidos na porta serial

Na linha física RS-232/TTL, cada byte é encapsulado conforme o quadro serial:

Start (1 bit, lógica “0”) → Dados (7/8 bits, enviados com LSB primeiro) → Paridade (opcional) → Stop (1 ou mais bits, lógica “1”).

• Idle: a linha de TX fica estável em lógica “1” (mark). Assim, o sinal permanece em 1 até chegar o bit de Start.
• Bit de Start: uma transição para “0” (space) sinaliza o início do byte.
• Bits de dados: os bits de dados são transmitidos em ordem LSB-first (bit menos significativo primeiro).
• Bit de Stop: retorno para “1” por 1 ou mais bits; garante que o estado de idle seja restaurado.
• Taxa de baud: determina a duração de cada bit (por exemplo, a 9600 baud cada bit dura ~104,17 µs).

Observação sobre RS-232 vs. TTL

• No nível TTL (UART em 3,3 V/5 V), “1” é alto e “0” é baixo.
• No nível RS-232 os níveis de tensão são invertidos (lógica “1” ≈ tensão negativa, lógica “0” ≈ positiva), mas a sequência start/dados/stop permanece idêntica.

Exemplo rápido: tempo para transmitir “Hello”

Com configuração 8N1 (1 start, 8 dados, 1 stop) cada byte usa 10 bits na linha. A 9600 baud, isso dá ~960 bytes/s. Para 5 bytes (“Hello”) leva ~5,21 ms.

Capítulo 2 – Monitorar/snifar, depurar e registrar uma comunicação serial com dois adaptadores USB-para-serial

2.1 Objetivo

Criar um monitor/sniffer serial não intrusivo para observar, depurar e registrar os bytes trocados entre o Dispositivo 1 e o Dispositivo 2 sem interromper sua comunicação.

2.2 Conexões elétricas (tapping passivo)

• COM5 (USB-para-serial #1): conecte o pino RX do adaptador ao TX do Dispositivo 1 (snife os dados enviados pelo Dispositivo 1).
• COM6 (USB-para-serial #2): conecte o pino RX do adaptador ao TX do Dispositivo 2 (snife os dados enviados pelo Dispositivo 2).
• GND comum: conecte o terra de ambos os adaptadores USB-para-serial ao dos dois dispositivos (referência compartilhada para níveis lógicos).
• Não conecte os TX dos adaptadores ao barramento: permanecemos em modo “somente escuta” de alta impedância, sem perturbar a linha.
• Não alimente os dispositivos a partir dos 5V/3,3V dos adaptadores (VCC não é usado no tapping).

Observação de nível: este método se aplica a UART/TTL (3,3/5 V) ou a barramentos com drivers compatíveis. Para RS-232 (±12 V) não conecte um RX TTL diretamente: você precisa de um conversor RS-232↔USB ou de um tap/monitor RS-232 dedicado. Em outras palavras, se quiser registrar uma linha RS-232, use o hardware adequado.

2.3 Encontrando e ajustando a taxa de baud

Para decodificar os dados corretamente, a taxa de baud e os parâmetros devem corresponder aos dos dispositivos (por exemplo, 9600/8N1). Se desconhecida:

• Verifique a documentação do dispositivo ou do protocolo.
• Tente as taxas de baud mais comuns (9600, 19200, 38400, 57600, 115200...).
• Meça com um osciloscópio/analizador lógico: a duração do bit é Tbit=1/baud (por exemplo, a 9600 baud ≈ 104,17 µs por bit).

2.4 Abrindo as duas portas COM com o SerialTool

1. Conecte os adaptadores: o sistema verá duas portas (neste exemplo COM5 e COM6).
2. No SerialTool, abra duas sessões:
   • Sessão A → COM5, ajuste baud/paridade/stop como nos dispositivos (por exemplo, 115200/8N1).
   • Sessão B → COM6, mesmos parâmetros da Sessão A.
3. Coloque ambas em monitor (apenas RX): em COM5 você verá os bytes enviados pelo Dispositivo 1 e em COM6 os do Dispositivo 2.
4. Para depuração, use a visualização HEX e marcas de tempo; para registro, salve em arquivo (CSV/pcap/raw) para análise posterior.

Nesse cenário você atua como um man-in-the-middle físico passivo: você monitora/snifa os dados eletricamente sem alterar os sinais.

2.5 Pinos de controle excluídos neste exemplo

O diagrama foca nos dados TX/RX e não monitora pinos de controle (por exemplo, RTS/CTS, DTR/DSR, DCD, RI). Para muitas aplicações eles são desnecessários; porém, se os dispositivos usam controle de fluxo por hardware, você pode “tapar” essas linhas com sondas dedicadas.

Leitura adicional: RS-232 (Wikipedia), RS-232 – Sinais, Controle de fluxo por hardware, UART.

2.6 Dicas práticas para um monitor/sniffer estável

• Use cabos curtos e um GND comum sólido; evite laços de terra.
• A maioria dos drivers UART tolera duas entradas RX (fan-out) em uma linha TX, mas evite carga desnecessária.
• Sempre alinhe os parâmetros de porta em ambas as sessões (baud, dados, paridade, stop).
• Para RS-485 ou barramentos diferenciais, você precisa de adaptadores específicos e regras de tapping diferentes.

Com essa técnica você pode monitorar, snifar, depurar e registrar comunicações seriais entre dois dispositivos usando ferramentas comuns: dois adaptadores USB-para-serial + SerialTool.

Capítulo 3 – Sniffando/monitorando o enlace serial entre “PC Mestre” e “Dispositivo Alvo”

3.1 Propósito e conceitos

Queremos monitorar e snifar os bytes que trafegam entre o software no PC Mestre e o Dispositivo Alvo, sem interferir na comunicação. É um típico man-in-the-middle físico passivo: dois adaptadores USB-para-serial conectados apenas em RX “leem” cada direção. Isso é útil para depuração, análise de protocolo e como registrador para auditoria ou engenharia reversa.

3.2 Conexões (passo a passo)

1. COM5 (PC Sniffer) → conecte o RX do adaptador ao TX do Dispositivo (escute o que o Alvo envia).
2. COM6 (PC Sniffer) → conecte o RX do adaptador ao TX do PC (escute os comandos do PC Mestre).
3. GND comum entre os dois adaptadores e os dois dispositivos (referência compartilhada).
4. Não conecte os TX dos adaptadores do PC Sniffer: permanecemos em somente escuta (alta impedância), sem perturbar a linha.

No SerialTool abra duas sessões: COM5 e COM6. Em ambas, defina a taxa de baud e o formato idênticos aos usados pelo Mestre/Dispositivo (por exemplo, 115200-8N1). Se você não souber a baud, tente valores comuns ou meça a duração do bit com um osciloscópio/analizador lógico.

3.3 Mesmo protocolo, níveis diferentes: UART/TTL, RS-232, RS-485

O protocolo serial assíncrono (start, 7/8 bits de dados enviados com LSB primeiro, paridade opcional, 1+ stop) é o mesmo. Só muda o nível físico sobre o qual os bits trafegam:

• UART/TTL (3,3 V/5 V): sinais single-ended, “1” alto / “0” baixo.
• RS-232: níveis invertidos e ± tensão (tipicamente ±3…±12 V), ainda single-ended.
• RS-485: diferencial no par A/B, frequentemente half-duplex multi-drop; recomenda-se um terra de referência comum.

Portanto, use o adaptador correto: USB↔TTL para UART, USB↔RS-232 para RS-232, USB↔RS-485 para RS-485. O quadro permanece idêntico, mas os níveis elétricos e a topologia (diferencial/terminação) diferem.

3.4 Onde é usado (CNC, industrial, etc.)

Essa configuração é comum em CNC, máquinas industriais, PLC/HMI, robótica, balanças, POS, sensores, instrumentos, automação predial e, em geral, qualquer sistema onde um PC/PLC controla um dispositivo via serial. O método de sniffing descrito aqui permite monitorar/snifar/depurar/registrar o tráfego para análise funcional, diagnóstico de falhas, rastreamento de comandos e validação.

3.5 Modbus sobre serial

Portas seriais frequentemente carregam Modbus RTU/ASCII, um protocolo amplamente usado de mestre/escravo (agora cliente/servidor) na indústria. O Mestre envia requisições (leitura/escrita de coils e registers) e o Dispositivo responde. O SerialTool inclui um cliente Modbus para consultar rapidamente registradores (diagnóstico e testes), além do monitor/visualizador hex útil para ver quadros brutos (endereço, função, dados, CRC).

3.6 Atualização de firmware e parametrização

No mundo embarcado a serial é amplamente usada para atualizações de firmware ou passagem de parâmetros ao Alvo. Exemplos: bootloaders em placas customizadas, ecossistemas como Arduino, diversos microcontroladores. Aqui o desenvolvedor pode ter duas necessidades:

1. Depurar a aplicação que conversa com o Alvo (verificar comandos, temporização, erros).
2. Engenharia reversa de um protocolo existente (há um software Mestre “fechado” conversando com uma placa; eu snifo para entender suas mensagens e depois as replico com meu próprio software).

3.7 Observações práticas e ferramentas

• Essa configuração normalmente requer dois PCs (o Mestre e o PC Sniffer) e pelo menos dois conversores USB-para-serial para sniffing bidirecional.
• Para RS-232 use um tap/conversor RS-232; para RS-485 conecte uma interface somente de recepção aos terminais A/B (respeitando a terminação e a polaridade). Em RS-485 half-duplex você inferirá a direção pelo contexto de temporização.
• Excluímos pinos de controle (RTS/CTS, DTR/DSR, DCD, RI); se o sistema usa controle de fluxo por hardware, considere sondas dedicadas.
• No SerialTool você pode ativar visualizações HEX, marcas de tempo e salvar como registrador (texto/CSV/pcap) para análise posterior.

Em resumo: mesmo protocolo serial (quadros assíncronos), níveis físicos diferentes (TTL/RS-232/RS-485). Com tapping passivo de dois RX e software como o SerialTool você pode monitorar, snifar, depurar e registrar de forma confiável a comunicação entre um PC Mestre e um Dispositivo Alvo.

Capítulo 4 – COM Sniffer: monitor/sniffer/depurador/registrador sem cabeamento físico

4.1 O que o COM Sniffer faz

O COM Sniffer é um monitor de porta serial que intercepta a comunicação em uma porta COM já aberta por outro programa, permitindo monitorar, snifar, depurar e registrar todo o tráfego (TX/RX) sem tocar nos cabos, sem hardware extra e sem afetar a operação do PC Mestre ou do Dispositivo Alvo.

4.2 Como funciona: driver de kernel

O núcleo é um driver de kernel para Windows que se insere na pilha da porta serial e observa seletivamente:

• Buffers de dados lidos/escritos (TX ↔ RX) com clara separação de direção;
• IOCTL (Input/Output Control): aberturas/fechamentos, configurações de baud/paridade/stop, timeouts, sinais de controle (RTS/DTR/CTS/DSR/DCD/RI) etc.;
• Eventos/SINAIS e status da porta (status de linha, status de modem).

O driver é poderoso e a interface é simples: você pode filtrar por tipo (apenas dados, apenas IOCTL de configuração, apenas sinais, etc.) para focar no que importa. Ele é projetado para capturas de longa duração (horas/dias) com estabilidade, para monitorar seu app ou um de terceiros. Observação: funciona apenas no Windows porque depende de drivers em modo kernel.

4.3 Por que é melhor (em muitos casos) do que cabeamento físico

• Nada de “laboratório” com dois PCs + dois USB-para-serial: economize tempo e reduza pontos de falha.
• Impacto elétrico zero: você não carrega as linhas, sem risco de laços de terra.
• Veja tudo entre app e driver: dados, IOCTL, sinais, até mesmo em múltiplas portas simultaneamente.

4.4 Registro e exportação para análise de protocolo

Você pode salvar diretamente em arquivo como registrador (texto/CSV) ou exportar para pcap/pcapng para análise no Wireshark. Isso é extremamente útil para protocolos industriais como Modbus RTU/ASCII: com quadros e marcas de tempo você pode validar temporização, CRC, sequências de funções etc.

4.5 O que você pode observar

• Dados TX/RX separadamente, em ASCII e HEX, com marcas de tempo;
• Parâmetros da porta definidos pelo software (baud, 7/8 bits, paridade, stop, timeouts);
• Sinais de controle e IOCTL (RTS, DTR, CTS, DSR, DCD, RI) e mudanças de estado;
• Eventos de abrir/fechar e erros (overrun, framing, paridade).

4.6 Quando usar

• Depurar sua aplicação serial sem mudar código/cabeamento;
• Monitoramento de longo prazo de aplicações de terceiros para auditoria/diagnóstico;
• Engenharia reversa de protocolos proprietários (onde permitido por lei) para replicar funções com seu próprio software;
• Validação de protocolos padrão (por exemplo, Modbus) e de sinais de handshaking.

4.7 Observações e leituras adicionais

O COM Sniffer trabalha no nível do sistema com a lógica do protocolo serial assíncrono (start/dados/paridade/stop). Se a aplicação usa níveis físicos diferentes (UART/TTL, RS-232, RS-485) a captura permanece idêntica, pois acontece acima do nível elétrico, dentro da pilha de portas COM do Windows.

Links úteis: Porta serial · UART · RS-232 · RS-485 · IOCTL · Drivers de kernel do Windows · Wireshark · Modbus.

Em resumo: o COM Sniffer do SerialTool é uma solução “somente software” para monitorar, snifar, depurar e registrar uma porta serial aberta por outros programas, com um driver de kernel confiável, filtros direcionados e exportação para análise avançada.