Filtros USB no Wireshark: como achar o dispositivo certo com USBPcap, usbmon e Bus Scope

Capturas USB podem virar um mar de dados em segundos. Uma máquina pode ter, ao mesmo tempo, teclado, mouse, webcam, adaptador Bluetooth, dispositivo de armazenamento, adaptador serial, chave de segurança e hub interno ativos. Quando alguém busca por "Wireshark USB filter", "USBPcap filter device", "usbmon filter endpoint" ou "how to find my USB device in capture", o problema é quase sempre o mesmo: "a captura tem tráfego demais e estrutura de menos." O Bus Scope foi feito para tornar a inspeção USB mais direta, mas entender o problema de filtragem ainda ajuda. A captura pode vir do USBPcap no Windows, do usbmon no Linux ou de outra fonte, e o caminho é identificar o dispositivo e depois estreitar o trace por endereço, endpoint, tipo de transferência e requisição de controle.

Comece pela enumeração

A forma mais fácil de identificar um dispositivo USB é capturar desde a conexão. A enumeração traz descritores que nomeiam o dispositivo, o vendor ID, o product ID, as configurações, as interfaces, os endpoints e detalhes específicos de classe.

Procure por:

• Vendor ID
• Product ID
• device descriptor
• configuration descriptor
• interface descriptors
• endpoint descriptors
• string descriptors
• SET_ADDRESS
• SET_CONFIGURATION

Se você começa a captura depois do dispositivo já estar rodando, talvez só veja tráfego de endpoint sem o contexto de descritor. Isso dificulta a filtragem porque só o número de endpoint não basta.

O endereço do dispositivo pode mudar

Os endereços de dispositivo USB são atribuídos pelo host durante a enumeração. Se o dispositivo se desconecta e reconecta, o endereço pode mudar. Um filtro que funcionou na primeira conexão pode deixar passar a segunda.

Isso importa na depuração de loops de reset. Se um dispositivo reenumera várias vezes, você pode precisar rastrear vários endereços em uma única captura. Os descritores de produto e vendor revelam que esses endereços pertencem ao mesmo dispositivo físico.

O Bus Scope ajuda a manter essa relação visível em vez de obrigar você a costurar mentalmente as mudanças de endereço.

Filtre por endpoint

Depois da configuração, a maior parte do tráfego de dados usa endpoints. Endpoint zero é o de controle. Os outros podem ser bulk, interrupt ou isochronous.

Significados comuns de endpoint:

• 0x00: control OUT no endpoint zero
• 0x80: control IN no endpoint zero
• 0x81: endpoint 1 IN
• 0x01: endpoint 1 OUT
• 0x82: endpoint 2 IN
• 0x02: endpoint 2 OUT

O bit de direção importa. 0x81 e 0x01 não são a mesma direção de endpoint. Um adaptador serial, por exemplo, pode usar um bulk OUT para dados do host para o dispositivo e um bulk IN para dados do dispositivo para o host.

Filtros por endpoint são úteis depois que você já sabe qual endpoint carrega o tráfego que te interessa.

Filtre por tipo de transferência

Problemas diferentes de USB vivem em tipos de transferência diferentes:

• Control transfers: descritores, configuração, requisições de classe, comandos vendor.
• Bulk transfers: armazenamento, dados seriais, dados vendor, muitos dispositivos de captura.
• Interrupt transfers: entrada HID, notificações de status, relatórios de baixa latência.
• Isochronous transfers: áudio, vídeo, streaming sensível a tempo.

Se um dispositivo USB serial abre, mas não envia dados, inspecione as control transfers de line coding e control line state, depois os bulk endpoints em busca de payload. Se uma webcam inicia, mas o vídeo sai corrompido, inspecione as isochronous transfers e os alternate settings. Se um dispositivo HID se comporta mal, inspecione as interrupt transfers e os descritores de relatório.

Filtrar por tipo de transferência reduz o ruído e mantém a classe relevante de evidência.

Filtre por pacote de setup

Control transfers incluem pacotes de setup. Eles são extremamente úteis porque identificam a direção, o tipo, o recipient, o request code, o value, o index e o length da requisição.

Exemplos importantes:

• GET_DESCRIPTOR
• SET_ADDRESS
• SET_CONFIGURATION
• SET_INTERFACE
• CLEAR_FEATURE
• HID GET_REPORT
• HID SET_REPORT
• CDC SET_LINE_CODING
• CDC SET_CONTROL_LINE_STATE
• comandos vendor-specific

Quando um dispositivo falha no setup, o pacote de setup geralmente mostra qual requisição disparou o problema.

Seleção de captura USBPcap no Windows

No Windows, o USBPcap captura a partir de host controllers USB. Se a máquina tem vários controllers, escolher o errado pode gerar uma captura sem nenhum tráfego do dispositivo alvo.

Um fluxo prático:

1. Desconecte o dispositivo alvo.
2. Inicie a captura no controller provável.
3. Conecte o dispositivo.
4. Procure os descritores de enumeração.
5. Se nada aparecer, tente outro controller.
6. Quando o dispositivo for encontrado, mantenha a captura por perto como referência.

O valor do Bus Scope está em tornar esse fluxo menos opaco: o alvo é a conversa USB do dispositivo, não uma lista enorme de pacotes.

Captura com usbmon no Linux

No Linux, o usbmon expõe o tráfego dos barramentos USB. O número do barramento importa. Um dispositivo listado como Bus 003 Device 012 pertence ao barramento 3 naquele momento. Depois de reconectar, o número do dispositivo pode mudar.

A captura mais útil começa antes da conexão, porque a enumeração revela a identidade do dispositivo. Se permissão bloquear a captura, resolva isso primeiro; caso contrário, você só verá a falha na camada de aplicação e nunca terá a evidência USB.

Erros comuns de filtragem

Evite estes erros:

• Filtrar só depois da falha, perdendo a enumeração.
• Assumir que o endereço do dispositivo é estável entre reconexões.
• Confundir a direção do endpoint.
• Ignorar o tráfego de controle do endpoint zero.
• Olhar só para pacotes de payload e perder requisições de classe.
• Tratar toda requisição vendor-specific como ruído.
• Filtrar resets e erros cedo demais.
• Ignorar o contexto de hub e porta.

Um filtro limpo só é útil se preservar a falha.

O que manter em uma captura de investigação

Para um relatório que você pode compartilhar com firmware, driver ou QA, mantenha:

• A enumeração inicial.
• Os descritores do dispositivo alvo.
• A configuração e a interface selecionadas pelo host.
• As requisições de classe ou vendor-specific antes da falha.
• O tráfego de endpoint envolvido na falha.
• O evento de reset, stall, timeout ou desconexão.
• Contexto de temporização suficiente para mostrar se a falha é imediata, relacionada a idle ou a carga.

Essa evidência é mais forte do que um screenshot de "device not recognized".

Diagnóstico final

Filtragem em USB não é só esconder ruído. É preservar a sequência de pacotes que explica a falha. Comece pela enumeração, identifique o dispositivo, acompanhe as mudanças de endereço, estreite por endpoint e tipo de transferência, e mantenha as control requests visíveis.

O Bus Scope foi feito para apoiar esse fluxo: encontrar rápido a conversa USB real e depois inspecionar a evidência no nível do barramento que explica por que o dispositivo funciona, trava, reseta ou desaparece.