Sala limpia frente a ingeniería inversa: cómo se usó la IA para reproducir software propietario

Anteriormente escribí sobre cómo se usó la IA para reproducir productos de software de Microsoft, Adobe y AutoCAD mediante un método supuestamente legal conocido como implementación en sala limpia (clean room). Aquí quiero profundizar un poco en lo que eso significa en comparación con simplemente hacerle ingeniería inversa a un programa.

Ingeniería inversaing

La ingeniería inversa es el proceso de analizar un programa compilado (un binario .exe), casi siempre sin acceso a su código fuente original ni a sus documentos de diseño, para entender cómo funciona, cuál es su arquitectura y cómo fluyen sus datos. Esta práctica permite comprender a fondo cómo se desarrolló el software, incluidos los algoritmos protegidos por propiedad intelectual que se hayan utilizado y otras técnicas de optimización. En última instancia, se puede trabajar hacia atrás de forma metódica hasta poder escribir un código fuente que, al compilarse, genere un ejecutable casi idéntico al original. Con el código fuente en la mano, es posible portar el software a otras arquitecturas y sistemas operativos, agregarle nuevas funciones, etcétera. Más adelante veremos por qué alguien querría hacer esto.

Esta práctica no se limita al software; existe desde que la humanidad fabrica herramientas. Uno de los ejemplos más antiguos que se conocen ocurrió durante la Primera Guerra Púnica (264 a. C. – 241 a. C.). Al inicio de la guerra, la República romana no contaba con una armada permanente. Los romanos capturaron un quinquerreme cartaginés (un tipo de buque de guerra), lo desarmaron pieza por pieza, midieron sus componentes y lo usaron como modelo para construir su propia flota de unos 300 barcos en solo tres meses. La ingeniería inversa es una práctica común en todas las industrias.

Podría parecer que la razón principal para hacerle ingeniería inversa a un software es robarse ilegalmente el producto de un competidor, y eso sin duda pasa. Pero en realidad hay muchas razones para hacerlo con bases legales más sólidas.

La primera es el análisis de malware. La mayoría estamos acostumbrados a recibir software e instalarlo a ciegas en el celular o la computadora sin pensar mucho en qué tan seguro es. Confiamos en las fuentes (Apple o Microsoft, por ejemplo) y suponemos que lo que nos dan es legítimo. Sin embargo, hay muchos administradores de sistemas que necesitan, de forma crítica, asegurarse de que el software que se instala en sus equipos no tenga intenciones maliciosas. La ingeniería inversa es una forma de descubrir amenazas ocultas.

Además del análisis de malware, se buscan otras vulnerabilidades ocultas. Estas no necesariamente existen por mala intención; incluyen errores (bugs) u otras fallas de diseño o de algoritmos que dejan un sistema expuesto a otros ataques.

Las empresas de software de terceros, como las que desarrollan plug-ins u otros complementos para programas existentes, a menudo le hacen ingeniería inversa a los binarios. Pensemos, por ejemplo, en una empresa como NIK, que fabrica filtros para Adobe Photoshop. Es posible que le hagan ingeniería inversa a Photoshop para conocer las estructuras de archivo que usa para abrir y cerrar imágenes, entre otras cosas, con el fin de lograr compatibilidad. Según la jurisprudencia actual de Estados Unidos, esta forma de ingeniería inversa se considera “uso justo” (fair use). Véase Sega Enterprises Ltd. v. Accolade, Inc. (977 F.2d 1510), 1992, USA.

La modernización de sistemas heredados (legacy) es otra razón. A veces una empresa tiene un ejecutable antiguo que ya no funciona en un sistema nuevo y cuyo código fuente quizá ya ni exista. Recurre a la ingeniería inversa para entender cómo se creó el código original y así poder modificarlo o actualizarlo según sus necesidades futuras.

Por último, y esta lista no es para nada exhaustiva, una de las mejores razones para hacerle ingeniería inversa a un software es simplemente aprender nuevas habilidades y técnicas de programación.

La doctrina de sala limpia y la “muralla china”e and the Chinese Wall

Supongamos por ahora que el objetivo es reproducir, con la mayor precisión posible, el producto de software de un competidor y luego ponerlo a disposición de otros (gratis o no). Usar la ingeniería inversa para copiar exactamente la implementación y la funcionalidad del código es, en gran medida, ilegal en la mayoría de las jurisdicciones. Para empezar, constituye una violación de derechos de autor y un robo de propiedad intelectual. Puede implicar múltiples violaciones de patentes. Si el software copiado se obtuvo legalmente, lo más probable es que hayas aceptado unos Términos de Servicio (ToS) antes de poder instalarlo o ejecutarlo. Muchos de estos acuerdos estipulan que el software no puede someterse a ingeniería inversa. (La legalidad de estos acuerdos es un tema que merece su propia discusión). Romper los Términos de Servicio constituye un incumplimiento de contrato. Finalmente, la Ley de Derechos de Autor de la Era Digital (DMCA) de 1998 introdujo muchos matices en este terreno. Hacerle ingeniería inversa a un producto para sacar tu propia versión y hacerla pasar como tuya te metería en un problemón.

