Ingeniería inversa
Software en Visual Basic de los años noventa que opera una cámara industrial, sin documentación: descifrado y reconstruido sin conexión.
- Rol
- Único ingeniero
- Cliente
- Dueño de una cámara industrial de secado de madera (confidencial)
- Año
- 2026
- Estado
- Verificado sin conexión, aún sin probar en la cámara
- Tecnologías
- Python, SQLite, React, Vite, Playwright, Unicorn, Capstone, pefile
El sistema
Cuatro programas de Windows de fines de los años noventa supervisan una cámara industrial de secado de madera. El dueño quería preservarlos y reemplazarlos por software mantenible, sin poner en riesgo la cámara.
En cifras
- 1.709 archivos instalados, inventariados con su hash
- 296 recetas de secado reales que lee la nueva aplicación
- 220 pruebas automatizadas, todas sin conexión
- Cero conexiones a la cámara: todo se hizo con hardware simulado
Lo que se sabía
Los cuatro programas tal como estaban instalados: una aplicación para el operador, un programa auxiliar que se comunica con el controlador de la cámara por puerto serie y dos utilidades pequeñas. Con ellos venían su configuración, 296 recetas de secado, 481 archivos de historial, seis juegos de idioma y un plano de cableado escaneado: 1.709 archivos en total. También, una recuperación parcial del código hecha con un descompilador, en la que varios módulos salieron vacíos, y notas y grabaciones de tráfico anteriores, de origen desconocido.
Lo que había que averiguar
Cómo se comunican los programas entre sí y con el controlador. Qué significa cada campo de las recetas y los historiales, y en qué unidades. Cómo se registran las alarmas. Qué parte ejecuta el programa de secado: el software o el controlador. Nada de eso estaba escrito en un lugar confiable, y parte de lo escrito estaba equivocado.
Cómo se desarmó
-
Inventariar.
Cada archivo instalado se listó con su hash antes que nada, para que nada cambiara sin notarse.
-
Leer, nunca tocar.
Los archivos y el código recuperado se leyeron sin conexión. La cámara en funcionamiento nunca se contactó, ni siquiera para leer un valor.
-
Ejecutar el original.
Sus propias rutinas corrieron en un emulador x86 y en una copia privada de su entorno de Visual Basic, con entradas controladas y casos límite: redondeos, valores negativos, nombres con tildes.
-
Coincidir o marcar.
Un comportamiento contaba como verificado solo si el código nuevo coincidía con la salida del original. Todo lo demás queda marcado como inferido o desconocido.
La nueva aplicación sin conexión tras una pérdida de comunicación simulada. Captura hecha con el simulador, sin maquinaria conectada.
- Las últimas lecturas siguen en pantalla.
- El estado del proceso figura como desconocido en vez de repetir el último valor conocido.
- La muestra aparece desactualizada.
- Arranque y parada quedan deshabilitados hasta restaurar el enlace.
Qué hizo posible
El software de la cámara quedó documentado, y un reemplazo sin conexión ya lee sus datos reales.
La documentación cubre cómo se comunican sus programas, qué contienen sus archivos y cómo registra las alarmas. La nueva aplicación lee las 296 recetas reales y el historial original, simula el arranque, la parada y la pérdida de conexión, y registra cada acción para poder reproducir una sesión exactamente.
El código nuevo se verificó contra las rutinas del propio programa original. Con las recetas reales probadas, los datos que prepara para el controlador coincidieron byte a byte con los del original, y los 120 campos del historial de alarmas se decodifican igual. Hay 220 pruebas automatizadas que corren sin conexión.
Todavía no se ha conectado a la cámara, y no se conectará hasta que se autorice una prueba supervisada.
IA en este proyecto
Sí. Agentes de programación con IA trabajaron en el análisis y en el código, con dos reglas que fijé yo: cada hallazgo debía quedar marcado como verificado, inferido o desconocido, y nada podía conectarse a la cámara.