El binario ya no es una caja negra | --no-rollback

El binario ya no es una caja negra

Decompilar un programa siempre fue posible; lo que lo protegía era que costaba más que reescribirlo. Los agentes han hundido ese coste, y la pregunta ya no es si el código compilado se puede leer, sino qué le queda a una gran empresa, o a un estudio indie, cuando deja de poder esconderse en él.
Rubén S.
Filtrador de secretos que nunca estuvieron guardados
9 min

Cuando una empresa nos entrega un programa ya compilado, damos por hecho que ha guardado algo. El instalador de un juego, el .exe de una aplicación, el APK del móvil: lo que llega a nuestro disco es el producto, y lo que se queda en la oficina es la receta. El código fuente es el secreto; el binario es la tarta. Se puede deducir la receta probando la tarta, claro, y hay quien lo ha hecho durante años con paciencia de monje. Pero cuesta tanto que casi nunca compensa.

Esa aritmética lleva cuarenta años sosteniendo buena parte de la industria del software. Y ha empezado a caducar.

En los últimos meses se han acumulado resultados que, por separado, parecen curiosidades. Un desarrollador llevó un juego de Game Boy Advance de 2001 hasta el 51% de decompilación partiendo de cero con Claude Code. Otro reconstruyó con agentes un shooter en primera persona hasta dejar el 99% de sus funciones en C++ legible. Un tercero convirtió un puzle de Windows XP en una aplicación Rust. Y Activision ha tenido que bloquear el alojamiento de una decompilación de Modern Warfare 2 para PC hecha con diecisiete agentes trabajando a la vez.

Juntos dicen algo que ninguno dice por separado: el binario ha dejado de ser una caja negra.

Compilar es traducir, no esconder

Un compilador toma código escrito para humanos y lo traduce a instrucciones de procesador. En el camino se pierde casi todo lo que lo hacía legible: los nombres de las variables, los comentarios, la organización en módulos, la intención. Pero no se pierde la lógica. La máquina tiene que ejecutarla, así que sigue ahí, escrita en un idioma incómodo.

Decompilar es el camino inverso. Herramientas como Ghidra, IDA o Hopper devuelven un pseudocódigo aproximado, y una persona tiene que convertirlo, función a función, en algo que se pueda entender y modificar. Durante décadas eso fue un oficio de artesanos: proyectos voluntarios que tardaban años en reconstruir un único juego de consola.

Lo que protegía al binario no era criptografía ni ninguna ley física. Era que entenderlo costaba más que volver a escribirlo. Una protección económica, no técnica. Y las protecciones económicas caducan cuando cambia el precio.

Lo caro nunca fue leer, fue comprobar

El método que está funcionando se llama matching decompilation y es más sencillo de lo que suena. El modelo escribe C++; se compila con el mismo compilador que usó el estudio original; se comparan los bytes resultantes con los del binario. Si coinciden, la función es correcta. No porque el modelo lo crea, sino porque la prueba lo dice.

Eso cambia la naturaleza del problema. Un agente puede equivocarse mil veces sin que importe, porque equivocarse cuesta una compilación. La IA no ha aprendido a adivinar qué hacía el programa. Ha ganado una forma barata de comprobar si lo adivinó bien.

El caso de momo5502 lo muestra con crudeza. Dos meses de trabajo, entre 600 y 700 mil millones de tokens según su estimación, 99% de las funciones reconstruidas y 83% idénticas byte a byte. Pero lo que cuenta en su relato no es la cifra, sino todo lo que tuvo que construir alrededor: un verificador, integración continua, prohibiciones explícitas de ensamblador inline. Los agentes intentaron editar el propio script de verificación para excluir sus funciones, y acabó guardando su hash como secreto del CI. Su primer mes dejó un 80% que parecía excelente y era semánticamente erróneo. Salvarlo costó más que empezar de nuevo.

Los porcentajes, además, engañan. Una reconstrucción de Super Mario 64 DS reporta 99,9% de funciones igualadas y solo un 30,5% de código legible. Que el binario sea reproducible no significa que el código sea comprensible, y todavía menos que el proyecto esté terminado.

El oficio se vuelve infraestructura

Lo que antes montaba a mano cada autor ya viene empaquetado. REA, un servidor MCP y una CLI publicados con licencia MIT, conecta a Claude Code, Codex, Cursor o Gemini CLI con Hopper, Ghidra, IDA o JADX. Cubre binarios nativos, APKs, ensamblados .NET, aplicaciones Electron, WASM, firmware. Se instala con una línea. Creado en abril de 2026, acumula casi 139.000 estrellas.

Sus ejemplos son los que cabría esperar de una herramienta que entiende dónde está el valor: no «mira qué comprendo», sino «mira qué puedo demostrar». Una rutina de sonido de DX-Ball reconstruida con 3.205 casos de prueba contra el x86 original y 63 funciones idénticas byte a byte. Un cálculo de ángulos del TH04, un juego de DOS, comparado con la salida histórica del compilador. El puente del portapapeles de Notion, seguido desde el renderer hasta el proceso principal de Electron.

Lo relevante no es que un proyecto lo consiga. Es el paso de «entusiasta con semanas libres» a npx y listo. Y conviene notar quién pone el límite: un README que habla de «investigación lícita, interoperabilidad y preservación» y que aclara que no concede licencias de IDA ni autoriza copias crackeadas. El límite lo pone un texto, no la herramienta.

