Ingeniería inversa con IA: el software deja de ser una caja negra

Un desarrollador abre su agente de programación y le hace una pregunta concreta: cómo genera una app de autenticación su código de seis dígitos. No tiene el código fuente, solo la aplicación publicada. El agente abre el paquete, sigue las funciones que intervienen y explica por qué el código cambia cada 30 segundos.

Hasta hace poco, ese análisis exigía un especialista en ingeniería inversa y herramientas como Ghidra o IDA. Ahora puede plantearlo cualquier equipo con un agente bien configurado.

La ingeniería inversa asistida por IA convierte el software publicado en algo que se puede estudiar, y eso cambia cómo diseñamos, protegemos y construimos aplicaciones. Es una tecnología polémica y disruptiva, y conviene entender sus dos caras antes de tomar partido.

Qué es REA y por qué está en todas partes

REA (Reverse Engineer Anything) es un proyecto de código abierto, con licencia MIT, que conecta agentes de programación como Claude Code, Codex, Cursor o Gemini CLI con herramientas de ingeniería inversa. Según su repositorio, funciona como servidor MCP y línea de comandos, analiza en local y trabaja con binarios nativos, aplicaciones Electron y JavaScript, webs, ensamblados .NET, APK de Android, WebAssembly o firmware.

Sus demostraciones son concretas: cómo el autenticador Aegis calcula su código de acceso, cómo Notion conserva el formato al copiar bloques o cómo DX-Ball, un juego de 1996, decide si un sonido suena a la izquierda o a la derecha. En ese último caso, InfoQ recoge que la función reconstruida supera pruebas que coinciden con los 3.205 casos del código x86 original.

El 17 de octubre de 2026, InfoQ contaba más de 200.000 estrellas en GitHub; dos días después, el repositorio superaba las 300.000. La novedad no es el descompilador: REA se apoya en motores existentes como Ghidra, Hopper o IDA y, según InfoQ, no pretende recuperar el código fuente original. Lo nuevo es que un agente formula hipótesis, consulta el programa y las comprueba una y otra vez.

La parte polémica: ¿se puede abrir y copiar cualquier programa?

Se ha extendido la idea de que cualquier aplicación puede «desencriptarse» y replicarse. Hay matices, pero la preocupación es legítima.

REA examina lo que el software entrega al dispositivo: código compilado, paquetes de JavaScript, recursos y llamadas de red. Lo que se ejecuta en un servidor nunca llega a la máquina analizada. Y su propio aviso de uso responsable advierte de que el resultado de una descompilación puede ser incompleto o erróneo.

Pero lo que llega al dispositivo es mucho: la lógica de una funcionalidad, sus cálculos y los servicios a los que llama. Si todo eso vive en el cliente, entenderlo y reproducirlo cuesta ahora mucho menos. InfoQ recoge el temor de desarrolladores independientes a copias de sus juegos y apps o a que se salten sus funciones de pago, y un comentario en Hacker News que prevé que esto acelerará el paso de las aplicaciones de las grandes tecnológicas a la nube.

El propio proyecto marca la línea: rechaza ayudar a saltarse DRM o licencias, a crear trampas para juegos o a copiar código propietario, y recuerda que obtener algo parecido al código fuente no da derechos sobre el programa original.

Qué dice la ley: estudiar sí, clonar no

En España, el artículo 100 de la Ley de Propiedad Intelectual, en línea con la Directiva 2009/24/CE, marca una frontera clara:

• El usuario legítimo de un programa puede observar, estudiar o verificar su funcionamiento para determinar las ideas y principios en los que se basa, mientras lo usa con normalidad.
• La descompilación sin autorización solo se admite cuando es indispensable para la interoperabilidad con un programa creado de forma independiente, si esa información no estaba ya disponible y limitándose a las partes necesarias.
• Lo obtenido no puede usarse para desarrollar un programa sustancialmente similar en su expresión, ni para ningún otro acto que infrinja los derechos de autor.

