DO MOVIMENTO
AOS BYTES
Um experimento com Wireshark e USBPcap que transformou movimentos do mouse, teclas e modificadores em bytes observáveis — e mostrou quanto trabalho existe entre capturar e compreender.
O que o computador e o controlador estavam trocando?
A curiosidade surgiu durante a parametrização de um controlador de moto elétrica. Ainda não havia hardware CAN disponível para observar diretamente a rede da moto e a USB talvez nem transportasse quadros CAN brutos, mas a conversa entre o software e a interface poderia revelar comandos, parâmetros, respostas, identificadores ou padrões úteis para uma investigação futura.
Uma pesquisa com apoio de IA levou ao Wireshark e ao USBPcap. Antes de apontar essas ferramentas para o controlador, decidi começar com algo simples e conhecido: o mouse.
Uma porta cotidiana cheia de comunicação.
O Wireshark é conhecido pela análise de Ethernet e Wi‑Fi, mas pode observar outros barramentos quando recebe dados de uma interface apropriada. No Windows, o USBPcap fornece essa captura USB; neste experimento, seu uso exigiu privilégios administrativos.
No início aparecem requisições e respostas GET DESCRIPTOR de dispositivo e configuração, seguidas por SET CONFIGURATION. É a enumeração: antes da comunicação normal, o host precisa descobrir o dispositivo, suas configurações e interfaces.
Nem cada linha é uma ação do usuário. USBPcap registra etapas das URBs, e uma única ação fica cercada por muitos registros. Foi fascinante perceber quanta coisa acontece ao mesmo tempo em uma porta que normalmente tratamos apenas como “conectei o mouse e funcionou”.
O mouse trouxe o teclado junto.
Mouse e teclado pertenciam ao mesmo kit e compartilhavam o receptor sem fio. O dispositivo físico expôs funções HID distintas:
Receptor USB │ ├── endpoint 0x81 / 1.1.1 → teclado │ └── endpoint 0x82 / 1.1.2 → mouse
Ambos usavam transferências URB_INTERRUPT na direção IN: dispositivo → computador. Neste receptor, um único dispositivo físico expôs funções HID acessíveis por interfaces/endpoints distintos.
O pacote capturado não era só o relatório HID.
O painel de detalhes mostrava o pseudo-header, a função URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER, endpoint, direção, tipo e somente então Packet Data Length: 8. Separar a moldura da captura do conteúdo do dispositivo foi parte essencial da investigação.
Little-endian saindo do conceito abstrato
Um campo bruto como b0 63 ff 13 8f aa ff ff aparecia interpretado como IRP ID: 0xffffaa8f13ff63b0. O valor não estava corrompido: seus bytes estavam representados em little-endian.
Movimentos controlados, bytes comparáveis.
Mover o mouse em uma direção de cada vez permitiu correlacionar o gesto físico ao payload. À direita apareceram 0200000300000000 e 0200000100000000. À esquerda, 020000ff0f000000. Movimentos verticais produziram, entre outros, 020000f8bfff0000, 020000fdefff0000 e 0200000010000000.
Neste receptor, X e Y são muito provavelmente valores signed de 12 bits empacotados em três bytes. Isso foi inferido por correlação entre movimento e dados; não é um formato universal de mouse HID.
byte 3 byte 4 byte 5
XXXXXXXX YYYYXXXX YYYYYYYY
X = byte3 + ((byte4 & 0x0F) << 8)
Y = (byte4 >> 4) + (byte5 << 4)0x001 → +1 · 0x003 → +3 · 0xFFF → −1 · 0xFFE → −2 · 0xFFD → −3. Consultar o HID Report Descriptor seria uma etapa posterior para validar formalmente a inferência.
Após reconstruir os 12 bits, valores com o bit 0x800 ativo são interpretados em complemento de dois; nesse caso, subtrai-se 0x1000 para obter o valor negativo.
movimento físico → sensor → deslocamento relativo
↓
relatório HID → Windows → cursorEssas contagens não são necessariamente pixels. Sensibilidade, aceleração e outras configurações ainda transformam o deslocamento informado no movimento final do cursor.
Alt+Tab reconstruído pelos relatórios.
O teclado observado usava um relatório de oito bytes compatível com o padrão boot-style: modificadores, um byte reservado e até seis posições de tecla. Isso descreve este receptor; não significa que todo teclado HID use a mesma estrutura.
04 00 00 00 00 00 00 00Alt esquerdo pressionado04 00 2b 00 00 00 00 00Alt + Tab04 00 00 00 00 00 00 00Tab solto; Alt permanece00 00 00 00 00 00 00 00Alt soltoUma ação completa da interface pôde ser reconstruída olhando apenas para os estados reportados.
Teclas A e B
0000040000000000 representou a tecla física A; 0000050000000000, a tecla B. Ao soltar, o relatório voltou a zeros.
Uma tela cheia de “b” não exige muitos relatórios iguais.
Ao manter B pressionado, o relatório indicou o estado da tecla e depois seu desligamento. O editor, entretanto, produziu vários caracteres. O key repeat pode ser processado pelo sistema operacional; a repetição visual não prova que o receptor enviou um novo relatório com B para cada caractere.
tecla física → HID Usage ID → USB HID
↓
Windows + layout + modificadores
↓
caractereO teclado não envia diretamente “A”, “á” ou outro caractere ASCII. Envia Usage IDs e modificadores; layout, Shift, AltGr, Caps Lock, idioma e composição ficam a cargo do sistema.
Os exemplos podem ser abertos no Wireshark.
A captura USB usada neste artigo está disponível em formato .pcapng. Ela preserva enumeração, endpoints, transferências e os payloads necessários para acompanhar a análise.
O arquivo publicado não é a captura bruta original. Foram removidos metadados identificáveis do computador e pacotes de dispositivos USB sem relação com o experimento. A enumeração do receptor compartilhado, os endpoints relevantes e os payloads HID usados neste artigo foram preservados; a higienização não altera os dados técnicos analisados.
Outro barramento, o mesmo problema de separar sinal e ruído.
Em um experimento paralelo, usei o Wireshark para observar uma interface web embarcada via Wi‑Fi. O teste não é reproduzido aqui porque ocorreu em ambiente corporativo. Nenhum endereço, nome, payload, captura ou elemento identificável desse ambiente é publicado.
Conceitualmente, a experiência deixou visíveis DHCP, DNS, mDNS, TCP, HTTP e tráfego de fundo. Mesmo numa rede aparentemente simples, filtrar já faz parte da análise.
Uma ferramenta nova para projetos que já conversavam.
A Galeria já contém investigações de RS485, telemetria e protocolos: o Bridge TTL/RS485, o Modbus RTU Slave Simulator, o DMS Portable Logger e a Inverter Modbus Lib. A interface Wi‑Fi da iluminação da bancada acrescenta outra camada.
Isso não transforma USB, Wi‑Fi, RS485 e CAN no mesmo protocolo. Registra uma continuidade de método: observar, filtrar, comparar estados e testar hipóteses antes de afirmar como um sistema funciona.
Capturas também são dados.
- Capturar somente dispositivos e redes próprios ou com autorização.
- Tratar arquivos
.pcapngcomo potencialmente confidenciais. - Revisar metadados e conteúdo antes de publicar qualquer captura.
- Não esperar que o Wireshark “quebre” criptografia: pacotes podem estar visíveis enquanto o conteúdo permanece protegido.
Capturar foi a parte fácil.
O trabalho começou ao separar ruído, controlar movimentos, comparar estados e transformar bytes em hipóteses verificáveis. Wireshark e USBPcap entraram no meu conjunto de ferramentas não porque decodificam qualquer protocolo, mas porque oferecem visibilidade para descobrir, documentar e testar.