Noticias

Agentes de IA reconstruyeron el código fuente de Slack, el Finder de Apple y un malware ruso a partir de sus binarios

8 min de lectura

La investigación de Intezer en un esquema: del binario y la documentación pública, pasando por los agentes de IA (Codex, Kimi K3 y Claude), al código fuente que se compila y se compara con el original; qué tan completos quedaron Slack, el Finder de macOS y TinyTurla-NG, lo que no se publicó y la defensa que recomienda Intezer. Datos de Intezer Research. Infografía: decodigo.com.

Investigadores de la empresa de seguridad Intezer pusieron a agentes de IA a hacer algo que hasta hace poco requería meses de trabajo de especialistas: tomar programas ya compilados, tal como se descargan, y convertirlos otra vez en código fuente legible que se puede compilar y modificar. Lo intentaron con tres: el cliente de Slack, el Finder de macOS y TinyTurla-NG, una backdoor del grupo de espionaje ruso Turla. Los tres funcionaron, con huecos, y en el caso de Slack hasta le agregaron una función que la app original no tiene.

La ingeniería inversa de software es tan vieja como el software. El dicho del gremio era que, si sabes leer ensamblador, todo programa es de código abierto. Pero entre leer el ensamblador y tener un proyecto mantenible hay un trecho enorme: los descompiladores devuelven pseudocódigo sin nombres ni comentarios, útil para entender una función, no para mantener una aplicación entera. La pregunta de Intezer fue si los agentes de IA ya pueden cubrir ese trecho solos, a partir de lo mismo que tiene cualquier usuario: el binario o el paquete de instalación y la documentación pública del fabricante.

Claves de la investigación de Intezer

  • Quién y cuándo. La publicó el 10 de noviembre Nicole Fishbein, de Intezer, con el investigador Eran Segal, de Kodem Security. Eligieron programas con cuyo código, hasta donde saben, la IA no se entrenó.
  • Qué agentes usaron. Codex, el agente de OpenAI, configurado con GPT-5.6-sol-high, dirigió el caso más difícil; Kimi K3, alojado en Fireworks, cumplió tres papeles aislados dentro del mismo sistema, y Claude participó en el caso de Slack. Alrededor, herramientas clásicas como Binary Ninja, BinDiff, webcrack y Asar.
  • Qué contaba como éxito. Código legible y mantenible, comparable al que escribe una persona, que se compile solo con lo reconstruido, sin librerías de terceros metidas dentro y que se comporte igual que el original.
  • Slack. Reconstruyeron el cliente y, como el servidor no se puede descargar, construyeron uno compatible sobre SQLite. Después le agregaron autocompletado de texto con un modelo local pequeño.
  • Finder. La copia navega, copia, mueve, busca, etiqueta y muestra Get Info y Quick Look, pero no maneja los archivos solo en línea, el estado de sincronización ni las acciones que dependen de otros servicios de macOS.
  • TinyTurla-NG. La DLL reconstruida pesa 296,960 bytes contra 291,840 del original e importa exactamente los mismos símbolos. Nunca se ejecutó: todo fue análisis estático.
  • Lo que no dicen. Ni cuánto tardaron ni cuánto gastaron en total. Tampoco publicaron nada: aclaran que no comparten ni distribuyen el código, los binarios ni ningún otro material reconstruido.
Del binario al código fuente Cómo trabajaron los agentes de Intezer Lo que cualquiera puede descargar el binario o el paquete de la app y la documentación pública Harness con agentes de IA Codex con GPT-5.6-sol-high dirige Kimi K3 cumple tres papeles aislados Claude identificó las librerías de Slack Binary Ninja, webcrack y Asar Código fuente nuevo legible y sin librerías de terceros compilar Programa reconstruido compilado solo con ese código comparar Contra el original Slack: pruebas de punta a punta Finder: navegar, copiar, buscar TinyTurla: función por función en Binary Ninja, más BinDiff Datos: Intezer. Esquema: decodigo.com.
Cómo trabajaron los agentes: del binario y la documentación al código fuente, y de ahí a un programa que se compara con el original. Esquema: decodigo.com con datos de Intezer.

