hw-harness: la IA que escribe drivers de hardware

¿Qué es hw-harness y cómo logra que la IA escriba un driver?

Un desarrollador pasó meses atascado intentando que su escáner de negativos funcionara en Linux. Con un agente de IA y una máquina virtual de Windows, consiguió su primer escaneo funcional en unas horas. Ese experimento derivó en hw-harness, un conjunto de herramientas que documenta cómo usar modelos como Claude o Codex para escribir drivers de hardware que no tiene documentación pública.

El problema que ataca es viejo en el software libre. Escribir un driver para un dispositivo sin especificaciones implica capturar el tráfico del bus, leer volcados hexadecimales y formular hipótesis sobre qué hace cada registro o transferencia de control. Después hay que probarlas una por una, normalmente durante semanas.

El autor lo describe sin dramatismo: nada de esto es conceptualmente difícil, pero requiere mucha paciencia y habilidades. Ahí está la grieta que aprovecha la IA. Un modelo puede leer miles de líneas de una captura USB, notar que una secuencia se repite con un solo byte cambiando y proponer qué significa ese byte. Puede escribir la prueba para confirmarlo y no se aburre.

El harness se apoya en cuatro pasos:

• Grabar una sesión de referencia. Se ejecuta el driver oficial de Windows dentro de una máquina virtual KVM, con el dispositivo real pasado al invitado mediante passthrough.
• Capturar desde fuera de la VM. El tráfico se registra en el host Linux con usbmon, que queda por debajo de la capa de passthrough, así que el invitado no lo ve.
• Repetir la misma operación en Linux con el driver propio y capturarla de la misma forma.
• Comparar las dos trazas. Al venir del mismo instrumento, son directamente comparables. Las diferencias son la lista de bugs del driver.

Para dispositivos sin un bus que espiar —como una cámara MIPI interna— el harness cambia de estrategia e inspecciona el lado Windows: archivos INF, datos de registro, tablas ACPI y propiedades del dispositivo.

Un detalle relevante para quien tema problemas legales: el método no copia código. Observa lo que hace el hardware y extrae datos de configuración de los drivers de Windows, de modo que cada constante del driver nuevo se puede rastrear hasta algo que quedó registrado.

Los tres proyectos: de un escáner Plustek a la cámara de un ThinkPad

Proyecto 1: un backend SANE para el Plustek OpticFilm 8200i. El escáner que compró el autor usaba el controlador Genesys GL128 (USB 07b3:1825) y no tenía soporte en Linux. El modelo anterior, con el mismo nombre comercial, usa un GL845 y ya estaba cubierto por SANE. El backend nuevo soporta modos color, gris, infrarrojo y color+infrarrojo; resoluciones de 300 a 7.200 dpi a 8 o 16 bits por canal; eliminación de polvo y rayaduras desde el canal infrarrojo; y un multiplicador de exposición para negativos densos. Se empaqueta como RPM de Fedora y se compila automáticamente en cada push.

El desenlace tiene una moraleja incómoda: mientras el autor había abandonado el proyecto, alguien ya había subido código a SANE para soportar ese escáner. El backend upstream ganó soporte en septiembre de 2026. La comparación entre ambos es concreta: los dos resuelven el mismo detalle fino a 3.600 dpi, pero el suyo es más rápido a resolución completa (34,6 segundos contra 54,4) y soporta eliminación de polvo por infrarrojo, mientras que el upstream ofrece más pasos de resolución. El propio autor pide cautela: son resultados de una sola unidad y un solo fotograma.

Proyecto 2: Negative Vibes. Un driver solo no sirve de mucho si escanear negativos sigue siendo un dolor. Negative Vibes es una app de GNOME escrita en Rust para escanear negativos y diapositivas en color y blanco y negro con cualquier escáner SANE compatible con película. El escaneo se conserva tal como lo entrega el escáner —16 bits, lineal, con el plano infrarrojo— y todo lo demás es una pila de ajustes no destructivos. Incluye inversión de negativos en espacio de densidad con corrección de base de película y cruce de tintes, ajustes por rollo con anulaciones por fotograma, calibración IT8 vía ArgyllCMS y exportación a TIFF, JPEG, PNG y DNG con perfiles ICC y metadatos. Se distribuye como Flatpak que incluye el backend del escáner.

