DO WIRESHARK
AO PROXY SERIAL

O problema começou no Wireshark.

O experimento Do movimento aos bytes — explorando USB HID com Wireshark mostrou que informações normalmente invisíveis entre software e hardware podiam ser observadas. Endpoints, relatórios HID e payloads deixaram de ser abstrações e apareceram como bytes.

A descoberta permaneceu, mas a necessidade seguinte era bem mais estreita: quais bytes este software envia para esta porta COM e quais bytes o equipamento devolve?

Uma ferramenta excelente podia ser grande demais para a tarefa.

O Wireshark não foi aprovado para uso normal no computador de trabalho. A preocupação fazia sentido: captura de rede e USB em baixo nível possui alcance amplo, pode envolver drivers próprios e determinadas operações podem exigir privilégios administrativos.

Uma máquina offline dedicada à análise continuava sendo uma alternativa válida. Mas a restrição ajudou a formular uma pergunta melhor: se o objetivo era observar somente portas COM, por que capturar USB bruto, rede ou protocolos sem relação com o equipamento?

Substituir dois conversores por um null modem virtual.

O com0com cria duas portas COM conectadas entre si. Tudo que é escrito em uma ponta aparece na outra. Na validação, o par foi COM13 ↔ COM14: o software abriu COM13 e o proxy abriu COM14 junto da porta física do equipamento.

Esses números documentam o teste, não são requisitos. Qualquer par configurado pode ser informado. A instalação do driver é uma operação separada e pode exigir privilégios administrativos; o tr_serialProxy não instala nem configura drivers.

Primeiro enxergar. Interpretar depois.

A versão inicial não tenta decidir se os dados são Modbus, um protocolo proprietário, JBD, VOTOL ou CAN encapsulado. Seu núcleo é deliberadamente menor:

A análise pode ser feita posteriormente sobre os logs. Essa neutralidade permite usar o proxy com USB-TTL, USB-RS485, CDC/serial e conversores CAN que apareçam no Windows como uma COM. Interfaces CAN que dependam de API própria e não exponham uma porta serial ficam fora do escopo.

Tempo, direção, tamanho e bytes.

Cada execução cria um arquivo textual próprio. O registro inclui horário local com fuso e microssegundos, tempo decorrido medido por contador monotônico, direção, quantidade de bytes e conteúdo hexadecimal.

[2026-09-30T14:35:22.123456-03:00] [+0.381224] TX  4 bytes
00 41 7F FF

Com --raw-log, o mesmo conteúdo também é gravado como JSONL reversível:

{"time":"2026-09-30T14:35:22.123456-03:00","elapsed":0.381224,"direction":"TX","length":4,"data":"00417fff"}

Os valores acima são fictícios e vêm da documentação pública. --ascii acrescenta somente uma visualização dos caracteres imprimíveis; os bytes permanecem representados em hexadecimal.

Menos capacidade genérica, não risco zero.

Em vez de uma ferramenta capaz de observar diversos tipos de tráfego do computador, o proxy acessa apenas as duas portas seriais informadas. Isso torna seu comportamento mais limitado, previsível e auditável.

Os logs ficam locais e são ignorados pelo Git do projeto. Ainda assim, qualquer arquivo ou captura precisa ser revisado antes de sair do ambiente em que foi produzido.

Transparente nos bytes, não no tempo elétrico.

• Drivers, buffers, terminal e disco acrescentam latência; não há garantia de tempo real.
• RTS, DTR, CTS, DSR, BREAK e outros sinais de controle não são espelhados.
• Mudanças de configuração feitas pelo software na COM virtual não são propagadas automaticamente.
• Não há reconexão automática, reconstrução de frames, reconhecimento de baud ou reenvio após entrega incerta.
• Não é indicado começar por firmware ou bootloader crítico sem validação específica.

A ferramenta ficou entre duas investigações.

O artigo do Wireshark e USB HID forneceu a origem conceitual: tornar tráfego invisível observável. Já o mapeamento Entre o Greenway e o BMS mostra por que uma captura serial bidirecional pode ser útil antes de qualquer interpretação de protocolo.

O código e toda a documentação técnica estão no repositório público do tr_serialProxy ↗.

O núcleo continua pequeno.

A versão 0.1 entrega bridge bidirecional e logs. O roadmap público reserva filtros de visualização para a 0.2, estatísticas e análise de timing para a 0.3 e, no futuro, replay opcional e decodificadores como plugins.

Nenhum desses itens é apresentado como concluído. Mesmo quando crescer, a base continua sendo a mesma: capturar, registrar e retransmitir sem modificar os bytes.