Slack fue el caso de dificultad media. Su cliente de escritorio está hecho con Electron, TypeScript y React, y trae más de 500,000 funciones, casi todas de librerías de terceros. Los investigadores lo extrajeron con Asar, le quitaron la minificación con webcrack y lo partieron en módulos siguiendo un patrón que se repite en todo el paquete. Claude se encargó de identificar qué librerías eran ajenas a Slack, algunas escondidas dentro del propio código. Lo difícil fue el servidor: Salesforce, dueña de Slack desde 2021, no lo distribuye, así que los agentes escribieron uno compatible a partir de las llamadas que hace el cliente, de la inspección del tráfico de la app real y de la documentación de la API de Slack. Usa SQLite con el esquema mínimo para servir de prueba de concepto. Para validarlo, el equipo controló varios clientes a la vez con el Chrome DevTools Protocol, presionando botones y escribiendo texto, mientras un servidor simulado capturaba el tráfico. Y para demostrar que el resultado se puede mantener como cualquier proyecto, le pidieron a Claude una función nueva: autocompletado de texto con IA, servido por el modelo qwen2.5:3b. Según Intezer, la terminó en una sola sesión corta.

El Finder quedó en dificultad baja a media. El paquete trae un ejecutable de 25.8 MB, para Intel y Apple Silicon, más archivos de interfaz, imágenes y textos. El sistema fue función por función: buscaba en el binario los controles visibles y el código que llaman, implementaba la acción y la probaba con carpetas y archivos temporales. Cuando el binario no revelaba cómo lo hace Apple, porque depende de otros servicios del sistema, recurría a las API públicas de macOS y anotaba en qué podía diferir. Por eso Intezer advierte que por dentro su Finder no se parece al de Apple, aunque por fuera haga lo mismo en el uso diario.

Captura del Finder reconstruido por los agentes de Intezer: ventana en modo oscuro con la barra lateral de Favoritos y Ubicaciones, la vista de lista con las carpetas Applications, Library, System y Users, y los botones Icons, List, Columns y Gallery
El Finder «reconstruido» por los agentes, compilado solo con el código que escribieron. Imagen: Intezer.

El caso difícil fue TinyTurla-NG, una backdoor que Cisco Talos describió en febrero de 2024 y atribuyó al grupo Turla, que la usó contra organizaciones civiles de Polonia, al menos una de apoyo a Ucrania. Es una DLL de Windows de 64 bits que funciona como acceso de reserva para los atacantes. La muestra no estaba empaquetada ni ofuscada, pero sí compilada sin símbolos: nada de nombres de funciones ni de archivos. Intezer puso reglas estrictas. El binario manda: un modelo puede proponer una interpretación, pero solo cuenta si la respalda el análisis estático de Binary Ninja. Nada se ejecuta, ni el original ni la copia. Codex compila en una máquina virtual de Windows a la que se conecta por SSH, y a Kimi K3 nunca le llegan los binarios ni las credenciales; además, antes de cada revisión se borra el contenido de las cadenas de texto. Cada petición queda en un registro de gasto que obliga a conservar una reserva de cinco dólares por debajo del tope autorizado, lo único que dicen sobre el costo.

El resultado son unas 3,100 líneas de C++ en dos archivos que cubren todo lo que hace el implante: registrarse con sus servidores de comando y control, recibir y ejecutar órdenes, abrir una shell, transferir archivos y borrarse. La copia tiene 1,072 funciones contra 1,041 del original, y BinDiff empareja 1,034 de ellas con un 92.8 % de parecido estructural y una confianza de 98.7 %. Intezer insiste en que eso mide la forma, no el comportamiento, que comprobó comparando cada función reconstruida con su original en el lenguaje intermedio de alto nivel de Binary Ninja. Dos detalles honestos: el runtime de C++ de Microsoft se enlazó en lugar de reescribirlo, y el original parece incluir partes de un compilador preliminar que no está disponible, así que la herramienta de compilación es solo una aproximación.

