Un desarrollador conocido como schlarp documentó cómo usó trece horas de trabajo efectivo de Claude Opus 5 y noventa y ocho prompts propios para hacer ingeniería inversa asistida por IA en cinco periféricos de su escritorio, durante dos semanas de noches libres. El resultado: un webcam cuya luz de grabación se apaga sin detener la cámara, un monitor que acepta firmware sin firma alguna, un micrófono con una consola de comandos en texto plano y una luz de estudio que acepta escrituras de memoria de cualquiera en la misma red WiFi.
El experimento no es un ataque a terceros: es una auditoría de sus propios dispositivos, algo que hasta hace poco exigía semanas de trabajo manual con un desensamblador.
TL;DR
- Claude Opus 5 hizo ingeniería inversa de 5 periféricos en 13 horas de trabajo y 98 prompts del autor.- El webcam Insta360 Link tomó 3.7 horas y 33 prompts; su firmware solo valida un hash MD5, sin firma.- El agente desactivó el LED de grabación del webcam sin detener la cámara, editando la tabla de patrones del firmware.- El monitor ASUS ROG Swift PG42UQ tomó 1.2 horas y 13 prompts; actualiza firmware por I2C con checksum simple.- Según el autor, un micrófono expuso una shell de comandos en texto plano accesible desde el host.- Una luz de estudio ('key light') acepta escrituras de memoria de cualquier equipo en la misma red WiFi.- Todo el código generado quedó publicado en repositorios de GitHub, validado contra hardware real.
Qué pasó: ingeniería inversa asistida por IA en cinco periféricos
Durante dos semanas de noches libres, el autor tomó cinco dispositivos que ya tenía en su casa (un webcam, un monitor, un micrófono, una luz de estudio y un quinto periférico) y le dio a Claude Opus 5 el firmware oficial, la utilidad de actualización del fabricante y acceso de solo lectura al dispositivo conectado por USB. La instrucción era siempre parecida: documentar el formato de actualización, reimplementar la herramienta de flasheo, evaluar la seguridad del protocolo (checksums, firmas, secure boot) y encontrar funcionalidad oculta o de depuración.
El resultado más citado es el del webcam Insta360 Link: bajo la carcasa corre un sistema operativo de tiempo real completo (ThreadX, de Ambarella), con modelos de visión embebidos para seguimiento facial y gestos. Ese mismo canal de control permitió apagar el LED de actividad sin detener la grabación, algo parecido a lo que en 2013 exigió meses de trabajo manual en el exploit iSeeYou contra la webcam del MacBook.
El método: un objetivo claro y dejar iterar al agente
La clave del proceso no fue un prompt sofisticado, sino uno explícito y verificable. El autor le entregó a Claude Opus 5 un directorio con el firmware y la utilidad de actualización, y una lista de objetivos concretos:
In this directory is the firmware and update utility for ___. The device is also
attached to this computer, and you may interact with it in non-mutating ways.
Exhaustively document and cross-validate the entire firmware, including the
following goals:
* reverse engineer the firmware update format and update protocol
* implement our own update utility
* determine the security properties of the update protocol, including
checksums, signature validation, secure boot
* use static and dynamic analysis to determine all protocol surfaces and
completely enumerate functionality
* find any hidden or debug functionality in the product and how to access it
Con ese marco, el agente combinó análisis estático del binario de firmware con análisis dinámico contra el hardware real conectado por USB, en modo no destructivo. Los periféricos resultaron ser candidatos ideales para este tipo de trabajo: son computadoras pequeñas con una conexión de datos al host y, casi siempre, un mecanismo propio de actualización de firmware, así que el agente siempre tiene contra qué iterar.
Detalles técnicos: webcam, monitor y sus protecciones reales
En el Insta360 Link, la interfaz USB Video Class expone un comando de "extension unit" (XU) que pone al dispositivo en modo de almacenamiento masivo. Desde ahí se puede transferir una actualización de firmware preparada al sistema de archivos FAT interno, que el dispositivo aplica solo al reiniciar. Pero hay un segundo canal, sobre la clase vendor de USB, que expone lectura y escritura arbitraria de archivos más un comando de reinicio: con eso alcanza para reflashear el dispositivo completo sin ninguna intervención del usuario. La única protección de integridad es un hash MD5 anexado al final del archivo, sin firma criptográfica.
Ese mismo firmware guarda una tabla de "patrones" del LED que define color y parpadeo según el estado del dispositivo. El agente escribió una herramienta que borra la entrada correspondiente a "grabando", recalcula el hash MD5 y flashea el resultado. Tras la prueba, el LED verde de grabación dejó de encenderse, aunque el gimbal del Insta360 sigue bajando cuando no graba, así que el disimulo no es total.
El firmware del webcam solo valida un hash MD5, sin firma criptográfica.
El monitor ASUS ROG Swift PG42UQ resultó todavía más abierto: actualiza su firmware por I2C sobre USB con un esquema de dos slots (A/B) y un checksum simple, sin ninguna otra protección. El objetivo original del autor era desactivar el aviso emergente de "pixel cleaning" que el monitor muestra cada ocho horas de uso sin que exista forma nativa de apagarlo. Claude encontró el área exacta del firmware a parchear para eliminar esa función, aunque el autor todavía no se anima a flashear el monitor real por su costo.
La siguiente tabla resume el esfuerzo y el hallazgo principal de los dos dispositivos con datos públicos:
DispositivoVector de ataqueProtección de firmwareHallazgo principalInsta360 Link (webcam)Comando XU (USB Video Class) + acceso de archivos por clase vendor USBHash MD5 anexado, sin firmaLED de grabación desactivable sin detener la cámaraASUS ROG Swift PG42UQ (monitor)I2C sobre USB, esquema A/BChecksum simple, sin firmaAviso de "pixel cleaning" parcheable; firmware reescribible por completo
Cómo probarlo: reverse engineering agéntico paso a paso
El flujo que siguió el autor es reproducible con cualquier periférico que tengas a mano, siempre que respetes el límite de "no mutar" el dispositivo hasta confirmar qué hace cada comando. Los pasos generales:
- Descargar el firmware oficial y la utilidad de actualización del fabricante (normalmente un instalador de Windows o macOS que se puede desempaquetar).- Conectar el dispositivo real para permitir análisis dinámico, sin ejecutar todavía ninguna operación que escriba en el firmware.- Dar al agente un objetivo explícito y verificable, como el prompt citado arriba, en un entorno de reverse engineering (desensamblador, Wireshark/USBPcap, un intérprete de Python).- Dejar que el agente itere: análisis estático del binario, análisis dinámico contra el hardware, y cruce entre ambos para validar hipótesis.- Documentar en un repositorio el protocolo encontrado y, si aplica, escribir una utilidad de actualización propia.
Un ejemplo simplificado de cómo se ve un control transfer de USB para hablar con la extension unit de una webcam UVC, en Python con pyusb:
import usb.core
VENDOR_ID = 0x2E1A # Insta360 (ejemplo ilustrativo)
PRODUCT_ID = 0x0004 # Link
XU_UNIT_ID = 0x03
XU_SELECTOR_MODE = 0x01
dev = usb.core.find(idVendor=VENDOR_ID, idProduct=PRODUCT_ID)
if dev is None:
raise SystemExit("dispositivo no encontrado")
# bmRequestType, bRequest, wValue, wIndex, data
dev.ctrl_transfer(
0x21, 0x01,
(XU_SELECTOR_MODE Cada dispositivo tomó entre 1.2 y 3.7 horas de trabajo del agente.
> **💡 Tip:** Empezá siempre en modo de solo lectura. Documentar el protocolo antes de escribir nada evita convertir tu periférico en un ladrillo por un comando mal interpretado.
## Impacto y análisis: qué implica para la seguridad de tus periféricos
El patrón que se repite en los cinco dispositivos es el mismo: **protección de integridad, no de autenticidad**. Un hash MD5 o un checksum simple confirman que el firmware no se corrompió en tránsito, pero no confirman que lo haya generado el fabricante. Cualquiera con el formato documentado puede construir una imagen válida.
Este diagrama resume el flujo que usó el autor en cada dispositivo:
flowchart TD
A["Firmware oficial y utilidad de actualización"] --> B["Claude Opus 5 (agente)"]
C["Dispositivo conectado por USB"] --> B
B --> D["Análisis estático y dinámico"]
D --> E["Protocolo de actualización documentado"]
D --> F["Vulnerabilidades y funciones ocultas"]
E --> G["Utilidad de actualización propia"]
F --> G
La parte más delicada, según el propio resumen del autor, es la de la luz de estudio: acepta escrituras de memoria de cualquier equipo en la misma red WiFi, sin autenticación. A diferencia del webcam o el monitor, que requieren acceso físico por USB, ese periférico expone su superficie de ataque a toda la red local.
> **⚠️ Ojo:** Si un periférico de red doméstica acepta comandos de memoria sin autenticación, cualquier dispositivo comprometido en tu WiFi (una smart TV, un enchufe inteligente) es un punto de entrada potencial.
Esto no significa que estos fabricantes sean particularmente descuidados: es el estándar habitual en periféricos de consumo, donde el costo de implementar boot seguro y firma criptográfica rara vez se justifica frente al precio del producto. Lo que cambió no es la superficie de ataque, sino el costo de encontrarla: documentar un protocolo de actualización a mano puede tomar semanas; con un agente iterando contra el hardware real, el autor lo hizo en horas.
## Qué sigue
El autor planea publicar hallazgos adicionales a medida que analice más dispositivos, y ya adelantó que probará flashear el firmware modificado del monitor cuando se sienta más seguro del proceso. Cada repositorio queda como documentación pública y como base para que otros usuarios repliquen o corrijan el trabajo contra su propio hardware.
Para la industria, el caso es una señal más de que la ingeniería inversa asistida por IA baja la barrera de entrada de forma drástica: lo que antes requería experiencia especializada en firmware embebido ahora es accesible para cualquier desarrollador con curiosidad y un fin de semana libre.
📖 Resumen en Telegram: [Ver resumen](#)
Probalo vos: si tenés un periférico USB con actualización de firmware, empezá por desempaquetar el instalador oficial del fabricante y pedile a un agente que documente el formato antes de escribir nada.
## Preguntas frecuentes
### ¿Es legal hacer reverse engineering de un dispositivo propio?
Sí, en la mayoría de las jurisdicciones auditar un dispositivo de tu propiedad para fines de investigación personal es legal. El riesgo legal aparece si se distribuye firmware protegido por copyright o se elude un mecanismo de protección con fines comerciales.
### ¿Qué modelo de IA usó el autor del experimento?
Claude Opus 5, de Anthropic, ejecutado dentro de un entorno de reverse engineering con acceso al firmware, la utilidad de actualización del fabricante y el dispositivo conectado por USB en modo no destructivo.
### ¿Por qué un hash MD5 no protege el firmware?
MD5 detecta corrupción accidental, no verifica quién generó el archivo. Sin una firma criptográfica validada contra una clave pública del fabricante, cualquiera que conozca el formato puede construir una imagen que pase la verificación.
### ¿Qué es una extension unit (XU) en USB Video Class?
Es un mecanismo estándar de la especificación UVC que permite a un fabricante exponer comandos propietarios adicionales, fuera de los controles estándar de video, típicamente para funciones de configuración o depuración.
### ¿Puedo apagar el LED de una webcam de forma permanente sin herramientas de IA?
Es posible en teoría con ingeniería inversa manual del firmware, pero documentar el protocolo de actualización y encontrar la tabla de patrones del LED a mano suele tomar semanas, no horas.
### ¿Estos hallazgos aplican a todos los modelos del mismo fabricante?
No necesariamente. El análisis se hizo sobre unidades específicas (Insta360 Link, ASUS ROG Swift PG42UQ) y el protocolo puede variar entre generaciones o modelos del mismo fabricante.
## Referencias
- [Everything I own, owned](https://schlarp.com/posts/everything-i-own-owned/): el artículo original de schlarp con el detalle técnico completo y los repositorios de GitHub de cada dispositivo.- [USENIX Security](https://www.usenix.org): sede académica donde se publicó el exploit iSeeYou original contra el LED de la webcam del MacBook.- [Display Data Channel (DDC/CI)](https://en.wikipedia.org/wiki/Display_Data_Channel) en Wikipedia: explica el canal de control que exponen los monitores sobre el cable de video.- [Ambarella](https://www.ambarella.com): fabricante del system-on-chip y la plataforma ThreadX que corre dentro del webcam Insta360 Link.
📱 **¿Te gusta este contenido?** Únete a nuestro canal de Telegram [@programacion](https://t.me/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.
Top comments (0)