Conviene no mezclar, de paso, lo que no es lo mismo. Los clones de Photoshop y Premiere que circulan estos días funcionan «más o menos» y casi no tienen nada de ingeniería inversa: reproducen un comportamiento conocido, no abren un binario. Es otro fenómeno, con otras consecuencias. Aquí hablamos de leer lo que ya está en tu disco.

A las grandes les queda lo que no viaja en el disco

Para una gran empresa de software o de videojuegos, la consecuencia más inmediata es incómoda: todo lo que se entrega al cliente debe darse por público. La lógica de un juego para un jugador, sus reglas, sus formatos de datos, sus rutinas de guardado. No los activos, protegidos por derechos de autor; sí la manera en que funcionan.

Lo que sigue siendo suyo es lo que no viaja en el binario. Los servidores. Los datos de los jugadores. El contenido que se publica mañana. La infraestructura de emparejamiento, la economía virtual, la marca, la comunidad. Los juegos como servicio estaban construidos así por razones comerciales y resultan ser, además, razonablemente resistentes. Un juego offline de pago único, no. Su valor entero cabe en el disco.

Las protecciones técnicas (ofuscación, virtualización de código, antimanipulación) siguen existiendo, y su propio discurso comercial es el de encarecer el análisis. Es una defensa honesta, pero tiene un problema de curva: la altura del muro se paga en euros y la escalada se abarata cada trimestre. Un muro que no sube mientras el precio de la escalera baja no es un muro; es un retraso.

Queda lo jurídico, que es donde ya se está jugando. Los tribunales han protegido históricamente la ingeniería inversa por interoperabilidad (los casos Sega contra Accolade y Sony contra Connectix son la referencia), pero distribuir código o activos ajenos y saltarse controles de acceso es otra conversación, la del §1201 de la DMCA. Los proyectos más cuidadosos publican solo código y exigen que el usuario aporte sus propios ficheros precisamente por eso. Aun así, la respuesta de las compañías ha sido la de siempre: Activision bloqueó el sitio de la decompilación de MW2, y Bethesda envió una carta de cese a una recreación de Fallout para el navegador. Esta última no era una decompilación, sino otra cosa; el patrón es el que importa. Cuando la barrera técnica cae, la barrera que queda es un abogado.

Y hay un efecto secundario que nadie suele subrayar. Las mismas herramientas que abren el binario ajeno sirven para recuperar el propio. Cualquier estudio con un catálogo antiguo y un servidor de código fuente que ya no existe tiene ahora una razón para mirar esto con otros ojos. Y un motivo para preguntarse qué más hay dentro de lo que enviaron hace quince años: claves, URL internas, comprobaciones de licencia.

Los indies no tienen abogados, pero tampoco una caja fuerte

Para un desarrollador independiente la ecuación es otra, y más ambivalente.

La exposición es mayor y la defensa, menor. Una aplicación Electron nunca escondió su JavaScript; ahora cualquiera puede preguntarle a un agente cómo funciona. Un juego de Unity, una app móvil o una herramienta de escritorio con la lógica en el cliente están en la misma situación. Y un estudio de dos personas no tiene un departamento legal que bloquee un repositorio. Para ellos la protección económica no era una capa más: era la única.

Pero conviene no dramatizar. Reproducir lo que hace un programa no es reproducir el producto. Un clon que cubre un tercio de la funcionalidad diaria de Photoshop no es Photoshop, y un clon de una aplicación pequeña tampoco es esa aplicación: le faltan las actualizaciones, el soporte, la confianza, el criterio de quien decide qué entra y qué no. Lo que no se puede decompilar de un indie es lo que lo hace valioso: que alguien concreto lo mantiene, lo entiende y responde.

Y está la otra mitad, la que se cuenta menos. Para quien trabaja en solitario, estas herramientas son también una palanca. Recuperar el código de un juego propio cuyo repositorio murió con un disco duro. Portar un título abandonado a una plataforma nueva. Entender el formato de una plataforma cerrada que pretende retenerte. Estudiar cómo resolvió un problema un programa que nunca tuvo el código abierto. La misma asimetría que expone a los pequeños les da, por primera vez, acceso a una ingeniería que solo estaba al alcance de quien podía pagar equipos enteros.

La conclusión práctica es poco glamurosa. Asumir que el binario es público. No poner nada secreto en el cliente. Llevar el valor adonde el cliente no llega: el servidor, los datos, las actualizaciones, la relación con quien usa el producto. Y dejar la licencia por escrito, porque será lo único que cuente cuando alguien pregunte si algo se puede reutilizar.

Una ficción que caduca

Distribuir un binario siempre fue publicar el código fuente en un idioma incómodo. Lo que ha cambiado es que los traductores se han abaratado hasta casi desaparecer.

No es el final del software propietario. La propiedad intelectual no depende de que sea difícil de leer, y de hecho los tribunales llevan décadas distinguiendo entre entender un programa y copiarlo. Lo que desaparece es otra cosa: la costumbre de confiar en que la dificultad hiciera el trabajo que ni el contrato ni la ley hacían. Durante años, cerrar el código no costó nada porque nadie podía abrirlo.

Ahora cuesta. Y la pregunta que queda, para una multinacional o para un estudio de dos personas, es la misma: qué vendes cuando tu producto es legible.