Edición en Markdown

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

# Use pares de trazas USB para investigar un dispositivo sin soporte en Linux

> Una guía basada en documentación para registrar la misma operación de hardware con el controlador del fabricante en Windows y con uno de Linux, y después probar las diferencias en 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 consiguió que un escáner de película sin soporte produjera una imagen reconocible en Linux tras registrar lo que su controlador de Windows enviaba por USB. En su [relato del 15 de octubre](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/), describe el uso de Claude para analizar esas capturas y desarrollar un backend de SANE. La primera imagen aún tenía problemas de calidad; más adelante informó de un controlador mucho mejor. Son resultados de un desarrollador y un escáner, no una medición reproducida de forma independiente de cuántas veces puede la IA escribir controladores.

Después, Schaller publicó [hw-harness](https://github.com/cschalle/hw-harness), un conjunto de scripts y documentación con licencia MIT que generaliza su método. Aclara que los proyectos del escáner y la cámara usaron código a medida, no el harness publicado en su forma actual. Para un desarrollador de controladores Linux con acceso físico a un dispositivo USB sin soporte, la tarea útil es más concreta que «dejar que la IA haga ingeniería inversa»: capturar una operación con el controlador funcional del fabricante, capturar la misma operación con el controlador Linux e investigar la primera diferencia significativa.

## El gran cambio

- **Qué cambió:** Schaller ha empaquetado una forma repetible de observar una sesión funcional del dispositivo en Windows y un intento con el controlador Linux mediante el mismo registrador USB del anfitrión. Su resultado con el escáner muestra por qué puede ayudar la comparación, pero sigue siendo un único caso comunicado.
- **Por qué importa:** Un desarrollador puede dar trazas etiquetadas a un asistente de programación con IA y pedir una explicación del protocolo o una pequeña prueba exploratoria. Sigue necesitando el hardware, una operación de referencia funcional y pruebas directas antes de aceptar código generado.
- **Qué observar:** El método depende de que el tráfico relevante del dispositivo sea observable. Para una cámara MIPI interna, el harness publicado recurre a la configuración del dispositivo en Windows y a la inspección de ACPI; una receta de trazas USB omitiría la información necesaria.

## Qué necesita antes de una captura

El [README de hw-harness](https://github.com/cschalle/hw-harness) dice que se desarrolló y probó en Fedora. La configuración documentada requiere libvirt/KVM, un invitado Windows que ejecute el controlador del fabricante, paso directo USB real, captura con `usbmon` en el anfitrión Linux y un controlador o prueba exploratoria Linux para comparar. Windows 11 Pro permite los controles gráficos del harness basados en RDP. La [guía de la máquina virtual](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) dice que un invitado Home puede usar SSH, pero no esos controles RDP. El repositorio enumera paquetes de Fedora y permisos de grupo; ejecute `harness doctor` sobre la revisión descargada para encontrar componentes faltantes antes de conectar el dispositivo.

Disponga de una instalación autorizada de Windows y del software del fabricante, el dispositivo exacto, una operación repetible y espacio para capturas de paquetes. Presupueste una máquina virtual, acceso al hardware, Windows y el servicio de IA que elija; el repositorio no fija un coste total. Sus scripts tienen licencia MIT, pero eso no otorga una licencia de Windows ni del software del fabricante. Revise sus propias licencias y las normas de ingeniería inversa aplicables antes de usar o distribuir lo recopilado.

Use un directorio de proyecto distinto por dispositivo. El README dice que `harness init` crea la configuración y los directorios excluidos del control de versiones `etc/` y `captures/`. Introduzca el nombre de la máquina virtual y los ID de fabricante/producto USB del dispositivo, en lugar de copiar los ejemplos del README. `winctl auth`, `harness iso` y el arranque inicial documentado del invitado establecen el control de la máquina Windows; `winctl status` debe indicar `ssh: ok` antes de una captura. Es la configuración documentada del proyecto, no una secuencia ejecutada por BIG CHANGE.

## Reproduzca una operación en ambos sistemas

1. **Registre una línea base y una referencia en Windows.** Siga el [documento del método](https://github.com/cschalle/hw-harness/blob/main/doc/method.md) del repositorio: primero aprenda cómo es el tráfico en reposo. Inicie la captura del anfitrión antes de entregar el dispositivo USB al invitado si necesita su enumeración inicial. Ejecute el controlador Windows del fabricante sobre el dispositivo pasado directamente y etiquete una acción breve y concreta, como un escaneo a una resolución indicada. `usbcap` captura el bus y escribe un archivo auxiliar `.meta` con el dispositivo, la dirección del bus, la duración y la etiqueta. El punto de captura del anfitrión está por debajo del paso directo USB, por lo que puede observar la operación del invitado.
2. **Registre la operación equivalente en Linux.** Devuelva el dispositivo al anfitrión y capture su controlador Linux realizando la misma operación con los mismos ajustes y material físico. Una referencia sin una ejecución Linux correspondiente no permite determinar qué acción del controlador divergió. El comando de escáner del repositorio es un ejemplo para la configuración del autor, no un comando universal para todos los dispositivos.
3. **Compare y pruebe una hipótesis.** Lea las dos trazas en Wireshark o con los filtros `tshark` del documento del método. Examine las transferencias de inicialización, las escrituras anteriores y posteriores a la acción, el sondeo de estado y los tiempos de transferencia masiva. Cambie un solo ajuste cada vez, como la resolución, para ver qué transferencia cambia. Pida a un asistente de IA que identifique una posible diferencia y cite la captura y la trama que la sustentan. Después, haga un cambio limitado en el controlador o una prueba exploratoria y repita la misma operación en hardware real. Una explicación plausible del modelo no es señal de éxito.

El resultado inmediato es un par de archivos de captura etiquetados y una descripción de la primera divergencia significativa. Una reparación satisfactoria exige que el dispositivo Linux realice la operación prevista de forma constante, con el resultado esperado, según las comprobaciones del propio desarrollador. Coincidir en unos pocos bytes o producir una imagen parcial no demuestra la calidad completa del controlador. Según el relato de Schaller, la primera imagen reconocible aún necesitaba trabajo, y el soporte de su escáner en el proyecto SANE apareció por separado mientras él trabajaba.

Si cuesta comparar las trazas, acorte la operación y confirme que coinciden dispositivo, ajustes y capa de captura. El método recomienda capturas pequeñas que respondan una pregunta y capturar una vez la conexión del dispositivo. Si falla el paso directo o el control del invitado, use `harness doctor`, `hostdev status` y la [guía de configuración de la máquina virtual](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) antes de interpretar una traza vacía como fallo del controlador. Conserve las capturas originales y las notas para que una constante de registro propuesta pueda rastrearse hasta una trama observada.

## Dónde termina el trazado USB

Una cámara MIPI interna no expone el mismo tráfico útil al registrador USB del anfitrión. En ese caso, el documento del método describe `winctl probe` para propiedades PnP de Windows, archivos INF, entradas del registro y tablas ACPI, además de inspección en Linux mediante `hwdbg`. Schaller dice haber aplicado esa ruta distinta a la cámara de su portátil, con parches del kernel y de libcamera; esos resultados también proceden de su relato. No use un resultado de cámara como prueba de que el ciclo USB funcionó en otro dispositivo.

Centre la investigación en el comportamiento observado del dispositivo y la configuración declarativa. La [guía de desarrollo en sala limpia](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) del repositorio excluye desensamblar binarios del fabricante o copiar su código en un controlador Linux. También advierte que las capturas pueden contener números de serie y que el directorio del proyecto tiene una clave SSH privada. Revise trazas, identificadores del dispositivo y archivos del invitado antes de entregarlos a un servicio de IA o compartirlos públicamente; deje las claves y las capturas sin procesar fuera del control de versiones. Las instrucciones publicadas establecen un método para probar. BIG CHANGE examinó el blog y el repositorio en la revisión fijada, pero no ejecutó la máquina virtual, capturó un dispositivo ni validó un controlador resultante.

### Fuentes y lecturas adicionales

- [El relato de Christian Schaller del 15 de octubre](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/) explica su trabajo con el escáner y el portátil, el papel que atribuye a Claude y por qué el harness compartido llegó después de sus scripts a medida. El resultado del escáner es su informe, sin reproducción independiente en este artículo.
- [Repositorio hw-harness](https://github.com/cschalle/hw-harness) describe las herramientas, los requisitos de Fedora y Windows, la configuración de ejemplo y la advertencia de privacidad del proyecto. BIG CHANGE examinó el commit `093afc5c576c200f29b771d01624a327d0ff1806` del 14 de octubre de 2026; el repositorio tiene licencia MIT y puede cambiar después de esa revisión.
- [El método](https://github.com/cschalle/hw-harness/blob/main/doc/method.md) detalla la línea base, referencia, comparación Linux y ciclo de repetición, la protección de capturas, la lectura de trazas USB y la ruta alternativa para dispositivos sin un bus visible desde el anfitrión.
- [Configuración de la máquina virtual de referencia Windows](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) cubre el acceso al invitado, el paso directo USB y las diferencias entre Windows Pro y Home para controles RDP. Compruebe las licencias de su instalación.
- [Límites de sala limpia](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) expone la práctica basada en observación, los límites sobre binarios del fabricante y la necesidad de anotar el origen de las constantes. Es orientación de ingeniería del proyecto, no una opinión jurídica.

## Sources

- [Christian Schaller: Usar inteligencia artificial para hacer ingeniería inversa de hardware](https://blogs.gnome.org/uraeus/2026/10/15/aiandreverseengineerhardware/) — Relato del autor en primera persona sobre el escáner y la cámara; aclara que el harness generalizado llegó después de los scripts a medida. Los resultados en dispositivos concretos son anecdóticos y BIG CHANGE no los reprodujo independientemente.
- [Repositorio hw-harness en el commit 093afc5](https://github.com/cschalle/hw-harness) — README, herramientas, requisitos Fedora/Windows, flujo de ejemplo y nota de privacidad; licencia MIT verificada en LICENSE. Commit fijado en la auditoría de fuentes.
- [hw-harness: El método](https://github.com/cschalle/hw-harness/blob/main/doc/method.md) — Línea base, capturas equivalentes, lectura de trazas e inspección separada de configuración cuando el bus relevante no es accesible. Examinado en el commit 093afc5.
- [hw-harness: La máquina virtual de referencia Windows](https://github.com/cschalle/hw-harness/blob/main/doc/vm-setup.md) — Requisitos de invitado, paso directo y RDP/SSH, incluidos los límites de Windows Home; las decisiones de instalación y licencia dependen del usuario. Examinado en el commit 093afc5.
- [hw-harness: Mantener el desarrollo en sala limpia](https://github.com/cschalle/hw-harness/blob/main/doc/cleanroom.md) — Límites del proyecto sobre observación y binarios del fabricante, orientación de procedencia y precaución con paquetes no confiables; práctica de ingeniería, no asesoramiento jurídico. Examinado en el commit 093afc5.