Proyecto 3: la cámara MIPI de un ThinkPad. La cámara del Lenovo ThinkPad X1 Carbon Gen 14 (Aura Edition) usa un sensor Sony IMX471 detrás de un Intel IPU7. En Linux producía imágenes oscuras, con viñeteo fuerte y un dominante amarillo-verde. Los arreglos del kernel incluyen un bug de selección de recorte que devolvía un error antes de guardar el rectángulo, un registro de patrón de prueba declarado con el ancho equivocado y un tope de ganancia analógica demasiado bajo que costaba unos 1,8 stops de sensibilidad. En el ISP por software de libcamera faltaba por completo la corrección de sombreado de lente, que dejaba las esquinas unos 2,7 stops más oscuras, y las estadísticas de balance de blancos se sumaban a la profundidad de bits nativa del sensor contra un nivel de negro de 8 bits, un arreglo que aplica a cualquier sensor RAW10 o RAW12.

En una prueba controlada con poca luz, el brillo del fotograma subió de 31,1 a 90,9 y las relaciones rojo/verde y azul/verde pasaron de 0,890 y 0,672 a 1,047 y 0,823, cerca de una webcam USB de referencia. El azul sigue unos 17% corto en condiciones de baja luz. Los parches del kernel ya se enviaron y los de libcamera están en revisión.

¿Por qué la IA funciona tan bien en ingeniería inversa de hardware?

Tres aprendizajes del autor explican el resultado.

• Las capturas de referencia son el salto grande. Comparar una traza que funciona contra una que falla convierte un vago no funciona en una lista concreta de diferencias. En el caso de la cámara MIPI, conectar además una webcam USB para que el modelo pudiera comparar ambas capturas fue determinante.
• La IA es buena en lo tedioso. Decodificar capturas, escribir sondas y verificar constantes cruzadas. El humano sigue sosteniendo el hardware físico.
• El hardware real es el único juez. Cada afirmación se verificó en el escáner o el portátil reales.

El disparador inicial no fue propio: el autor cuenta que vio una publicación en X de Tom Crider, conocido como Glorious Eggroll, sobre cómo había arreglado un driver de ratón con herramientas de IA, dándole al agente control total de una instancia de Windows para capturar los datos necesarios.

¿Qué significa esto para tu startup?

La lección no es usa IA para escribir drivers. Es que el cuello de botella de muchos equipos técnicos no es la dificultad conceptual, sino el volumen de trabajo repetitivo que nadie quiere hacer. Ese es exactamente el tipo de tarea donde un agente rinde.

Dos movimientos concretos:

• Convierte tu problema en un diff. Antes de pedirle a un agente que arregle algo, construye dos estados observables: uno que funciona y otro que no. La diferencia entre ambos es el trabajo real. Aplica esto a integraciones de API, pipelines de datos o migraciones, no solo a hardware.
• Diseña el entorno de observación, no la solución. El salto de hw-harness no fue el prompt, fue montar una VM con passthrough y capturar tráfico por debajo de la capa que el agente controlaba. Si tu agente no puede ver lo que pasa, no puede diagnosticarlo.

Y una advertencia de gestión: el autor había abandonado el proyecto durante meses y, al volver, descubrió que alguien ya había resuelto parte del problema. Antes de invertir semanas en una solución interna, revisa si el upstream ya avanzó.

Conclusión

hw-harness no promete drivers perfectos. El propio autor aclara que ni sus escaneos ni su cámara MIPI son perfectos, pero ambos mejoraron de forma medible y él no tenía el conocimiento profundo que ese trabajo suele exigir. Ese es el punto: la IA no reemplazó al ingeniero, le quitó de encima la parte que lo hacía rendirse.

No se encontraron datos adicionales verificables en las búsquedas realizadas para este artículo. Todas las cifras provienen del análisis publicado por el autor.

Fuentes

• Using AI to reverse engineer hardware (fuente original)