Suelta un build ofuscado a un LLM para ver si recupera sus secretos

Un desarrollador cogió su propia compilación endurecida, con las cadenas legibles eliminadas y los valores de configuración cifrados, y se la entregó a un LLM frontera para ver si el modelo era capaz de reconstruir los secretos que la aplicación descifra por sí sola. Según su propio relato, el resultado no es lo que cuenta: lo interesante fue montar un tribunal adversarial de agentes para auditar la investigación del modelo.

El punto de partida es una premisa que él mismo mete en el modelo de amenaza: la clave maestra viaja dentro del binario. La aplicación necesita descodificar sus valores, así que el artefacto contiene lo necesario para hacerlo. Un ingeniero inverso con paciencia puede dar con esa clave, entender la derivación y reproducir el descifrado. El endurecimiento no busca hacerlo imposible, sino subir el coste. Llamarlo protección criptográfica escondería la pregunta que sí se puede investigar: dado el build, ¿alguien puede encontrar y usar el material que ya está dentro?

Cómo está montado el cifrado

Los valores de configuración van en XOR. Cada uno usa una clave derivada en tiempo de ejecución a partir de una única clave maestra de 32 bytes. Esas claves de trabajo no se guardan en reposo dentro del binario. Invertir XOR es trivial cuando tienes los bytes de la clave correspondiente, así que la dificultad está en el descubrimiento: reconocer qué arrays contienen valores cifrados, localizar la clave maestra y atar esa clave a la derivación y al código de descifrado.

Sin cadenas legibles, el investigador se queda sin su punto de partida fácil. Los valores cifrados aparecen como literales de arrays de bytes que parecen hashes, y ningún fragmento del binario se lee como una clave. Además, la derivación elimina los prefijos compartidos: dos secretos parecidos no producen salidas parecidas. Eso corta un atajo habitual, que es agrupar valores que se parecen, deducir que comparten propósito y buscar después el código que los consume.

Hay un coste de implementación. La derivación vive en tres sitios independientes —el runtime de la aplicación, una herramienta de compilación y un script de build nativo— escritos en tres lenguajes distintos, y los tres tienen que coincidir byte a byte. Si divergen, la aplicación no descifra nada.

El tribunal de agentes

Para la parte de investigación usó varios agentes organizados como una sala adversarial. Tres investigadores neutrales recogen hechos por separado: uno mira código, permisos y patrones de ofuscación; otro, red y datos; el tercero, librerías y comportamiento. Luego un fiscal defiende los hallazgos con sesgo hacia encontrar problemas, un abogado defensor rebate esas interpretaciones y aporta explicaciones benignas, y un juez imparcial decide qué conclusiones tienen respaldo suficiente. La separación importa porque un único prompt de análisis tiende a dejar que una interpretación domine y que las observaciones siguientes se acomoden a ella.

El autor es explícito en un límite: esto no convierte a los agentes en fuentes independientes de verdad. Tampoco presenta una demostración pública del montaje, solo el relato de su propio build y de cómo lo interrogó.

Para quien despliega lógica en el cliente, el recordatorio es el de siempre: ofuscar encarece el trabajo del atacante, no lo elimina, y lo que viaja dentro del artefacto se puede acabar recuperando. Lo que aporta este experimento es el método de revisión: separar en roles opuestos la búsqueda de evidencia, la acusación y la defensa antes de dar por buena una conclusión sobre un binario opaco.