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

# Utilisez des traces USB appariées pour étudier un appareil non pris en charge sous Linux

> Un guide fondé sur la documentation pour enregistrer la même opération matérielle avec un pilote Windows du fabricant et un pilote Linux, puis tester les différences sur du matériel réel.

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 a obtenu une numérisation reconnaissable sous Linux avec un scanner de films non pris en charge, après avoir enregistré ce que son pilote Windows envoyait par USB. Dans son [récit du 15 octobre](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/), il explique avoir utilisé Claude pour l’aider à analyser ces captures et à développer un moteur SANE. La première numérisation présentait encore des défauts de qualité ; il a ensuite fait état d’un pilote bien meilleur. Il s’agit des résultats d’un développeur et d’un scanner, pas d’une mesure reproduite de façon indépendante de la fréquence à laquelle l’IA peut écrire des pilotes.

Schaller a ensuite publié [hw-harness](https://github.com/cschalle/hw-harness), un ensemble de scripts et de documentation sous licence MIT qui généralise sa méthode. Il précise que les projets du scanner et de la caméra utilisaient du code sur mesure, pas le harness publié dans sa forme actuelle. Pour un développeur de pilotes Linux ayant un accès physique à un appareil USB non pris en charge, la tâche utile est plus précise que « laisser l’IA faire de la rétro-ingénierie » : capturer une opération avec le pilote fonctionnel du fabricant, capturer la même avec le pilote Linux, puis examiner la première différence significative.

## Le grand changement

- **Ce qui a changé :** Schaller a rassemblé une méthode reproductible pour enregistrer une session fonctionnelle d’un appareil Windows et une tentative avec un pilote Linux au moyen du même enregistreur USB côté hôte. Le résultat de son scanner illustre l’intérêt de cette comparaison, mais reste un cas unique rapporté par son auteur.
- **Pourquoi c’est important :** Un développeur de pilotes peut fournir des traces étiquetées à un assistant de programmation IA et lui demander une explication possible du protocole ou une petite sonde de diagnostic. Avant d’accepter du code généré, il lui faut toujours le matériel, une opération de référence fonctionnelle et des tests directs.
- **Ce qu’il faut surveiller :** La méthode dépend de la possibilité d’observer le trafic pertinent de l’appareil. Pour une caméra MIPI interne, le harness publié s’appuie plutôt sur la configuration des périphériques Windows et l’examen de l’ACPI ; une procédure de capture USB manquerait les informations nécessaires au développeur.

## Ce qu’il faut avant une capture

Le [README de hw-harness](https://github.com/cschalle/hw-harness) indique que le projet a été développé et testé sous Fedora. La configuration documentée prévoit libvirt/KVM, un système invité Windows exécutant le pilote du fabricant, un véritable transfert direct USB, une capture avec `usbmon` sur l’hôte Linux et un pilote Linux ou une sonde de diagnostic pour la comparaison. Windows 11 Pro permet d’utiliser les commandes graphiques du harness fondées sur RDP. Le [guide de la machine virtuelle](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) précise qu’un invité Home peut toujours utiliser SSH, mais pas ces commandes RDP. Le dépôt énumère les paquets Fedora et les autorisations de groupe ; exécutez `harness doctor` sur la révision extraite du dépôt pour repérer les éléments manquants avant de brancher l’appareil.

Disposez d’une installation Windows et de logiciels du fabricant dont l’utilisation vous est permise, de l’appareil exact, d’une opération répétable et d’espace pour les captures de paquets. Prévoyez le coût d’une machine virtuelle, de l’accès au matériel, de Windows et du service d’IA choisi ; le dépôt ne donne pas de coût total fixe. Ses scripts sont sous licence MIT, mais cela ne vous accorde aucune licence Windows ou de logiciel du fabricant. Vérifiez vos conditions de licence et les règles applicables à la rétro-ingénierie avant d’utiliser ou de diffuser les éléments recueillis.

Utilisez un répertoire de projet distinct pour chaque appareil. Le README indique que `harness init` crée la configuration et les répertoires ignorés `etc/` et `captures/`. Renseignez le nom de la machine virtuelle et les identifiants USB fabricant/produit à partir de votre appareil, au lieu de copier les valeurs d’exemple du README. `winctl auth`, `harness iso` et l’amorçage documenté de l’invité établissent le contrôle de la machine virtuelle Windows ; `winctl status` doit afficher `ssh: ok` avant une capture. Il s’agit de la configuration documentée du projet, pas d’une suite d’étapes exécutée par BIG CHANGE.

## Faites correspondre une opération sur les deux systèmes

1. **Enregistrez un état de référence et une référence Windows.** Suivez le [document de méthode](https://github.com/cschalle/hw-harness/blob/main/doc/method.md) du dépôt : commencez par identifier le trafic au repos. Démarrez la capture sur l’hôte avant de confier l’appareil USB à l’invité si vous avez besoin de son énumération initiale. Utilisez le pilote Windows du fabricant avec l’appareil transféré et étiquetez une action courte et précise, comme une numérisation à une résolution donnée. `usbcap` capture le bus et écrit un fichier annexe `.meta` contenant l’appareil, l’adresse sur le bus, la durée et l’étiquette. Le point de capture de l’hôte se situe sous le transfert direct USB et peut donc observer l’opération de l’invité.
2. **Enregistrez l’opération correspondante sous Linux.** Rendez l’appareil à l’hôte et capturez votre pilote Linux exécutant la même opération avec les mêmes réglages et le même matériau physique. Une capture de référence sans exécution Linux correspondante ne permet pas d’établir quelle action du pilote a divergé. La commande de scanner du dépôt est un exemple pour la configuration de l’auteur, pas une commande universelle pour tous les appareils.
3. **Comparez et testez une hypothèse.** Lisez les deux traces dans Wireshark ou avec les filtres `tshark` du document de méthode. Vérifiez les transferts d’initialisation, les écritures qui encadrent l’action, les interrogations d’état et le minutage des transferts en bloc. Changez un seul réglage à la fois, par exemple la résolution, pour voir quel transfert change. Demandez à un assistant IA de relever une différence possible et de citer la capture et la trame qui l’étayent. Apportez ensuite une modification limitée au pilote ou utilisez une sonde de diagnostic, puis répétez la même opération sur le matériel réel. Une explication plausible dans une réponse du modèle n’est pas un signe de réussite.

Le résultat immédiat est une paire de fichiers de capture étiquetés et une description de la première divergence significative. Une réparation réussie exige que l’appareil Linux effectue régulièrement l’opération voulue, avec le résultat attendu, selon les propres vérifications du développeur. Quelques octets identiques ou une image partielle ne prouvent pas la qualité complète du pilote. Dans le récit de Schaller, la première numérisation reconnaissable nécessitait encore du travail, et la prise en charge de son scanner dans le projet principal SANE est apparue séparément pendant ses travaux.

Si les traces sont difficiles à comparer, raccourcissez l’opération et vérifiez que l’appareil, les réglages et la couche de capture correspondent. La méthode recommande de petites captures répondant à une question et une capture unique du branchement de l’appareil. Si le transfert direct ou le contrôle de l’invité échoue, utilisez `harness doctor`, `hostdev status` et le [guide de configuration de la machine virtuelle](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) avant d’interpréter une trace vide comme un défaut du pilote. Conservez les captures et notes originales pour pouvoir relier une constante de registre proposée à une trame observée.

## Les limites de la capture USB

Une caméra MIPI interne n’expose pas le même trafic utile à l’enregistreur USB de l’hôte. Le document de méthode décrit plutôt l’utilisation de `winctl probe` pour les propriétés PnP de Windows, les fichiers INF, les entrées du registre et les tables ACPI, ainsi que l’examen côté Linux au moyen de `hwdbg`. Schaller rapporte avoir appliqué cette autre voie à la caméra de son ordinateur portable, avec des correctifs du noyau et de libcamera ; ces résultats proviennent eux aussi de son récit. Ne prenez pas un résultat obtenu avec une caméra pour la preuve que la boucle USB a fonctionné sur un autre appareil.

Limitez l’enquête au comportement observé de l’appareil et à sa configuration déclarative. Le [guide clean-room](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) du dépôt exclut le désassemblage des binaires du fabricant ou la copie de leur code dans un pilote Linux. Il prévient aussi que les captures peuvent contenir des numéros de série et que le répertoire du projet renferme une clé SSH privée. Examinez traces, identifiants d’appareil et fichiers de l’invité avant de les fournir à un service d’IA ou de les diffuser publiquement ; gardez les clés et les captures brutes hors du contrôle de versions. Les instructions publiées décrivent une méthode à essayer. BIG CHANGE a examiné le blog et le dépôt à la révision fixée, mais n’a pas exécuté la machine virtuelle, capturé un appareil ni validé le pilote obtenu.

### Sources et lectures complémentaires

- [Le récit de Christian Schaller du 15 octobre](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/) explique son travail sur le scanner et l’ordinateur portable, le rôle qu’il attribue à Claude et pourquoi le harness partagé est venu après les scripts sur mesure. Le résultat du scanner est rapporté par l’auteur, sans reproduction indépendante dans cet article.
- [Le dépôt hw-harness](https://github.com/cschalle/hw-harness) décrit les outils, les prérequis Fedora et Windows, l’exemple de configuration et l’avertissement de confidentialité. BIG CHANGE a examiné le commit `093afc5c576c200f29b771d01624a327d0ff1806` du 14 octobre 2026 ; le dépôt est sous licence MIT et peut changer après cette révision.
- [La méthode](https://github.com/cschalle/hw-harness/blob/main/doc/method.md) précise l’état de référence, la référence Windows, la comparaison Linux et la boucle de répétition, les précautions liées aux captures, la lecture des traces USB et la voie distincte pour les appareils sans bus visible depuis l’hôte.
- [La configuration de la machine virtuelle Windows de référence](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) couvre l’accès à l’invité, le transfert direct USB et les différences entre Windows Pro et Home pour les commandes RDP. Vérifiez les conditions de licence de votre installation.
- [Les limites clean-room](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) exposent la pratique d’observation du projet, ses limites concernant les binaires du fabricant et la nécessité de consigner l’origine des constantes. Il s’agit de conseils d’ingénierie du projet, pas d’un avis juridique.

## Sources

- [Christian Schaller : Utiliser l’intelligence artificielle pour faire de la rétro-ingénierie matérielle](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/) — Récit à la première personne de l’auteur sur un scanner et une caméra ; il précise que le harness généralisé a suivi les scripts sur mesure. Les résultats d’appareils isolés sont anecdotiques et BIG CHANGE ne les a pas reproduits de façon indépendante.
- [Dépôt hw-harness au commit 093afc5](https://github.com/cschalle/hw-harness) — README, outils, prérequis Fedora/Windows, exemple de procédure et note de confidentialité ; licence MIT vérifiée dans LICENSE. Commit fixé lors de l’audit des sources.
- [hw-harness : La méthode](https://github.com/cschalle/hw-harness/blob/main/doc/method.md) — État de référence, captures correspondantes, lecture des traces et examen distinct de la configuration lorsque le bus utile est inaccessible. Examiné au commit 093afc5.
- [hw-harness : La machine virtuelle Windows de référence](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) — Prérequis de l’invité, du transfert direct et de RDP/SSH, y compris les limites de Windows Home ; les décisions d’installation et de licence dépendent de l’utilisateur. Examiné au commit 093afc5.
- [hw-harness : Respecter l’approche clean-room](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) — Limites du projet concernant l’observation et les binaires du fabricant, conseils de provenance et prudence face aux paquets non fiables ; pratique d’ingénierie plutôt que conseil juridique. Examiné au commit 093afc5.