Comparación lado a lado de Intezer: a la izquierda, el código C++ reconstruido de una función de TinyTurla-NG que abre cmd.exe con tuberías para capturar su salida; a la derecha, la misma función del binario original descompilada en Binary Ninja
La misma función de TinyTurla-NG: a la izquierda, el código C++ que escribieron los agentes; a la derecha, lo que muestra Binary Ninja al descompilar el original. Imagen: Intezer.
Tres programas, tres resultados Dificultad según Intezer Slack dificultad media cliente reconstruido y funcionando servidor compatible sobre SQLite autocompletado nuevo con qwen2.5:3b no es el servidor real, que no se descarga Finder baja a media ejecutable de 25.8 MB navegar, copiar, buscar, etiquetas Get Info y Quick Look archivos solo en línea estado de sincronización acciones de otros servicios de macOS TinyTurla-NG difícil DLL: 296,960 bytes contra 291,840 1,072 funciones contra 1,041 símbolos importados idénticos BinDiff: 92.8 % de parecido unas 3,100 líneas en dos archivos runtime de C++ enlazado, no reescrito Datos: Intezer. Esquema: decodigo.com.
Los tres programas, la dificultad que les asignó Intezer y qué tan completos quedaron. Esquema: decodigo.com con datos de Intezer.

Cuando compilar ya no esconde el código

Muchas empresas cuentan con que distribuir un programa compilado protege su código, porque reconstruirlo era caro. Intezer sostiene que ese supuesto se está cayendo: los agentes no lo hicieron sin tropiezos, pero cada mes salen modelos más capaces. Para quien defiende sistemas, la noticia es buena: leer el código fuente de un malware es mucho más rápido que descifrar su ensamblador. Para quien vende software, su conclusión es que «la industria tendrá que ajustarse». Mientras tanto recomienda lo de siempre, cifradores y ofuscadores, como los que usa el anti-cheat de los videojuegos, porque elevan la dificultad para los agentes. Su propia experiencia apunta en la misma dirección: les costó más donde había poca documentación, metadatos pobres y código de bajo nivel. Y reconstruir el cliente no basta: echar a andar la infraestructura de la que depende, como el servidor de Slack, es mucho más difícil.

Ya hay quien construye esa defensa pensando en la IA. El mismo 10 de noviembre, The Register presentó Blind LLM Agents, de Timo Zhang, un desarrollador y estudiante que propone «cegar» a los agentes que analizan apps: renombra símbolos, cifra cadenas, cambia la compilación en cada versión y siembra señuelos, sin alterar lo que hace el programa. Su lema es que el comportamiento queda igual y lo que sube es el costo de recuperar la lógica, aunque no promete resistir a herramientas como Ghidra o Frida.

Los fabricantes de los propios agentes también se mueven, aunque de forma confusa. Anthropic confirmó que le pidió a Claude Code que no recree juegos ajenos, y usuarios reportaron, según Tom’s Hardware, que Opus 5.5 empezó a frenar tareas de ingeniería inversa. 404 Media recogió quejas parecidas con Codex, aunque Tarun Gogineni, ingeniero de OpenAI, aclaró que no hay ninguna prohibición de hacer ingeniería inversa con Codex y que esos bloqueos son en su mayoría accidentales. Es la paradoja del estudio: Intezer usó justamente Codex y Claude. Lo legal tampoco es sencillo. Muchas licencias prohíben expresamente la ingeniería inversa, y en Estados Unidos la sección 1201 de la DMCA castiga saltarse protecciones técnicas aun con un fin legítimo, un terreno que juristas de Cornell ya advirtieron que la IA está desbordando. Intezer se cubre: lo hizo con fines de investigación, en un laboratorio aislado, y dice que no busca animar a nadie a violar licencias. Si tienes dudas sobre un caso concreto, la respuesta la da un abogado, no esta nota.

El experimento no produjo copias perfectas: el Finder tiene huecos, el servidor de Slack es un sustituto y la DLL de TinyTurla salió unos kilobytes más grande. Pero tres programas muy distintos, uno en un lenguaje de alto nivel, otro nativo de Apple y un malware sin símbolos, terminaron como proyectos que se compilan, se prueban y se pueden ampliar. Lo que antes era trabajo de semanas para un especialista empieza a ser una tarea que se le encarga a un agente, y eso obliga a fabricantes, defensores y legisladores a replantear qué protege de verdad un binario.

Fuente: Intezer Research, «When Everything Becomes Open-Source»; Help Net Security; Cisco Talos; The Register; Tom’s Hardware; 404 Media.