Para mitigar estos riesgos de infracción, la industria tecnológica desarrolló la metodología de “sala limpia” o “muralla china”. La ingeniería en sala limpia no es realmente una alternativa a la ingeniería inversa, sino un marco de trabajo disciplinado que separa el análisis técnico de un producto de software de la escritura de una nueva implementación, mediante una división organizacional hermética.

Les doy uno de los ejemplos más conocidos. Cuando IBM lanzó su primera computadora personal, dominaba el mercado. Aunque las máquinas usaban hardware existente que cualquiera podía comprar y ensamblar para fabricar sus propios clones de IBM (como se les llegaría a llamar), la pieza de software crucial que hacía que todo funcionara era el BIOS (Sistema Básico de Entrada/Salida), almacenado en un chip que la computadora lee primero al encenderse. El BIOS le indica a la computadora todo lo que necesita saber para acceder al resto del hardware y empezar a trabajar. En junio de 1982, una empresa llamada Columbia Data Products lanzó su propio BIOS, que duplicaba la funcionalidad del BIOS de IBM, pero cuyos ingenieros de software nunca vieron el ejecutable del BIOS de IBM. Aunque fue impugnado en los tribunales, se determinó que era legal. ¿Cómo lo lograron?

Una implementación en sala limpia divide el trabajo en dos equipos completamente separados: el equipo “sucio” y el equipo “limpio”. El equipo sucio trabaja directamente con el software objetivo. Estos ingenieros desensamblan los binarios, interceptan señales de hardware, analizan trazas de protocolos y mapean las relaciones entre entradas y salidas. Sin embargo, tienen estrictamente prohibido escribir código de producción para el producto de reemplazo.

En cambio, el único entregable del equipo sucio es una especificación funcional. Se trata de un documento exhaustivo y neutral que describe qué hace el software. Está completamente despojado de cualquier expresión propietaria que detalle cómo fue escrito, lo cual podría incluir algoritmos patentados, entre otras cosas. Esta especificación define entradas, transiciones de estado válidas, condiciones de error, códigos de retorno y comportamientos en casos límite, usando descripciones abstractas, fórmulas matemáticas o lenguajes formales de definición de interfaces.

Luego, el equipo limpio recibe esta especificación funcional y se encarga de escribir una implementación de software a partir de ella. Este equipo está formado exclusivamente por desarrolladores que nunca tuvieron acceso al binario del sistema objetivo, a código descompilado ni a documentación técnica propietaria. Nadie del equipo limpio puede haber tenido contacto con los integrantes del equipo sucio. Si un ingeniero de la sala limpia se topa con un requisito ambiguo o un caso límite inesperado, no inspecciona el software objetivo por su cuenta; envía una consulta formal al otro lado de la barrera. El equipo sucio verifica el comportamiento en el sistema objetivo y actualiza la especificación en consecuencia.

La idea es que el equipo limpio simplemente produce software basado en un documento que le entregaron y que describe, en lenguaje no propietario, lo que el software debe hacer. En general, los tribunales han determinado que este método está libre de los problemas legales inherentes a la ingeniería inversa simple.

La IA entra en escena

Espero que ahora entiendan el proceso de ingeniería inversa y lo que significa una implementación en sala limpia. Ahora podemos empezar a hablar, a grandes rasgos, de lo que hizo ArtCraft para reproducir los productos de software de algunos de los proveedores más grandes del mundo.

Básicamente, ArtCraft construyó un sistema compuesto por un equipo sucio y un equipo limpio, formados en su totalidad por agentes de IA. 

Los agentes de IA del equipo sucio tuvieron acceso a herramientas para examinar binarios existentes. Por razones legales, el equipo de ArtCraft decidió aplicar estrictamente la regla de que ningún binario podía descompilarse ni desensamblarse de ninguna forma. En su lugar, se alimentó al sistema con todos los documentos públicos disponibles sobre el software, como especificaciones de API, estructuras de archivos, etc. Un ejemplo sería un documento que Adobe ofrece libremente y que describe la estructura de sus archivos de imagen PSD.

