Edição Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Use capturas USB emparelhadas para investigar um dispositivo sem suporte no Linux

> Um guia baseado em documentação para registar a mesma operação de hardware com um controlador do fabricante para Windows e um controlador Linux, comparar as capturas e 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 digitalizador de película sem suporte produzisse uma digitalização reconhecível no Linux depois de registar o que o respetivo controlador Windows enviava por USB. No seu [relato de 15 de outubro](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/), 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, relatou ter obtido um controlador muito melhor. São resultados de um programador e de um digitalizador, não uma avaliação reproduzida de forma independente da frequência com que a IA consegue escrever controladores.

Posteriormente, Schaller publicou o [hw-harness](https://github.com/cschalle/hw-harness), um conjunto de scripts e documentação com licença MIT que generaliza o seu método. Diz explicitamente que os projetos do digitalizador e da câmara usaram código feito à medida, não o harness publicado na sua forma atual. Para um programador de controladores Linux com acesso físico a um dispositivo USB sem suporte, a tarefa útil é mais limitada do que «deixar a IA fazer engenharia inversa»: captar uma operação com o controlador funcional do fabricante, captar a mesma operação com o controlador Linux e investigar a primeira diferença significativa.

## A grande mudança

- **O que mudou:** Schaller reuniu um método repetível que coloca uma sessão funcional de um dispositivo Windows e uma tentativa com um controlador Linux sob o mesmo gravador USB do sistema anfitrião. O resultado do seu digitalizador mostra por que motivo esta comparação pode ajudar, mas continua a ser um único caso relatado.
- **Porque importa:** Um programador de controladores pode fornecer capturas identificadas a um assistente de programação com IA e pedir-lhe uma possível explicação do protocolo ou um pequeno teste de diagnóstico. O programador continua a precisar do hardware, de uma operação de referência funcional e de testes diretos antes de aceitar qualquer código gerado.
- **O que acompanhar:** O método depende de ser possível observar o tráfego relevante do dispositivo. Para uma câmara MIPI interna, o harness publicado recorre antes à configuração de dispositivos Windows e à inspeção de ACPI; uma receita de captura USB deixaria de fora a informação de que o programador precisa.

## O que precisa antes de uma captura

O [README do hw-harness](https://github.com/cschalle/hw-harness) indica que este foi desenvolvido e testado no Fedora. A configuração documentada requer libvirt/KVM, um sistema convidado Windows com o controlador do fabricante, passagem direta real de USB, captura com `usbmon` no anfitrião Linux e um controlador Linux ou teste de diagnóstico para comparação. O Windows 11 Pro permite os controlos gráficos do harness baseados em RDP. O [guia da máquina virtual](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) diz que um convidado Home pode continuar a usar SSH, mas não esses controlos 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 detetar componentes em falta antes de ligar o dispositivo.

Tenha uma instalação Windows e software do fabricante cuja utilização lhe seja permitida, o dispositivo exato, uma operação repetível e espaço para capturas de pacotes. Conte com os custos de uma máquina virtual, acesso ao hardware, Windows e qualquer serviço de IA que escolha; o repositório não indica um custo total fixo. Os scripts têm licença MIT, mas isso não concede uma licença Windows nem de software do fabricante. Verifique os seus próprios termos de licença e as regras de engenharia inversa aplicáveis antes de utilizar ou distribuir o que recolher.

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 máquina virtual e os identificadores USB do fabricante/produto a partir do dispositivo, em vez de copiar os valores de exemplo do README. `winctl auth`, `harness iso` e a inicialização documentada do convidado estabelecem o controlo da máquina virtual Windows; `winctl status` deve indicar `ssh: ok` antes de uma captura. Encare isto como a configuração documentada do projeto, não como uma sequência executada pelo BIG CHANGE.

## Reproduza a mesma operação nos dois sistemas

1. **Registe uma 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: comece por perceber como é o tráfego em repouso. Inicie a captura no anfitrião antes de entregar o dispositivo USB ao convidado se precisar da enumeração inicial. Execute o controlador Windows do fabricante com o dispositivo passado diretamente e identifique uma ação curta e específica, como uma digitalização com uma resolução indicada. `usbcap` capta o barramento e grava um ficheiro auxiliar `.meta` com o dispositivo, endereço no barramento, duração e identificação. O ponto de captura no anfitrião fica abaixo da passagem direta USB, pelo que consegue observar a operação do convidado.
2. **Registe a operação correspondente no Linux.** Devolva o dispositivo ao anfitrião e capte o controlador Linux a executar a mesma operação, com as mesmas definições e o mesmo material físico. Uma captura de referência sem uma execução Linux correspondente não permite determinar em que ação os controladores divergiram. O comando de digitalização 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 as duas capturas no Wireshark ou com os filtros `tshark` do documento do método. Verifique as transferências de inicialização, as escritas que antecedem e seguem a ação, a consulta periódica do estado e a temporização das transferências em massa. Altere uma definição de cada vez, como a resolução, para ver que transferência muda. Peça a um assistente de IA que identifique uma possível diferença e cite a captura e a trama que a sustentam. Depois, faça uma alteração limitada no controlador ou um teste de diagnóstico e repita a mesma operação em hardware real. Uma explicação plausível numa resposta do modelo não é sinal de sucesso.

O resultado imediato é um par de ficheiros de captura identificados e uma descrição da primeira divergência significativa. Uma reparação bem-sucedida exige que o dispositivo Linux execute de forma consistente a operação pretendida, com o resultado esperado, nas verificações do próprio programador. A correspondência de alguns bytes ou a produção de uma imagem parcial não demonstra a qualidade global do controlador. No relato de Schaller, a primeira digitalização reconhecível ainda precisava de trabalho, e o suporte no projeto principal SANE para o seu digitalizador surgiu separadamente enquanto ele trabalhava.

Se as capturas forem difíceis de comparar, encurte a operação e confirme que o dispositivo, as definições e a camada de captura coincidem. O método recomenda capturas pequenas que respondam a uma pergunta e uma captura da ligação do dispositivo feita uma vez. Se a passagem direta ou o controlo do convidado falharem, utilize `harness doctor`, `hostdev status` e o [guia de configuração da máquina virtual](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) antes de interpretar uma captura vazia como falha do controlador. Guarde as capturas e notas originais para poder relacionar uma constante de registo proposta com uma trama observada.

## Os limites da captura USB

Uma câmara MIPI interna não expõe o mesmo tráfego útil ao gravador USB do anfitrião. Em alternativa, o documento do método descreve o uso de `winctl probe` para propriedades PnP do Windows, ficheiros INF, entradas do registo e tabelas ACPI, além da inspeção no Linux através de `hwdbg`. Schaller relata ter aplicado essa via diferente à câmara do seu portátil, com alterações ao kernel e ao libcamera; esses resultados também provêm do seu relato. Não use um resultado obtido com uma câmara como prova de que o ciclo USB funcionou noutro dispositivo.

Mantenha a investigação centrada 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 a desmontagem de binários do fabricante ou a cópia do seu código para um controlador Linux. 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. Reveja capturas, identificadores de dispositivos e ficheiros do convidado antes de os entregar a um serviço de IA ou de os partilhar publicamente; mantenha as chaves e as capturas em bruto fora do controlo de versões. As instruções publicadas estabelecem um método a experimentar. O BIG CHANGE examinou o blogue e o repositório na revisão fixada, mas não executou a máquina virtual, não captou um dispositivo nem validou um controlador resultante.

### Fontes e leituras adicionais

- [O relato de Christian Schaller de 15 de outubro](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/) explica o seu trabalho com o digitalizador e o portátil, o papel que atribui ao Claude e por que motivo o harness partilhado surgiu depois dos scripts feitos à medida. O resultado do digitalizador é relatado pelo autor, sem reprodução independente neste artigo.
- [O repositório hw-harness](https://github.com/cschalle/hw-harness) descreve as ferramentas, os requisitos Fedora e Windows, a configuração de exemplo e o aviso 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 as capturas, a leitura de tráfego USB e a via separada para dispositivos sem um barramento visível ao anfitrião.
- [A configuração da máquina virtual Windows de referência](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) abrange o acesso ao convidado, a passagem direta USB e a diferença entre Windows Pro e Home nos controlos RDP. Verifique os termos de licença da sua própria instalação.
- [Os limites clean-room](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) definem a prática do projeto baseada na observação, os limites relativos a binários do fabricante e a necessidade de registar a origem das constantes. São orientações de engenharia do projeto, não um parecer jurídico.

## Sources

- [Christian Schaller: Usar inteligência artificial para fazer engenharia inversa de hardware](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/) — Relato na primeira pessoa do autor sobre um digitalizador e uma câmara; indica explicitamente que o harness generalizado surgiu depois dos scripts feitos à medida para os 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, requisitos Fedora/Windows, exemplo de fluxo de trabalho e nota de privacidade; licença MIT verificada no ficheiro 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 tráfego e inspeção separada da configuração quando o barramento relevante não está acessível. Examinado no commit 093afc5.
- [hw-harness: A máquina virtual Windows de referência](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) — Requisitos do convidado, de passagem direta e de RDP/SSH, incluindo os limites do Windows Home; as decisões de instalação e licenciamento dependem de cada utilizador. Examinado no commit 093afc5.
- [hw-harness: Manter a abordagem 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 proveniência e cautela com pacotes não fiáveis; prática de engenharia, não aconselhamento jurídico. Examinado no commit 093afc5.