Escribir un driver para hardware sin documentación siempre ha sido un trabajo de paciencia: capturar el tráfico del bus, mirar volcados hexadecimales durante horas, suponer qué hace cada registro y probar las hipótesis una a una, muchas veces durante semanas. Christian Schaller, de GNOME, ha publicado Using Artificial Intelligence to reverse engineer hardware, donde cuenta cómo ha usado Claude Code para hacer justo eso, y el resultado me parece uno de los casos de uso de los agentes más concretos que he leído últimamente.
Un escáner de negativos sin soporte
Todo empieza con una caja de negativos antiguos de fotos familiares y un escáner Plustek OpticFilm 8200i, que en teoría funcionaba en Linux. El problema es que el fabricante había cambiado el chip del modelo sin cambiarle el nombre: el antiguo usa un Genesys GL845, que SANE ya soportaba, y el nuevo un GL128, que no.
El primer intento con Claude Code no llegó a ningún sitio y el proyecto se quedó parado unos meses. Lo que lo desbloqueó fue una idea de Tom Crider (GloriousEggroll), que había arreglado el driver de un ratón dándole al agente el control completo de una máquina virtual con Windows. Con ese montaje, en unas horas había un primer escaneo funcional en Linux, y en unos días un driver casi completo, con soporte para el canal infrarrojo.
El método: grabar desde fuera y comparar
La parte que más me gusta es el método, que Schaller ha empaquetado en hw-harness. La premisa es sencilla: para casi cualquier hardware sin soporte ya existe un driver que funciona, el de Windows. No hace falta leerlo ni desensamblarlo, basta con observar lo que hace.
flowchart LR
A["Driver de Windows · VM con KVM"] --> B["Dispositivo USB"]
C["Driver propio · Linux"] --> B
B --> D["usbmon en el host"]
D --> E["Comparar las dos capturas"]
E --> F["Lista de fallos del driver"]- Grabar una sesión de referencia. El driver del fabricante corre en una máquina virtual con Windows, con el dispositivo real conectado a ella.
- Capturar desde fuera. En el host Linux,
usbmonregistra todo el tráfico USB. Está por debajo de la capa que pasa el dispositivo a la máquina virtual, así que Windows ni se entera. - Repetir la misma operación en Linux con el driver propio, y capturarla igual.
- Comparar las dos capturas. Como salen de la misma herramienta, se pueden comparar directamente, y las diferencias son la lista de fallos del driver.
Para hardware sin un bus que se pueda escuchar, como una cámara MIPI integrada en el portátil, la máquina virtual sigue siendo la fuente de información, pero a través de los ficheros INF, el registro de Windows y las tablas ACPI.
El repositorio incluye varias herramientas para el agente: winctl para manejar la máquina virtual por SSH y RDP (incluidos clics y capturas de pantalla), usbcap para capturar con usbmon, hostdev para pasar el dispositivo del host a la máquina virtual y al revés, y hwdbg para depurar en Linux con permisos de root acotados. Con eso, el agente puede manejar la aplicación del fabricante, escanear en Windows, devolver el escáner a Linux y repetir la prueba sin que nadie toque nada.
Observar, no descompilar
Hay un detalle importante, que el proyecto documenta aparte: hw-harness se queda deliberadamente en el lado de la observación. Las capturas de tráfico, los descriptores, los INF, el registro o las tablas ACPI describen el hardware. Desensamblar el driver del fabricante es otra cosa, con otras consecuencias legales. Así, cada constante del driver nuevo sale de algo que se ha grabado, no de código copiado.
Es el enfoque de sala limpia de toda la vida en la ingeniería inversa, con la diferencia de que ahora la parte tediosa la hace el agente.
Tres proyectos
Con este método salieron tres proyectos:
| Proyecto | Qué hace |
|---|---|
| Backend de SANE para el OpticFilm 8200i | Color, gris e infrarrojo, de 300 a 7200 ppp, a 8 o 16 bits, con eliminación de polvo usando el canal infrarrojo |
| Negative Vibes | Aplicación de GNOME en Rust para escanear negativos y diapositivas, con ajustes no destructivos y calibración IT8 |
| Arreglos para la cámara MIPI | Parches para el kernel y libcamera en un ThinkPad X1 Carbon Gen 14 |
Lo del escáner tiene su punto de ironía: mientras el proyecto estaba parado, alguien añadió soporte para ese escáner en el backend genesys de SANE, en septiembre de 2026. Schaller los ha comparado: los dos resuelven el mismo detalle a 3600 ppp, el suyo es más rápido a resolución máxima (34,6 s frente a 54,4 s) y tiene limpieza por infrarrojos, y el oficial ofrece más resoluciones. Lo presenta como una prueba de concepto y espera usar el oficial cuando esté a la par, pero los hallazgos pueden ayudar a mejorarlo.
La cámara del portátil
El caso de la cámara me parece el más interesante, porque no hay bus USB que escuchar. La cámara del ThinkPad usa un sensor Sony IMX471 detrás de un Intel IPU7, y en Linux daba imágenes oscuras, con las esquinas muy apagadas y un tono amarillo verdoso. En un día de trabajo del agente, reutilizando el mismo montaje, salieron estos arreglos:
- En el driver del kernel: un fallo en la selección del recorte devolvía un error antes de guardar el rectángulo, el registro del patrón de prueba tenía un ancho incorrecto, y el límite de ganancia analógica era demasiado bajo, lo que costaba unos 1,8 pasos de sensibilidad.
- En el ISP por software de libcamera: faltaba la corrección de sombreado de la lente, y las esquinas quedaban unos 2,7 pasos más oscuras. Además, las estadísticas de balance de blancos se sumaban con la profundidad de bits nativa del sensor frente a un nivel de negro de 8 bits. Este último arreglo sirve para cualquier sensor RAW10 o RAW12, no sólo para este portátil.
En una prueba con poca luz, el brillo medio de la imagen pasó de 31,1 a 90,9, y los colores quedaron cerca de los de una webcam USB que sirvió de referencia. Aquí fue clave tener esa webcam conectada a la vez, para que el agente pudiera comparar las dos imágenes. Los parches del kernel ya se han enviado y los de libcamera están en revisión.
Lo que me llevo
Schaller resume lo aprendido en tres ideas, y las comparto:
- Una captura de referencia lo cambia todo. Comparar una traza que funciona con una que falla convierte un “no funciona” en una lista concreta de diferencias.
- La IA es buena con lo tedioso. Leer miles de líneas de captura USB, ver que una secuencia se repite con un byte distinto, proponer qué significa ese byte y escribir la prueba para confirmarlo. Y no se aburre.
- El hardware real es el único juez. Todo se comprobó con el escáner y el portátil de verdad, y la persona sigue siendo quien decide qué construir y quien tiene el dispositivo en la mano.
Lo que más me gusta de este caso es que no va de que el agente escriba el código mejor que una persona, sino de que le da un bucle de verificación muy claro: hay una referencia que funciona, se puede medir la diferencia y se puede comprobar el resultado en el hardware. Enlaza con lo que comentaba hace unos días sobre el cuello de botella de la revisión de código: si revisar lo que produce un agente es lo que frena, lo que más ayuda es tener formas automáticas y objetivas de comprobar que el resultado es correcto.
El propio Schaller reconoce que no tenía los conocimientos profundos que normalmente exige este tipo de trabajo, y que ni el escáner ni la cámara están perfectos. Pero el soporte de hardware ha sido siempre uno de los puntos débiles de Linux, y si el trabajo pesado de la ingeniería inversa se vuelve asequible, puede llegar a mucho más hardware que el que hoy cubren los pocos especialistas que se dedican a esto.
Fuente: Using Artificial Intelligence to reverse engineer hardware, Christian F.K. Schaller.