Los agentes sucios también tuvieron acceso al software que se iba a examinar. La forma de explorarlo fue hacer que estos agentes actuaran como personas usando el software, probando cada función y opción de menú publicada solo para ver qué efecto tenía. Tenían acceso total al sistema donde corría el software y podían emular todas las combinaciones de teclas, movimientos y clics del mouse conocidos. Podían ver cómo el software interactuaba con la máquina y cómo se abrían, generaban o cerraban archivos. Como no son humanos, no necesitan dormir y operan a velocidades electrónicas, lograron determinar por completo lo que podía hacer un programa en cuestión de horas. Los resultados se pasaban a otros agentes del equipo sucio encargados de redactar la especificación que un programador tradicional usaría para empezar a escribir el software.

El equipo limpio estaba formado por agentes de IA que usaban Claude Opus 5.5 de Anthropic para leer el documento de especificación y escribir todo el código nuevo exclusivamente en el lenguaje de programación Rust, de modo que compilara y se comportara exactamente según lo especificado. Estos agentes de IA nunca examinaron el software original.

El sistema también incluye un ciclo de retroalimentación que compila el código en Rust y somete el nuevo software al mismo proceso que se usó con el software propietario. De esto se encargan los agentes sucios, que crearon un arnés de pruebas (test harness): un conjunto de tareas que el nuevo software debe superar para verificar su compatibilidad. Una tarea, por ejemplo, podría ser aplicar un filtro de imagen a un archivo, tanto con el nuevo software como con Photoshop de Adobe, y verificar que los archivos resultantes coincidan byte por byte. Si la prueba falla, los agentes sucios averiguan por qué y agregan nueva información a la especificación para resolverlo. De nuevo, gracias a la velocidad con la que funciona este sistema, todo esto ocurre en poco tiempo.

El resultado final, tras varias iteraciones del ciclo de retroalimentación, es un código que compila y se ejecuta, y que se ve y se comporta casi igual que el software propietario. Esto es lo que ArtCraft ya hizo con toda la línea de productos de Adobe, la suite Office 365 de Microsoft y el famoso software CAD de AutoCAD. La calidad no es perfecta: la mayoría de los usuarios y probadores (yo incluido) la consideran de calidad alfa. Sin embargo, hay suficiente material para que una comunidad más amplia de desarrolladores de código abierto la pula rápidamente, corrija problemas y agregue las funciones necesarias. Desde mi punto de vista personal, la mayor ventaja es que todos estos paquetes compilan y corren en Linux, lo que me da una forma completamente nueva de aprovechar hardware viejo, como mi MacBook Pro de Apple de 2016. Apple ya no le da soporte a la MBP con actualizaciones de software ni de seguridad, pero puedo correr Linux en ella sin problema. También tengo una computadora de escritorio con Linux que armé por menos de 600 dólares (USD) y que compite con lo que puede hacer una Apple M6 Mini nueva, que cuesta más de 2,000 dólares. Poder correr en ella software (incluso gratuito) que antes solo existía para macOS o Windows es una bendición.

Límites técnicos y controversias legalesversies

Aunque la velocidad técnica del proyecto no tiene precedentes (llevar siete aplicaciones distintas a fase alfa en cuestión de semanas), la estrategia de implementación en sala limpia enfrenta un escepticismo considerable. He visto algunos videos de YouTube de expertos legales y técnicos que tocan varios puntos importantes que deben atenderse.

• The La muralla china: Como el código lo escribió un LLM, es imposible verificar de forma independiente a qué datos propietarios o código fuente estuvo expuesto el modelo durante su entrenamiento base. Esto se ha mitigado en parte porque ArtCraft publicó otro proyecto de código: el conjunto completo de herramientas de IA que usaron, para que cualquiera que quiera hacer un trabajo similar con otro software pueda hacerlo. Esto también permite que cualquiera examine a detalle su configuración de sala limpia.
• Violación de los Términos de Servicio: ¿Recuerdan que antes mencioné que hay que aceptar los Términos de Servicio de un proveedor para instalar o usar su software? Aunque se evite la infracción de derechos de autor gracias a la sala limpia, analizar software comercial para extraer su comportamiento normalmente viola los Términos de Servicio y los EULA (Acuerdos de Licencia de Usuario Final) estándar. Este podría ser el camino que tome la industria para combatir a ArtCraft y a otros. Hasta ahora, según mi investigación, no existe una resolución judicial clara que haya hecho valer las cláusulas de estos acuerdos que prohíben la ingeniería inversa. Esas cláusulas, por ejemplo, prohibirían métodos de uso justo que los tribunales ya determinaron que son legales.
• Infracción de derechos de autor y marcas registradas: Aunque todo lo demás quede libre de problemas legales, podrían existir estas otras infracciones. Los íconos y los textos usados en los mensajes internos y en los menús de ayuda pueden formar parte de la propiedad intelectual (PI) del software. Los desarrolladores de ArtCraft tienen que revisar esto con lupa y reemplazar el contenido donde sea necesario.