Este no es un artículo patrocinado. Es la bitácora de un proyecto real de ingeniería.
Todo empezó con un render. No es broma. Queríamos que nuestro Centro de Operaciones (NOC) tuviera dos pequeños ticker displays mostrando eventos reales de operación —esos letreros de LED que pasan texto de lado a lado—. Un detalle estético, casi un capricho. Nadie esperaba que el camino para lograrlo pasara por reconstruir un algoritmo de cifrado.
No había API
El problema apareció rápido. Los displays eran hardware OEM de origen chino, sin documentación, sin API, sin SDK. Lo único que traían era una aplicación de Windows para configurarlos, que se comunicaba con ellos por WiFi. En otras palabras: para mostrar "nuestros" datos en "nuestros" equipos, teníamos que hablar un idioma que nadie nos quiso enseñar.
Podíamos rendirnos y usar los displays solo con su app de fábrica… o entender cómo funcionaban por dentro. Elegimos lo segundo.
Instrumentar antes de adivinar
La regla de oro de la ingeniería inversa no es "adivinar", es instrumentar: hacer visible lo invisible y trabajar sobre evidencia. El plan de ataque:
- Observar el tráfico: con Wireshark capturamos la conversación WiFi entre la app y el display —TCP en crudo— para ver la forma de los mensajes.
- Abrir la caja negra: la app de Windows guardaba la lógica. Con Frida (instrumentación dinámica) y la información de tipos en tiempo de ejecución (RTTI) de su interfaz Qt, pudimos observar qué hacía por dentro mientras corría.
- Reproducir en Python: la meta no era describir el protocolo, sino hablarlo. Cada hipótesis se convertía en un cliente Python que probábamos contra el hardware real.
Hasta aquí, ingeniería inversa clásica. Lo que cambió fue la velocidad.
Dónde entró la IA (y dónde no)
La mayor parte de esta investigación la condujo Claude Opus 4.8: correlacionar capturas, proponer la estructura de los paquetes, escribir y depurar el cliente Python, documentar sobre la marcha. Semanas de trabajo tedioso comprimidas en horas.
Pero hubo una pared: los mensajes iban cifrados, y sin romper eso no había cliente posible. Para esa fase —la más compleja— nos apoyamos en Fable 5, de la línea Mythos de Anthropic, especialmente fuerte en análisis de binarios. Y aquí vale ser específico, porque la diferencia entre marketing e ingeniería es la especificidad:
La IA localizó una única referencia al encabezado AA55AA55 dentro de la sección .text del binario, identificó la clase concreta encargada del cifrado, reconstruyó el algoritmo de autenticación (un RC5-32/12) y extrajo el key schedule incrustado. Con eso pudimos implementar un cliente completamente compatible con el dispositivo. Eso es medible. Eso es ingeniería, no una demo.
El hallazgo incómodo: una llave donde no debería estar
Reconstruir ese cifrado dejó al descubierto algo más interesante que el propio SDK: la "seguridad" del dispositivo se apoyaba en una llave incrustada en el firmware, la misma para los equipos de ese modelo. Eso no es seguridad; es una cerradura cuya llave viene pegada debajo del tapete —y compartida entre todas las casas—. Es la misma clase de descuido que señalamos en cámaras IP: el dispositivo que casi nadie parcha: hardware conectado con autenticación de fachada.
Por eso una aclaración importante: en este artículo contamos el método y el hallazgo, pero no publicamos las llaves ni un cliente listo para usarse contra cualquier equipo de ese fabricante, ni lo nombramos. Explicar cómo se investiga es una cosa; entregar un exploit que exponga a otros dueños del mismo hardware sería otra muy distinta. Trabajamos sobre equipos propios, con fines de interoperabilidad, y contactamos al fabricante.
Lo que NO diríamos
Sería fácil —y falso— titular esto como "la IA reemplazó al ingeniero". No lo hizo. Durante todo el proyecto quedó claro quién dirigía: nosotros definimos el objetivo, decidimos cuándo cambiar de estrategia, escribimos al fabricante, validamos cada avance en el hardware real y guiamos la investigación. La IA aceleró brutalmente la ejecución; no aportó el criterio. Esa distinción no es modestia: es la descripción exacta de cómo funcionó.
El resultado
En menos de un día de trabajo efectivo teníamos:
- Un SDK propio para los displays.
- La especificación del protocolo, documentada.
- Un cliente en Python, reutilizable.
- Documentación del conocimiento, para que no viva solo en la cabeza de quien lo descubrió.
- La integración con el NOC: los displays, por fin, mostrando eventos reales de operación.
El render del principio, hecho realidad —por el camino largo—.
La verdadera enseñanza
La mayor lección de este proyecto no fue descubrir el RC5 ni construir el SDK. Fue comprobar que hoy una empresa pequeña puede abordar problemas que hace pocos años exigían un equipo completo de ingeniería inversa. El umbral de entrada para hacer I+D serio bajó muchísimo.
Y por eso este artículo no se llama "Fable 5" ni "Opus 4.8" ni "Mythos". Dentro de un año habrá un modelo más potente y esos nombres sonarán viejos. Lo que seguirá siendo valioso es el método: definir un objetivo claro, instrumentar el problema, validar hipótesis contra la realidad, documentar el conocimiento y convertir el resultado en algo reutilizable. Ese proceso es mucho más duradero que la herramienta que lo hizo posible —y es, en el fondo, la misma tesis que venimos sosteniendo sobre la IA como herramienta con criterio humano, no como sustituto del ingeniero.
La IA no nos hizo más listos. Nos quitó de encima el trabajo que antes hacía inviable siquiera intentarlo.