Un monitor ASUS ROG Swift PG42UQ de casi dos mil dólares acepta cualquier archivo de firmware que le mandes por USB: sin firma, sin validación criptográfica, solo un checksum simple. Eso fue lo que encontró un desarrollador identificado como schlarp cuando sometió a ingeniería inversa con IA los periféricos de su escritorio usando Claude Opus 5.
En dos semanas de sesiones nocturnas, el experimento se extendió a cinco dispositivos: una webcam, un monitor, un micrófono, una luz de videollamadas y un quinto periférico. El resultado quedó documentado íntegramente en su blog, con el código y los hallazgos publicados en repositorios de GitHub validados contra hardware real.
TL;DR
- Un developer usó Claude Opus 5 para auditar 5 periféricos en 2 semanas de sesiones nocturnas: 13 horas de trabajo del agente y 98 prompts en total.- La webcam Insta360 Link expone un canal USB oculto con lectura y escritura arbitraria de archivos, sin intervención del usuario.- Claude parchó la tabla de LED de la Insta360 Link y apagó el indicador de grabación tras recalcular el hash MD5 de integridad del firmware.- El monitor ASUS ROG Swift PG42UQ actualiza su firmware por I2C sobre USB con solo un checksum simple, sin firma criptográfica.- La Insta360 Link corre un RTOS ThreadX completo de Ambarella, con modelos de visión embebidos para seguimiento facial y gestos.- El caso de la webcam recuerda al exploit iSeeYou de 2013, que apagaba el LED de cámaras iSight de MacBook sin encender ninguna luz.- Los cinco repositorios generados quedaron públicos en GitHub, con documentación y herramientas de flasheo validadas contra hardware real.- La luz de videollamadas del experimento expone escritura arbitraria de memoria accesible desde la red WiFi local.
Qué pasó
El experimento arrancó por una molestia doméstica: a schlarp le aparecía cada tanto un aviso de "pixel cleaning" en su monitor ASUS ROG Swift PG42UQ que nunca pidió ejecutar. En vez de buscar un firmware modificado en algún foro, le dio a Claude Opus 5 acceso al firmware oficial, a la herramienta de actualización del fabricante y al dispositivo físico conectado por USB, con instrucciones explícitas de no alterar nada todavía: solo documentar, analizar y validar.
El resultado fue un patrón que se repitió en los cinco dispositivos: firmware descargado del fabricante, herramienta de actualización oficial descompilada, protocolo de actualización reconstruido a mano por el agente y, en varios casos, un canal de comandos oculto que el fabricante nunca documentó públicamente.
Según el propio conteo de schlarp, sacado directamente de las transcripciones de las sesiones de Claude Code, el trabajo total sumó 13 horas de "churn" (el tiempo en que el agente estuvo activo, sin contar los períodos de inactividad) y 98 prompts del autor, repartidos en dos semanas de sesiones nocturnas para cinco dispositivos: una webcam, un monitor, un micrófono, una luz de videollamadas y un quinto periférico que completa la lista.
Contexto e historia
La ingeniería inversa de firmware de consumo no es nueva: existe una tradición larga de hobbyistas destripando routers, impresoras y cámaras para desbloquear funciones o auditar su seguridad. Lo que cambia con agentes como Claude Opus 5 es la velocidad con la que se puede pasar de "tengo un binario" a "tengo un protocolo documentado y una prueba de concepto funcionando contra el hardware real".
schlarp usó una metodología repetible para los cinco dispositivos: le entregó al agente el firmware, la herramienta de actualización oficial y acceso de solo lectura al dispositivo conectado, y le pidió que reconstruyera el formato de actualización, implementara una herramienta propia de flasheo, evaluara las propiedades de seguridad (checksums, firmas, secure boot) y buscara funcionalidad oculta o de depuración.
El caso de la webcam recuerda directamente al exploit iSeeYou, documentado en 2013 por investigadores de Johns Hopkins, que demostró que era posible grabar video en cámaras iSight de MacBook sin encender el LED indicador reprogramando el microcontrolador de la cámara. Más de una década después, el mismo problema de fondo (un LED controlado por software, sin ninguna garantía a nivel de hardware) sigue vivo en dispositivos nuevos.
El LED verde de grabación se puede desactivar por software, sin tocar el hardware.
Detalles técnicos y rendimiento
La Insta360 Link resultó ser mucho más que una webcam: corre un sistema operativo en tiempo real completo, ThreadX, sobre un system-on-chip de Ambarella, con varios modelos de visión embebidos que hacen seguimiento facial y detección de gestos para controlar ajustes de la cámara. Toda esa complejidad abre superficie de ataque.
Sobre la interfaz USB Video Class (UVC) estándar, la cámara expone un comando de Extension Unit (XU) que la pone en modo "almacenamiento masivo", lo que permite copiar una actualización de firmware preparada al sistema de archivos FAT interno del dispositivo, que se aplica solo al reiniciar. Pero además existe un segundo canal, sobre la clase vendor de USB, que expone lectura y escritura arbitraria de archivos y un comando de reinicio remoto, sin necesidad de que el usuario desconecte y reconecte el cable. Con eso, es posible reflashear el dispositivo completo sin ninguna interacción humana.
La única protección de integridad que encontró el agente fue un hash MD5 anexado al final del binario de firmware, sin ningún esquema de firma criptográfica ni secure boot. El firmware también contiene una tabla bien estructurada de "patrones" de LED (color, parpadeo) indexada según el estado del dispositivo. Claude escribió una herramienta que localiza la entrada correspondiente a "grabando", la reemplaza, recalcula el hash MD5 y flashea el resultado. La prueba mostró que el LED verde que normalmente se enciende al grabar dejó de activarse. El gimbal de la cámara sí se inclina hacia abajo cuando no está grabando, así que el disimulo no es total, pero el indicador luminoso principal queda completamente bajo control de quien tenga acceso USB.
El ASUS ROG Swift PG42UQ resultó todavía menos protegido: actualiza su firmware por I2C, un bus interno que en este monitor está expuesto a través de USB. El esquema es de dos slots (A/B) con un checksum simple, sin firma criptográfica de ningún tipo. En la práctica, cualquiera con acceso al bus puede escribir el firmware que quiera. El aviso de "pixel cleaning" que originó todo el experimento resultó no tener ninguna opción nativa para desactivarse (siempre reaparece a las 8 horas de uso), pero el agente sí encontró la zona exacta del binario donde parchar esa lógica.
DispositivoHallazgo principalHoras del agentePrompts del autorWebcam Insta360 LinkCanal USB vendor-class con lectura/escritura arbitraria y control del LED de grabación3.733Monitor ASUS ROG Swift PG42UQFirmware sin firma criptográfica, solo checksum simple sobre I2C/USB1.213Micrófono (sin identificar en el resumen)Shell de comandos en texto plano expuestoNo desglosadoNo desglosadoLuz de videollamadas (sin identificar en el resumen)Escritura arbitraria de memoria accesible desde la red WiFiNo desglosadoNo desglosado*Total (5 dispositivos)-13**98*
Las cifras completas de churn y prompts están sacadas directamente de las transcripciones de sesión que schlarp publicó junto al análisis; el reporte original detalla más a fondo el micrófono y la luz, aunque sin desglosar el tiempo exacto de cada uno.
⚠️ Ojo: reflashear firmware de un dispositivo real conlleva riesgo real de dejarlo inutilizable ("brickearlo"). El propio schlarp reconoce que todavía no se animó a escribir el firmware modificado en su monitor real por el costo del equipo.
flowchart TD
A["Firmware oficial y herramienta de actualizacion"] --> B["Agente Claude Opus 5"]
B --> C["Analisis estatico del binario"]
B --> D["Analisis dinamico contra el dispositivo real"]
C --> E["Documentacion y scripts generados"]
D --> E
E --> F["Validacion en hardware real"]
Cómo empezar tu propia ingeniería inversa con IA
No hace falta un laboratorio de hardware para arrancar. El primer paso es simplemente ver qué expone tu sistema operativo sobre cada dispositivo USB conectado.
# Linux: listar dispositivos USB con detalle de interfaces y endpoints
lsusb -v -d :
| less
# macOS: inventario completo de USB
system_profiler SPUSBDataType
# Windows (PowerShell): dispositivos USB conectados
Get-PnpDevice -Class USB | Format-Table -AutoSize
Ese primer comando ya te dice cuántas interfaces expone el dispositivo (en la Insta360 Link, por ejemplo, aparecería la interfaz UVC estándar más la interfaz vendor-specific que esconde el canal de lectura/escritura arbitraria) y con qué clase USB está registrada cada una.
El paso siguiente es conseguir el firmware y la herramienta de actualización oficial del fabricante, y pedirle a un agente como Claude Code que las analice antes de tocar nada. Un flujo mínimo, una vez que tenés el binario descargado, se ve así:
import hashlib
def recalcular_integridad(firmware: bytes) -> bytes:
# Reproduce el esquema tipo append-MD5 que encontro
# Claude en la Insta360 Link: el hash va pegado al
# final del binario, sin firma criptografica.
cuerpo = firmware[:-16]
checksum = hashlib.md5(cuerpo).digest()
return cuerpo + checksum
with open("firmware_original.bin", "rb") as f:
original = f.read()
# offset ilustrativo: el real depende del layout de cada binario
parcheado = bytearray(original)
parcheado[0x4A210:0x4A214] = b"\x00\x00\x00\x00"
firmware_final = recalcular_integridad(bytes(parcheado))
with open("firmware_parcheado.bin", "wb") as f:
f.write(firmware_final)
Este ejemplo es ilustrativo, no el offset real que usó schlarp (no publicó el binario completo), pero refleja el patrón general: localizar el dato a modificar, parchear los bytes y volver a calcular cualquier checksum de integridad antes de reflashear.
Documentar antes de modificar: el flujo que siguió el agente en los cinco dispositivos.
Para verificar que tu propio análisis va por buen camino, confirmá cada hallazgo contra el dispositivo real antes de asumir que es correcto: capturá el tráfico USB con Wireshark más el plugin usbmon en Linux (o USBPcap en Windows) mientras la herramienta oficial hace una actualización legítima, y compará esos paquetes contra lo que produce tu propia implementación.
Impacto y análisis
El patrón que documentó schlarp no es exclusivo de estos cinco dispositivos: los periféricos de consumo son, cada vez más, computadoras completas (con su propio sistema operativo, su propio stack de red o USB, y su propio mecanismo de actualización) que se venden como si fueran accesorios pasivos. Esa brecha entre la complejidad real del dispositivo y la protección que recibe su firmware es, según lo que muestra este caso, bastante común: ni la webcam ni el monitor tenían firma criptográfica en su esquema de actualización.
La ventaja de usar la ingeniería inversa con IA para este tipo de trabajo no es que Claude Opus 5 encuentre vulnerabilidades que un ingeniero humano no podría hallar (todo lo que hizo, en principio, lo puede hacer una persona con experiencia en ingeniería inversa), sino la velocidad: 13 horas de trabajo efectivo y 98 prompts para cubrir cinco dispositivos distintos es un ritmo que antes hubiera tomado semanas de trabajo manual por dispositivo.
💭 Clave: el agente no solo encontró los bugs, también generó su propia herramienta de flasheo y documentación para cada dispositivo, publicada en GitHub y validada contra el hardware real, no solo teorizada sobre el papel.
El caso de la luz de videollamadas (con escritura arbitraria de memoria accesible desde la red WiFi local) es probablemente el más serio de los cinco, porque no requiere acceso físico ni un cable USB: cualquier dispositivo en la misma red podría, en teoría, aprovechar ese canal. schlarp no detalla en el resumen si notificó al fabricante antes de publicar, un paso que sí sería esperable en una divulgación responsable de vulnerabilidades.
Probalo vos: corré lsusb -v (o su equivalente en macOS/Windows) sobre el próximo periférico que conectes y fijate cuántas interfaces vendor-specific expone antes de asumir que es una caja negra segura.
📖 Resumen en Telegram: Ver resumen
Qué sigue
schlarp planea seguir el mismo proceso con otros dispositivos de su escritorio y ya adelantó que, en algún momento, se anima a probar el firmware parcheado en el monitor real, hoy limitado por el riesgo de perder un equipo caro. El patrón de "dame el firmware, la herramienta de actualización y acceso al dispositivo, y documentá todo antes de tocar nada" queda como una plantilla reutilizable para cualquier developer con curiosidad por lo que corre dentro de sus propios periféricos.
Para el resto de la industria, el caso deja una pregunta abierta: si auditar cinco dispositivos de consumo con ingeniería inversa con IA tomó apenas 13 horas y encontró falta de firma criptográfica en al menos dos de ellos, cuántos periféricos que hoy están sobre miles de escritorios tienen el mismo problema sin que nadie lo haya mirado todavía.
Preguntas frecuentes
¿Qué significa "ingeniería inversa agéntica"?
Es el proceso de darle a un agente de IA (en este caso Claude Opus 5) el firmware, la herramienta de actualización y acceso al dispositivo real, y dejar que itere de forma autónoma analizando el binario, probando comandos y documentando lo que encuentra, con supervisión humana en los pasos que modifican el dispositivo.
¿Es legal hacer esto con dispositivos propios?
Auditar y modificar el firmware de un dispositivo que te pertenece, sin distribuir el firmware protegido por derechos de autor del fabricante ni violar los términos de garantía explícitos, es una práctica común dentro de la comunidad de hardware hacking. La legalidad exacta varía según el país y el dispositivo.
¿Corro riesgo de inutilizar el dispositivo?
Sí. Reflashear firmware sin el esquema de protección original activado puede dejar el dispositivo sin funcionar ("brickeado"). Por eso schlarp documentó el proceso completo antes de flashear cualquier cosa, y todavía no se animó a modificar el firmware real de su monitor.
¿Por qué una webcam necesita un sistema operativo completo?
Porque hace mucho más que capturar video: la Insta360 Link corre modelos de visión embebidos para seguimiento facial y detección de gestos en tiempo real, funciones que requieren un stack de cómputo mucho más parecido a un teléfono que a una cámara analógica.
¿Se puede aplicar este método a cualquier periférico?
En principio sí, siempre que el dispositivo tenga un mecanismo de actualización de firmware accesible y el fabricante publique (aunque sea de forma indirecta) el binario y la herramienta oficial de actualización.
¿Dónde está el código y la documentación generados?
schlarp publicó un repositorio de GitHub por cada dispositivo, con la documentación generada y las herramientas propias de actualización, validadas contra el hardware real según su propio relato.
Referencias
- Everything I own, owned (schlarp.com): el análisis original con los cinco dispositivos, las transcripciones de sesión y los enlaces a los repositorios de GitHub.- USB Video Class (Wikipedia): especificación de las extension units que expone la interfaz UVC usada por la Insta360 Link.- Claude (Anthropic): información oficial sobre la familia de modelos Claude, incluido Opus 5.- Ingeniería inversa (Wikipedia): contexto general sobre el proceso de análisis de software y hardware sin acceso al diseño original.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
