A diferencia del proceso de ingeniería tradicional, que va desde el diseño hasta la creación final de un producto, la ingeniería inversa parte del objeto terminado para "desmantelarlo" analíticamente y obtener su diseño o lógica subyacente. En el análisis de software se utiliza para estudiar el código de programas, detectar vulnerabilidades de seguridad, entender protocolos cerrados o mejorar la compatibilidad entre sistemas. En hardware, permite aplicar la misma lógica a objetos físicos.
En qué consiste y por qué se usa
Pensalo así: es como tratar de replicar la receta de una torta sin acceso al recetario del pastelero. No se puede entrar a la cocina, no se puede leer el cuaderno de recetas. Solo se puede probar la torta terminada, mirar su textura, oler sus ingredientes, cortarla en capas y, a partir de ahí, deducir qué lleva adentro y en qué orden se mezcló. Eso es la ingeniería inversa aplicada al software: mirar un programa desde afuera para entender cómo funciona por dentro, sin ver su código.
Se usa cuando se hereda un proyecto sin documentación, cuando el software es cerrado o cuando se quiere construir una versión alternativa que haga lo mismo. "Está pensada para cuando no querés ver el código o no tenés acceso a ese código. Como por ejemplo cuando heredás un proyecto y querés entender cómo funciona, problemas que tiene, vulnerabilidades y entender todo el funcionamiento", explicó a El Observador Franco Galeano, programador de la empresa Metria.
Para Espino, la práctica no es ninguna novedad. "El uso de ingeniería inversa no es algo nuevo, no es algo novedoso y siempre se ha hecho en todos los procesos de ingeniería, de desarrollo", apuntó. Y suele aparecer cuando "uno tiene una determinada aplicación que no le conforma su funcionamiento o directamente la aplicación es a veces de código cerrado y uno quiere implementar una funcionalidad o una versión de código abierto que sea mantenible y que pueda replicar de cierta forma el funcionamiento que hace esa otra aplicación". El ingeniero fue más allá: "Todas las aplicaciones que son versiones de código abierto de aplicaciones de código cerrado trabajan de esa forma, cuando no tienen esa información".
El método es siempre el mismo y vuelve a la metáfora de la torta: se le mete algo y se mira qué sale. Si al batir claras con azúcar se obtiene merengue, se anota. Si al hornear a 180° durante 40 minutos se logra una miga esponjosa, también. "Generalmente se mira desde afuera el comportamiento: se usa el software, se prueban entradas y se anota qué sale. Esto se puede hacer con IA", detalló a El Observador Fabricio González, ingeniero y desarrollador en inteligencia artificial. En los casos más avanzados, agregó, "se intercepta la comunicación: se mira qué datos viajan por red, archivos o puertos" –el equivalente a espiar qué entra y qué sale de la cocina mientras se cocina la torta–.
Espino lo describió como un trabajo artesanal de caja cerrada. "El proceso siempre es de caja cerrada. Es una tarea muy artesanal. Uno va haciendo una prueba, sabe cuál es la función, le brinda un input y recibe un output, pero no sabe cómo se procesó adentro para recibir ese output", explicó. A partir de ahí, dijo, "uno tiene que empezar a indagar, ya sea por resultados intermedios o ya sea por logs que van quedando en otras partes de esa otra aplicación, para llegar a cómo se hace el razonamiento y generar una versión propia". Es la misma lógica del pastelero amateur que raspa el molde, prueba la miga del borde y revisa la basura buscando envoltorios para saber qué marca de chocolate se usó.
Galeano completó esa idea desde el ángulo del método: "¿Cómo se hace ese entendimiento? Con entrada-salida. Si yo hago esto, cómo funciona, cómo reacciona, qué procesos te dan".
Lo que se busca en ese análisis se concentra, según González, en cuatro frentes. El primero son los datos que intercambia el sistema –"protocolos, formatos de archivo"– para lograr compatibilidad. El segundo es el comportamiento: "qué hace ante cada interacción del usuario". El tercero son las funciones: "qué operaciones internas existen. Esto es en términos de código y se ve al desensamblar". Y el cuarto es la interfaz, que según el especialista "es lo más visible, pero lo menos útil para entender cómo funciona por dentro" –el glaseado de la torta: lindo de ver, poco útil para saber qué hay abajo–.
Aplicada al software nuevo, esa lógica permite –según Galeano– "crear un programa compatible con otro sin la necesidad de copiar el código". Y el programador remarcó la premisa de la disciplina: "Esa es la gracia de la ingeniería inversa: que no sabés cómo se hizo, no sabés cómo está ese código".
Los motivos para hacerlo son variados, según detalló González: lograr compatibilidad entre sistemas –"hacer que tu programa lea los archivos o hable con otro sistema, por ejemplo Samba con los protocolos de Windows"–, reemplazar sistemas viejos –"se perdió el código fuente o ya no hay soporte, pero hay que migrar"–, construir emuladores –"imita una consola o un sistema viejo, Windows 95 ponele"– o analizar seguridad: "analizar malware o buscar vulnerabilidades. Acá el objetivo no es crear software nuevo".
Cómo la IA cambió la ecuación
El uso de ingeniería inversa en combinación con IA es, según Galeano, una tendencia creciente entre empresas con productos de larga trayectoria que no fueron construidos con inteligencia artificial. "No se tiene acceso al código de cómo se hace, pero empresas grandes que ya tienen producto hecho hace años no lo tenían hecho con inteligencia artificial. Como ya se sabe más o menos la entrada, la salida, se prueban esos flujos, se rehacen esos sistemas pero con las herramientas que hay hoy en día, haciéndolos medio AI-native a todos esos procesos", explicó el cofundador de Metria.
Espino lo graficó con el cambio de método. "Este proceso cambió radicalmente con la incorporación de la inteligencia artificial porque uno antes tenía que hacer ese razonamiento por sí solo y tenía que hacer esas pruebas manualmente a veces, o semiautomatizadas", apuntó. Y agregó: "Hoy por hoy puede ir razonando junto con la inteligencia artificial; la inteligencia artificial ejecuta ciertas pruebas o inclusive puede sugerir otras pruebas más para poder tener más información y, de esa forma, poder llegar a replicar la funcionalidad en una versión trabajada en conjunto".
Antes de la irrupción de la IA, buena parte de este trabajo se resolvía con patrones de ingeniería como el Adapter, que –según detalló Galeano– "hace que una salida se adapte a la entrada de otro programa". La IA generativa movió esa frontera. "Mediante la inteligencia artificial, la gente ya no usa tanto esos patrones, sino que va o rehace ese código desde cero y hace un programa nuevo sin la necesidad de reutilizar algo viejo que no se tiene tanto contexto ni nada, sino lo hace de cero con ingeniería inversa", señaló el programador de Metria. El patrón Adapter, dijo, queda reservado para los casos en que reconstruir el sistema desde cero sería demasiado riesgoso por un posible problema futuro.
Dónde está el límite legal
La reconstrucción puede acercarse mucho al original, pero –según Espino– rara vez lo iguala. "Teóricamente sí, podés llegar. A veces lo que termina pasando es que te vas a ir acercando lo más posible a esa funcionalidad", apuntó. Puso como ejemplo a LibreOffice y Office 365: ambas suites generan archivos .doc, un formato cerrado de Microsoft. "Lo que hizo LibreOffice para poder llegar a eso fue hacer un trabajo de ingeniería inversa para llegar a un archivo que es compatible con lo que puede generar Office oficial, el Office de Microsoft", relató. El código, aclaró, "definitivamente es diferente al código que se utiliza para implementar Microsoft Office".
Ahí aparece el punto más delicado de la disciplina. "Se puede hacer una cosa compatible, se puede llegar a una funcionalidad bastante similar y en esos casos no son códigos copiados. El límite ahí es más legal que otra cosa", sostuvo Espino. Y detalló cómo se evalúa un plagio en el desarrollo: "El que termina evaluando si una aplicación es plagio de la otra no es específicamente la funcionalidad, sino es si efectivamente el código es exactamente igual". Esos chequeos –explicó– "se hacen a partir de la verificación de si línea a línea coincide el código". Y advirtió: "No necesariamente tiene que estar letra por letra el espacio en el mismo lugar, sino que inclusive si está desorganizado las funciones y el código de esas funciones es el mismo, también es plagio".
El ingeniero resumió el criterio que, a su juicio, define la frontera entre inspiración y copia. "Si uno hackeó, por decir algo, los servidores de Microsoft, se llevó el código y después lo publicó como el Office más grande del mundo, obviamente que es una copia. Pero una implementación no deja de ser un ejercicio creativo y si por dos caminos distintos se puede llegar a la misma solución, no se puede decir que son copias; son simplemente dos versiones diferentes", afirmó.
Las empresas de IA empezaron a mover sus propias fichas para no quedar en el centro de ese debate. Anthropic, la compañía detrás de Claude, actualizó su asistente de código para que no copie el estilo original de los videojuegos, un cambio que apunta a frenar el uso de esta inteligencia artificial para "infringir propiedad intelectual".
La firma introdujo líneas de código que limitan las acciones del modelo cuando se trata de videojuegos originales, es decir, que restringen el uso de la IA para la creación de otros videojuegos o modificaciones basadas en determinados títulos.
El cambio lo confirmó Addy Osmani, un empleado de Claude Code en Anthropic, en un breve mensaje en la red social X: "Añadimos dos frases al prompt de Claude Code en Opus 5.5 para alejarlo de recrear el juego específico de otra persona, porque usar Claude para infringir propiedad intelectual va en contra de nuestra política de uso".
