Thana prueba: REA, Reverse Engineer Anything

Hay algo que siempre me llamó la atención de la industria del software: cómo algunas empresas consiguen convertir funcionalidades relativamente sencillas en productos cerrados, propietarios y, en ocasiones, absurdamente caros. Te ofrecen una herramienta, te acostumbrás a utilizarla, dependés de ella y, cuando querés hacer algo parecido por tu cuenta, aparecen las licencias, las restricciones, los formatos propietarios y toda una colección de obstáculos que parecen diseñados para recordarte quién es el dueño del juguete.

Bueno, parece que llegó la hora de empezar a mirar qué hay adentro.

Esta vez, en Thana prueba, ponemos las manos sobre REA (Reverse Engineer Anything), una herramienta de código abierto orientada a la ingeniería inversa que permite investigar cómo están construidas y cómo funcionan otras aplicaciones, incluso cuando no tenemos acceso a su código fuente original.

REA, ingeniería inversa con agentes de programación. Imagen: proyecto REA.

¿Y qué hace exactamente?

REA conecta herramientas de análisis con nuestros agentes de programación mediante MCP o CLI. A partir de ahí podemos inspeccionar aplicaciones, seguir funciones, analizar archivos y dependencias, identificar módulos, rutas de ejecución y relaciones entre componentes. También permite trabajar con binarios nativos, aplicaciones JavaScript/Electron y otros formatos compatibles, dependiendo de las herramientas de análisis disponibles.

El flujo de una investigación: el agente pregunta, REA inspecciona y rastrea con las herramientas de análisis, y devuelve código y evidencia para seguir preguntando. Esquema oficial del proyecto REA.

El proyecto se publica bajo licencia MIT, se instala con npx rea-agents setup y hace el análisis en la máquina local, sin subir los binarios a ningún servidor. Esa combinación —código abierto, trabajo local y evidencia verificable— no es un detalle menor cuando lo que estamos mirando es software ajeno.

La gracia está en que no tenemos que quedarnos mirando una aplicación como si fuera una caja negra. Podemos investigar qué sucede cuando apretamos determinado botón, cómo está implementada una función, qué archivos intervienen o qué lógica hay detrás de una característica que nos gustaría incorporar a nuestros propios desarrollos.

REA lanzando su puente de análisis dentro de Hopper mientras inspecciona un binario nativo. Captura oficial del proyecto REA.

Y eso es exactamente lo que vamos a hacer: empezar con aplicaciones relativamente pequeñas, probar sus funcionalidades, abrirlas en canal y estudiar cómo están hechas. No se trata simplemente de intentar replicar una interfaz bonita, sino de entender qué decisiones técnicas hay detrás, qué podemos aprender y qué podemos construir tomando ese conocimiento como punto de partida.

El anillo de balas de TH04, un juego de PC-98, reconstruido a partir de sus instrucciones de 16 bits. Figura: caso TH04 del proyecto REA.

Porque ahí está lo interesante: una funcionalidad que una compañía considera parte de su producto exclusivo puede ser, desde otra perspectiva, un problema de ingeniería que alguien más puede estudiar y resolver de una manera diferente.

Y acá es donde empieza a ponerse divertido

Durante años, determinadas corporaciones construyeron verdaderos ecosistemas cerrados alrededor de sus herramientas. Compraron competidores, patentaron procesos, restringieron formatos y convirtieron la dependencia del usuario en un modelo de negocio. No necesariamente porque fueran los únicos capaces de desarrollar esas soluciones, sino porque tenían los recursos para controlar su distribución y mantener sus mecanismos internos fuera del alcance de los demás.

Un cambio mucho más grande

REA representa una pequeña pieza de un cambio mucho más grande: el conocimiento técnico empieza a dejar de ser un privilegio reservado a quienes escribieron originalmente el software. Con ingeniería inversa, herramientas abiertas y agentes de inteligencia artificial, un desarrollador independiente puede investigar sistemas que antes resultaban prácticamente inaccesibles y construir sus propias alternativas.

De DXBALL.EXE a una función en C mantenida: el cálculo de paneo de sonido recuperado y verificado contra 3.205 casos del x86 original. Figura: caso DX-Ball del proyecto REA.

No, esto no significa que mañana desaparezcan el copyright, las patentes o las grandes compañías. Pero sí significa que cada vez resulta más difícil sostener un negocio únicamente sobre el misterio de cómo funciona una herramienta.

Quizás no sea el final de las corporaciones, pero sí el principio del final de esa época en la que podían decirnos que algo era imposible de reconstruir simplemente porque no teníamos permiso para mirar cómo estaba hecho.

Tampoco se trata de agarrar cualquier programa y desarmarlo sin pensar. La propia documentación de REA circunscribe la herramienta a la investigación, la educación, la interoperabilidad y la preservación de software que uno posee o está autorizado a examinar. La diferencia con la vieja caja negra no es que ahora podamos hacer cualquier cosa, sino que ahora sabemos qué estamos mirando antes de decidir.

Empezar a desarmar

Así que vamos a empezar a desarmar algunas aplicaciones, investigar sus entrañas y ver hasta dónde podemos llegar. Porque si algo funciona y queremos entender por qué, ahora tenemos algunas herramientas bastante interesantes para averiguarlo.

Y si después podemos construir algo mejor, más libre o que no nos cobre una suscripción por respirar… mucho mejor.

REA está en rea.tools y su código, en github.com/morluto/rea.

Thana prueba. Esta vez, el juguete viene con las instrucciones escondidas.