En resumen: las ideas se estudian; el código ajeno no se copia. A eso se suman las licencias y contratos de cada producto, y ante un caso concreto conviene pedir asesoramiento jurídico antes de analizar nada.

La otra cara: conocimiento técnico al alcance de equipos pequeños

Bien usada, democratiza un saber reservado hasta ahora a muy pocos perfiles. Para un estudio como el nuestro, abre posibilidades concretas:

• Entender infraestructuras similares a las de un proyecto antes de diseñarlo: cómo resuelve otra aplicación la sincronización o la caché.
• Auditar la seguridad de nuestras propias aplicaciones con la mirada de un tercero.
• Integrar sistemas de un cliente sin documentación suficiente, dentro de los límites de la interoperabilidad.
• Analizar el software que una empresa ya tiene para diseñarle una herramienta a medida que cubra lo que de verdad utiliza.
• Recuperar datos de herramientas antiguas que el cliente quiere dejar atrás.

Cuando contamos que el SaaS ha muerto «tal y como lo conocíamos», hablábamos de construir herramientas propias con IA en días. La ingeniería inversa asistida completa ese movimiento: también facilita entender a fondo la herramienta que se quiere sustituir.

Qué cambia en las apps y dinámicas que desarrollamos

Muchas de nuestras dinámicas para ferias funcionan en tótems, tabletas o en el móvil del visitante, en espacios públicos. Con herramientas como REA, partimos de una premisa: cualquiera con tiempo y curiosidad puede estudiar lo que instalamos en un dispositivo.

En el quiz interactivo de MITMA, el visitante responde, suma estrellas y, según las que consigue, escanea un código QR para recibir su premio. En una mecánica así, proponemos validar la puntuación y el premio en el servidor, con códigos de un solo uso, y no solo en la app que el visitante tiene delante.

Photo AI es una de las dinámicas estrella de WOMI, nuestra plataforma propia, y la edición de Turespaña 2026 es uno de sus mejores ejemplos: el visitante se hace una foto y, en tres pasos, aparece en distintos lugares de España. Cuando una plataforma así viaja de feria en feria, la lógica que le da valor y cualquier credencial de los servicios de IA deben quedarse en el servidor; el tótem solo necesita mostrar la experiencia.

Cómo proponemos incorporarlo a nuestro método

No se trata de usarlo para todo, sino en momentos concretos del desarrollo:

1. Revisión antes de entregar. Analizar nuestras propias compilaciones (web, escritorio o Android) como lo haría un tercero: claves expuestas, servicios accesibles, mapas de código fuente o modos de depuración olvidados.
2. Lo sensible, en el servidor. Premios, puntuaciones, credenciales y datos personales se diseñan desde el principio fuera del dispositivo.
3. Descubrimiento técnico del software del cliente. Con licencia y autorización, entender formatos y flujos para integrarlo o diseñar una alternativa. Primero pedimos documentación al fabricante; la ingeniería inversa llega si esa vía no existe.
4. Estudiar ideas, no copiar código. Si otro producto resuelve bien un problema, documentamos el principio y escribimos nuestra propia implementación.
5. Verificar con pruebas. Cada conclusión del agente se contrasta con tests y revisión humana, como en el caso de DX-Ball.

Lo que viene en los próximos meses

Nuestra lectura es que el valor del software se desplaza. El código que llega al dispositivo protege cada vez menos; lo que diferencia un producto es el servicio que hay detrás, los datos, la experiencia y el criterio con que se construye. Es previsible ver más lógica en servidores, licencias que mencionen el análisis con agentes y equipos que estudian software ajeno con la naturalidad con que hoy leen documentación.

Para quien encarga una aplicación, la pregunta ya no es solo qué hace, sino también qué deja ver.

Si quieres saber qué expone tu aplicación actual, integrar una herramienta que ya usas o diseñar una a medida pensando en este nuevo escenario, cuéntanos tu proyecto. En Viseni lo estudiamos contigo, con criterio técnico y dentro de la ley.