La ingeniería inversa con IA ha pasado en pocos meses de ser una curiosidad de especialistas a algo que cualquiera con cierta soltura técnica puede probar en su propio ordenador. Herramientas gratuitas como REA permiten que un agente de inteligencia artificial examine un programa ya terminado e intente explicar cómo funciona por dentro. Y, como suele ocurrir en seguridad informática , en cuanto aparece una forma nueva de atacar aparece también alguien que intenta frenarla.
En este caso, ese alguien es BLA, un proyecto de código abierto que propone una defensa poco habitual: en lugar de esconder el código, lo llena de pistas falsas para que la IA se pierda por el camino. A continuación te contamos qué hacen exactamente estas dos herramientas, qué hay de cierto en lo que se dice de ellas y qué cifras conviene leer con prudencia.
Qué es la ingeniería inversa con IA y qué hace REA
La ingeniería inversa consiste en estudiar cómo funciona un programa sin tener su código fuente, es decir, sin las instrucciones originales que escribieron sus autores. Es como desmontar un reloj ya montado para entender su mecanismo sin tener los planos. Durante años ha sido un trabajo lento y manual, reservado a analistas con mucha experiencia.
REA (siglas de Reverse Engineer Anything, algo así como «ingeniería inversa de cualquier cosa») busca que parte de ese trabajo lo haga un agente de IA, es decir, un modelo de inteligencia artificial capaz de usar herramientas externas por su cuenta. Según la reseña publicada en Buttondown, el proyecto se publicó en GitHub el 14 de abril de 2026 con licencia MIT, una licencia que permite usarlo y modificarlo gratis. Funciona como un servidor MCP y como herramienta de línea de comandos. MCP es un estándar abierto que permite a los agentes de IA conectarse a otras herramientas, algo así como un enchufe universal para que la IA pueda manejar programas ajenos.
Con ese enchufe, el agente pone a trabajar en el ordenador del usuario descompiladores conocidos como Ghidra, IDA, Hopper o JADX. Un descompilador intenta reconstruir un código legible a partir de un programa ya compilado, igual que alguien que intentara deducir una receta probando el plato terminado. Según su repositorio oficial, REA sirve para inspeccionar programas nativos, aplicaciones hechas con JavaScript y Electron (la tecnología con la que se construyen muchos programas de escritorio a partir de tecnologías web), ensamblados .NET y sitios web. Su popularidad se disparó: según PiyushAI, pasó de menos de 10.000 a cientos de miles de estrellas en GitHub durante octubre de 2026, aunque el número exacto varía según la fuente que se consulte.
Se suele decir que, con esto, un agente de IA puede desarmar casi cualquier programa y que es muy fácil. Es una exageración. Como explica Buttondown, REA no convierte a la IA en un descompilador autosuficiente: hace falta tener instaladas las herramientas de análisis, proporcionar al agente un programa que se esté autorizado a analizar y plantearle una pregunta de investigación concreta. Tampoco hay pruebas de que pusiera nerviosa a buena parte de la industria: lo que recoge AICoder es un debate intenso entre desarrolladores en X, sin fuentes que documenten reacciones de empresas.
Por qué la ofuscación tradicional podría quedarse corta
La forma clásica de proteger un programa que se distribuye es la ofuscación: hacer el código difícil de leer, por ejemplo cambiando los nombres de las variables por letras sin sentido o enredando su estructura. Es como escribir una carta en un idioma que solo entiende quien tiene la clave. Funciona porque a una persona le cuesta mucho tiempo y paciencia descifrar ese galimatías.
Quienes defienden enfoques como el de BLA sostienen que esa barrera pierde eficacia cuando quien lee el código es una IA, porque los modelos reconocen patrones con rapidez y no se cansan. También se repite que durante décadas se protegió el código pensando solo en lectores humanos. Son opiniones razonables, pero no las hemos podido contrastar con estudios o datos independientes, así que conviene leerlas como argumentos del debate y no como hechos demostrados.
Cómo funciona BLA: envenenar, agotar y alucinar
BLA son las siglas de Blind LLM Agents, que podría traducirse como «agentes de IA a ciegas». Según su repositorio oficial, la idea no es ocultar el código, sino conseguir que la IA lo interprete mal y se quede sin presupuesto antes de entender nada útil. Hay un matiz importante: BLA no toca los archivos fuente con los que trabajan los programadores, sino los artefactos de compilación, que son la versión final del programa que se entrega a los usuarios.
Para entender la estrategia hay que hablar de los tokens. Un token es un fragmento de texto que la IA procesa y por el que normalmente se paga. Cuanto más código tiene que leer y razonar un agente, más tokens consume y más dinero cuesta el análisis, como un taxi cuyo taxímetro sigue corriendo mientras el conductor da vueltas. BLA quiere que ese taxímetro no pare.
El proyecto resume su método en un lema de tres pasos:
- Envenenar: sembrar el programa de señuelos, como claves falsas y lógica que parece importante pero no hace nada útil.
- Agotar: colocar trampas de recursos que obligan al agente a gastar tokens en caminos sin salida y a repartir su atención entre hipótesis que se contradicen.
- Alucinar: lograr que la IA acabe sacando conclusiones sobre un funcionamiento que en realidad no existe.
Estos señuelos funcionan como lo que en seguridad se llama un honeypot o trampa: un cajón con una llave falsa que hace perder el tiempo a quien intenta abrirlo. Eso sí, la descripción de estas trampas procede del propio proyecto y no hemos encontrado pruebas independientes que confirmen cómo se comportan frente a agentes reales.
BLA se distribuye a través de npm, el gran almacén de paquetes de JavaScript, con el nombre bla-agents, y su repositorio indica que es compatible con asistentes como Claude Code, Codex, Cursor y Gemini CLI, entre otros. El número de formatos de archivo que puede proteger varía según la fuente: unas hablan de más de 19 y otras de 26. Su crecimiento también ha sido rápido: según i10x, el repositorio se creó el 25 de octubre de 2026 y el 9 de noviembre ya tenía 3.887 estrellas y 478 copias derivadas (forks). Se ha dicho que alcanzó casi 4.000 estrellas en seis semanas, pero en realidad le bastaron unos quince días.
Las cifras: lo que dice el proyecto y lo que está comprobado
El dato más llamativo de BLA es que el atacante gastaría entre 300 y 2.800 veces más tokens al analizar un programa protegido. Conviene leerlo con mucho cuidado. Como explica ExplainX, el propio proyecto presenta esos importes en tokens y en dólares como estimaciones internas, no como mediciones. La suma total de su propia tabla da unas 639,5 veces más tokens y unas 304,4 veces más coste, y otra fuente recoge un rango distinto, de 162 a 2.532 veces, lo que indica que las cifras no son estables.
Las pruebas reales que el proyecto ha hecho contra REA miden otra cosa: cuántas veces falla el analizador, no cuánto se multiplica el gasto. Son datos útiles, pero no equivalen a demostrar el multiplicador de coste. En nuestra búsqueda no hemos encontrado ninguna verificación independiente de esas cifras.
Algo parecido ocurre con la promesa de que el programa funciona exactamente igual para el usuario. El proyecto afirma una equivalencia del 100 % en tiempo de ejecución, es decir, que el programa se comporta igual aunque por dentro esté modificado, pero ese resultado se refiere a sus 14 objetivos de prueba. No hay datos sobre aplicaciones reales de terceros. Además, las trampas ocupan espacio: en la prueba del propio proyecto, un archivo de una aplicación Electron pasó de 607 bytes a 16,9 MiB. Por eso la reseña de Review Ramble señala que el coste real para quien lo usa son descargas más grandes y más tiempo para verificar cada versión.
¿Es realmente un antídoto contra la ingeniería inversa con IA?
Presentar BLA como el antídoto definitivo es quedarse corto en matices. Como explica Starlog, su protección es económica y no criptográfica: no hace el análisis imposible, solo intenta hacerlo caro. Un atacante con mucho presupuesto puede, sencillamente, pagar ese coste extra en tokens. Es como una puerta muy pesada: disuade a muchos, pero no detiene a quien está dispuesto a empujar el tiempo suficiente.
Review Ramble añade que un analista humano decidido sigue pudiendo superar la protección, ya que las trampas están pensadas sobre todo para confundir a los agentes automáticos. Y en el debate entre desarrolladores se ha recordado que una herramienta así no sustituye a las comprobaciones que se hacen en el servidor ni a una buena gestión de las claves. Dicho de otro modo, BLA puede ser una capa más, pero no la cerradura principal.
¿Y a mí en qué me afecta?
Si eres usuario de aplicaciones, lo más probable es que no notes nada a simple vista. Si algún programa que usas adopta este tipo de protección, el cambio más visible podría ser que sus descargas ocupen bastante más. Si desarrollas o encargas software, en cambio, hay algunas ideas sencillas que conviene tener presentes:
- No guardes secretos dentro de la aplicación: las claves importantes y las comprobaciones críticas deben vivir en el servidor, no en el programa que se descarga el usuario.
- Trata las cifras con cautela: los multiplicadores de coste de BLA son estimaciones del propio proyecto, no mediciones independientes.
- Prueba tu propio programa: la equivalencia del 100 % se ha comprobado en 14 casos de prueba, así que verifica que todo funciona igual en el tuyo y vigila el tamaño final.
- Instala solo desde las fuentes oficiales: hay muchas copias del repositorio, y el proyecto pide usar siempre qybaihe/bla o el paquete bla-agents. En el caso de REA, la fuente oficial es github.com/morluto/rea.
- Analiza solo lo que tengas permiso para analizar: el propio planteamiento de REA parte de trabajar con programas autorizados.
En resumen
La ingeniería inversa con IA es ya una realidad práctica gracias a herramientas como REA, aunque no es tan automática ni tan sencilla como a veces se cuenta. BLA responde con una idea original: dejar el código a la vista, pero sembrado de señuelos que hagan que la IA gaste más, se equivoque y saque conclusiones falsas. Su enfoque es interesante, pero sus cifras más llamativas son estimaciones propias sin verificación independiente, su protección es económica y no absoluta, y no sustituye a las buenas prácticas de siempre, como mantener los secretos fuera del programa que se distribuye.
Fuentes
- GitHub: qybaihe/bla (repositorio oficial de BLA)
- bla.tools (web oficial de BLA)
- GitHub: morluto/rea (repositorio oficial de REA)
- Buttondown: Reverse Engineer Anything (REA) on GitHub: How Far It Goes
- PiyushAI: REA (Reverse Engineer Anything) Explained
- i10x: BLA (Blind LLM Agents) vs. REA
- GitHot: qybaihe/bla
- AICoder: debate sobre BLA en X
- ExplainX: BLA Blind LLM Agents, 612x Token Claim, Checked
- Review Ramble: reseña de BLA
- Starlog: BLA, The First Adversarial Defense System Built to Bankrupt AI Reverse Engineering
