AI-translated from English; not yet reviewed by a fluent editor. # Use registros USB pareados para investigar um dispositivo sem suporte no Linux > Um guia baseado em documentação para registrar a mesma operação de hardware com o driver do fabricante no Windows e com um driver Linux, e então testar as diferenças em hardware real. By BIG CHANGE Editorial Published: 2026-10-17T02:51:13.544Z Updated: 2026-10-17T02:51:13.544Z Canonical: https://bigchange.ai/blog/compare-usb-traces-linux-device-driver ![Two sheets with abstract trace rows, one orange highlighted, beside a closed generic USB device connected to a small computer.](https://bigchange.ai/api/media/file/usb-trace-comparison-concept-v1.png) AI-generated conceptual illustration by BIG CHANGE; no actual captures, identifiable vendor device or tested repair is depicted. Christian Schaller conseguiu que um scanner de filmes sem suporte produzisse uma digitalização reconhecível no Linux depois de registrar o que o driver Windows enviava por USB. Em seu [relato de 15 de outubro](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/), ele descreve como usou o Claude para ajudar a analisar essas capturas e desenvolver um backend SANE. A primeira digitalização ainda tinha problemas de qualidade; mais tarde, ele relatou ter obtido um driver muito melhor. São resultados de um desenvolvedor e um scanner, não uma medição reproduzida de forma independente sobre a frequência com que a IA consegue escrever drivers. Depois, Schaller publicou o [hw-harness](https://github.com/cschalle/hw-harness), uma coleção de scripts e documentação sob licença MIT que generaliza seu método. Ele afirma explicitamente que os projetos do scanner e da câmera usaram código feito sob medida, não o harness publicado em sua forma atual. Para um desenvolvedor de drivers Linux com acesso físico a um dispositivo USB sem suporte, a tarefa útil é mais restrita do que “deixar a IA fazer engenharia reversa”: capturar uma operação com o driver funcional do fabricante, capturar a mesma operação com o driver Linux e investigar a primeira diferença significativa. ## A grande mudança - **O que mudou:** Schaller reuniu uma forma repetível de registrar uma sessão funcional de um dispositivo Windows e uma tentativa com um driver Linux usando o mesmo gravador USB no host. Seu resultado com o scanner mostra por que essa comparação pode ajudar, mas continua sendo um único caso relatado. - **Por que importa:** Um desenvolvedor de drivers pode fornecer registros identificados a um assistente de programação com IA e pedir uma possível explicação do protocolo ou um pequeno programa de sondagem. Antes de aceitar qualquer código gerado, ainda precisa do hardware, de uma operação de referência funcional e de testes diretos. - **O que acompanhar:** O método depende de ser possível observar o tráfego relevante do dispositivo. Para uma câmera MIPI interna, o harness publicado recorre à configuração de dispositivos Windows e à inspeção de ACPI; um procedimento de captura USB deixaria de fora as informações necessárias ao desenvolvedor. ## O que você precisa antes da captura O [README do hw-harness](https://github.com/cschalle/hw-harness) informa que o projeto foi desenvolvido e testado no Fedora. A configuração documentada exige libvirt/KVM, um sistema convidado Windows que execute o driver do fabricante, passthrough USB real, captura com `usbmon` no host Linux e um driver Linux ou programa de sondagem para comparar. O Windows 11 Pro permite usar os controles gráficos do harness baseados em RDP. O [guia da VM](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) diz que um convidado Home ainda pode usar SSH, mas não esses controles RDP. O repositório lista os pacotes Fedora e as permissões de grupo; execute `harness doctor` na revisão obtida do repositório para identificar o que falta antes de conectar o dispositivo. Tenha uma instalação Windows e software do fabricante cujo uso seja permitido, o dispositivo exato, uma operação repetível e espaço para capturas de pacotes. Inclua no orçamento uma VM, acesso ao hardware, Windows e o serviço de IA escolhido; o repositório não informa um custo total fixo. Os scripts têm licença MIT, mas isso não concede uma licença do Windows ou do software do fabricante. Confira seus termos de licença e as regras de engenharia reversa aplicáveis antes de usar ou distribuir o que coletar. Use um diretório de projeto separado para cada dispositivo. O README diz que `harness init` cria a configuração e os diretórios ignorados `etc/` e `captures/`. Preencha o nome da VM e os IDs USB do fabricante/produto a partir do seu dispositivo, em vez de copiar os valores de exemplo do README. `winctl auth`, `harness iso` e a inicialização documentada do convidado estabelecem o controle da VM Windows; `winctl status` deve informar `ssh: ok` antes de uma captura. Esta é a configuração documentada do projeto, não uma sequência executada pelo BIG CHANGE. ## Reproduza a mesma operação nos dois sistemas 1. **Registre a linha de base e uma referência Windows.** Siga o [documento do método](https://github.com/cschalle/hw-harness/blob/main/doc/method.md) do repositório: primeiro, entenda como é o tráfego em repouso. Inicie a captura no host antes de entregar o dispositivo USB ao convidado se precisar da enumeração inicial. Execute o driver Windows do fabricante no dispositivo em passthrough e identifique uma ação curta e específica, como uma digitalização na resolução indicada. `usbcap` captura o barramento e grava um arquivo auxiliar `.meta` com o dispositivo, endereço no barramento, duração e identificação. O ponto de captura no host fica abaixo do passthrough USB, então consegue observar a operação do convidado. 2. **Registre a operação correspondente no Linux.** Devolva o dispositivo ao host e capture seu driver Linux executando a mesma operação, com as mesmas configurações e o mesmo material físico. Uma captura de referência sem uma execução Linux correspondente não permite determinar em qual ação os drivers divergiram. O comando de scanner do repositório é um exemplo para a configuração do autor, não um comando universal para todos os dispositivos. 3. **Compare e teste uma hipótese.** Leia os dois registros no Wireshark ou com os filtros `tshark` do documento do método. Verifique as transferências de inicialização, as escritas que antecedem e sucedem a ação, as consultas de status e a temporização das transferências em massa. Altere uma configuração de cada vez, como a resolução, para ver qual transferência muda. Peça a um assistente de IA que identifique uma possível diferença e cite a captura e o quadro que a sustentam. Então faça uma alteração limitada no driver ou um programa de sondagem e repita a mesma operação em hardware real. Uma explicação plausível na resposta de um modelo não é sinal de sucesso. O resultado imediato é um par de arquivos de captura identificados e uma descrição da primeira divergência significativa. Um reparo bem-sucedido exige que o dispositivo Linux execute consistentemente a operação pretendida, com a saída esperada, nas verificações do próprio desenvolvedor. Alguns bytes iguais ou uma imagem parcial não demonstram a qualidade completa do driver. No relato de Schaller, a primeira digitalização reconhecível ainda precisava de trabalho, e o suporte ao seu scanner no projeto principal SANE apareceu separadamente enquanto ele trabalhava. Se os registros forem difíceis de comparar, encurte a operação e confirme que dispositivo, configurações e camada de captura correspondem. O método recomenda capturas pequenas que respondam a uma pergunta e uma captura única da conexão do dispositivo. Se o passthrough ou o controle do convidado falhar, use `harness doctor`, `hostdev status` e o [guia de configuração da VM](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) antes de interpretar um registro vazio como falha do driver. Guarde as capturas e anotações originais para que uma constante de registrador proposta possa ser rastreada até um quadro observado. ## Onde a captura USB deixa de ajudar Uma câmera MIPI interna não expõe o mesmo tráfego útil ao gravador USB do host. O documento do método descreve, em vez disso, o uso de `winctl probe` para propriedades PnP do Windows, arquivos INF, entradas do Registro e tabelas ACPI, além da inspeção no Linux por meio de `hwdbg`. Schaller relata ter aplicado esse outro caminho à câmera de seu notebook, com patches do kernel e do libcamera; esses resultados também vêm de seu relato. Não use um resultado com a câmera como prova de que o ciclo USB funcionou em outro dispositivo. Mantenha a investigação no comportamento observado do dispositivo e na configuração declarativa. O [guia clean-room](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) do repositório exclui desassemblar binários do fabricante ou copiar seu código para um driver Linux. Ele também alerta que as capturas podem incluir números de série de dispositivos e que o diretório do projeto contém uma chave SSH privada. Revise registros, identificadores dos dispositivos e arquivos do convidado antes de fornecê-los a um serviço de IA ou compartilhá-los publicamente; mantenha chaves e capturas brutas fora do controle de versão. As instruções publicadas estabelecem um método para experimentar. O BIG CHANGE examinou o blog e o repositório na revisão fixada, mas não executou a VM, capturou um dispositivo ou validou um driver resultante. ### Fontes e leituras adicionais - [O relato de Christian Schaller de 15 de outubro](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/) explica seu trabalho com o scanner e o notebook, o papel que atribui ao Claude e por que o harness compartilhado veio depois dos scripts feitos sob medida. O resultado do scanner é seu relato, sem reprodução independente neste artigo. - [O repositório hw-harness](https://github.com/cschalle/hw-harness) descreve as ferramentas, os pré-requisitos Fedora e Windows, o exemplo de configuração e o alerta de privacidade do projeto. O BIG CHANGE examinou o commit `093afc5c576c200f29b771d01624a327d0ff1806` de 14 de outubro de 2026; o repositório tem licença MIT e pode mudar depois dessa revisão. - [O método](https://github.com/cschalle/hw-harness/blob/main/doc/method.md) especifica a linha de base, a referência, a comparação Linux e o ciclo de repetição, os cuidados com capturas, a leitura de registros USB e o caminho separado para dispositivos sem um barramento visível ao host. - [A configuração da VM Windows de referência](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) abrange o acesso ao convidado, o passthrough USB e a diferença entre Windows Pro e Home nos controles RDP. Confira os termos de licença da sua instalação. - [Os limites clean-room](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) apresentam a prática do projeto baseada em observação, os limites relacionados aos binários do fabricante e a necessidade de registrar a origem das constantes. São orientações de engenharia do projeto, não um parecer jurídico. ## Sources - [Christian Schaller: Usando inteligência artificial para fazer engenharia reversa de hardware](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/) — Relato em primeira pessoa do autor sobre scanner e câmera; afirma explicitamente que o harness generalizado veio depois dos scripts específicos dos projetos. Os resultados de dispositivos individuais são relatos de casos e não foram reproduzidos de forma independente pelo BIG CHANGE. - [Repositório hw-harness no commit 093afc5](https://github.com/cschalle/hw-harness) — README, ferramentas, pré-requisitos Fedora/Windows, exemplo de fluxo de trabalho e nota de privacidade; licença MIT verificada em LICENSE. Commit fixado na auditoria das fontes. - [hw-harness: O método](https://github.com/cschalle/hw-harness/blob/main/doc/method.md) — Linha de base, capturas correspondentes, leitura de registros e inspeção separada da configuração quando o barramento relevante não está disponível. Examinado no commit 093afc5. - [hw-harness: A VM Windows de referência](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) — Pré-requisitos do convidado, passthrough e RDP/SSH, incluindo os limites do Windows Home; as decisões de instalação e licença dependem de cada usuário. Examinado no commit 093afc5. - [hw-harness: Permanecendo em clean-room](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) — Limites do projeto quanto à observação e aos binários do fabricante, orientações de origem e cautela com pacotes não confiáveis; prática de engenharia, não aconselhamento jurídico. Examinado no commit 093afc5.