Poisoned Identifiers Survive LLM Deobfuscation: A Case Study on Claude Opus 4.6

1. El Problema

El estudio investiga un fenómeno crítico en la seguridad del código asistido por Inteligencia Artificial: ¿Pueden los nombres de identificadores "envenenados" (maliciosos o incorrectos) presentes en una tabla de cadenas de código ofuscado sobrevivir en el código reconstruido por un Modelo de Lenguaje Grande (LLM), incluso cuando el modelo demuestra comprender correctamente la semántica subyacente?

El escenario específico implica:

• Código Ofuscado: JavaScript con nombres de variables manipulados (ej. attraction en lugar de repulsion, amplification en lugar de damping).
• La Tarea: Deobfuscación (reconstrucción del código legible).
• La Paradoja: El modelo genera comentarios correctos describiendo la operación física real, pero utiliza los nombres de variables incorrectos en el bloque de código.
• Fallo de las Instrucciones Explícitas: Las instrucciones directas para "verificar que los nombres coincidan con las matemáticas" no logran prevenir la propagación de estos errores.

2. Metodología

El estudio se divide en dos fases principales, utilizando dos arquetipos de código: una simulación de gráfico de fuerza dirigida (física) y un algoritmo de búsqueda de ruta A*.

• Modelos Probados: Principalmente Claude Opus 4.6 (con 1M de contexto) y verificaciones limitadas con Claude Haiku 4.5.
• Fase A (Exploratoria): 28 ejecuciones manuales en la interfaz de línea de comandos de Claude Code (con uso de herramientas). Objetivo: Generar hipótesis.
• Fase B (Sistemática): 192 ejecuciones automatizadas vía API de Anthropic Messages (sin uso de herramientas).
  • Muestra: 50 condiciones diferentes, con 3 a 6 repeticiones por condición.
  • Estímulos ("Pills"): Se utilizaron 50 variantes de código ofuscado, incluyendo:
    • Nombres envenenados semánticamente plausibles (dentro del dominio de física).
    • Nombres envenenados con cero ajuste semántico (ej. usar "combustión" para una fuerza de repulsión) para probar la coherencia del dominio.
    • Controles de malware real para medir tasas de rechazo.
• Métricas:
  • Endpoint Primario: Preservación de identificadores envenenados en bloques de código.
  • Endpoint Secundario: Detección del patrón de "doble representación" (nombre incorrecto en código + descripción correcta en comentarios).
  • Marcos de Tarea: Se compararon tres enfoques: "Deobfuscar esto" (traducción), "Reescribir con nombres correctos" y "Escribir una implementación fresca desde cero" (generación).

3. Contribuciones Clave

1. Descubrimiento del Patrón de Doble Representación: Demostraron que los LLMs pueden mantener una comprensión semántica correcta (en comentarios) mientras propagan errores léxicos en el código ejecutable.
2. Ineficacia de la Verificación Explícita: Se demostró que las instrucciones de verificación explícitas ("verifica cada nombre contra las matemáticas") son ineficaces para corregir identificadores envenenados en un contexto de deobfuscación (12/12 fallos).
3. El Efecto del Enmarcado de la Tarea (Task Framing): Se identificó que cambiar el marco de la tarea de "traducción/deobfuscación" a "generación desde cero" reduce drásticamente la propagación de errores, sugiriendo que el modo de trabajo del modelo (traducción vs. creación) es más determinante que las instrucciones de seguridad.
4. Coherencia del Dominio vs. Ajuste Semántico Individual: Se descubrió que la persistencia de nombres incorrectos no depende tanto del ajuste semántico individual de una palabra, sino de si la tabla de cadenas completa forma un dominio coherente alternativo. Si la tabla es incoherente, el modelo tiende a preservar los nombres originales (envenenados) en lugar de inferir nuevos.

4. Resultados Principales

• Persistencia en Línea Base: En el marco de "deobfuscar", los identificadores envenenados aparecieron en el 100% de las ejecuciones de prueba (8/8 en física, 5/5 en pathfinding).
• Doble Representación: En 15 de 17 ejecuciones exitosas (donde hubo propagación), el modelo escribió el nombre incorrecto en el código pero lo describió correctamente en los comentarios (ej. attraction: 4000 con el comentario // Fuerza de repulsión).
• Impacto del Enmarcado (Framing):
  • Al cambiar la instrucción a "Escribir una implementación fresca desde cero", la propagación de errores en el artefacto de física cayó del 100% al 20%, y en el algoritmo de pathfinding se eliminó por completo (0%).
  • La estructura algorítmica verificada se mantuvo intacta en todos los casos de generación exitosa.
• Nombres sin Ajuste Semántico: Incluso términos que no tienen sentido en absoluto (ej. "factura" para una heurística de pathfinding) persistieron al mismo ritmo que los términos plausibles si la tabla de cadenas no formaba un dominio coherente alternativo.
• Efecto de la Temperatura: A temperatura 0, la propagación fue determinista (100%), confirmando que no es un artefacto de muestreo aleatorio.
• Rechazo vs. Deobfuscación: El modelo rechazó código con lógica de malware real, pero entró en "modo forense" y deobfuscó completamente el código si el malware estaba ofuscado, revelando los nombres envenenados.

5. Significado e Implicaciones

• Multiplicador de Costos, no Protección: La ofuscación con identificadores envenenados no oculta el código de un atacante determinado, pero actúa como un multiplicador de costos para el análisis asistido por LLM. Obliga a los ingenieros a realizar una verificación manual o a reescribir el código desde cero para corregir los errores.
• Fallo de las Instrucciones de Seguridad: Las técnicas actuales de "prompt engineering" que se basan en pedir al modelo que verifique su propio trabajo son insuficientes para este tipo específico de ataque.
• Recomendación Práctica: Para flujos de trabajo de análisis de código asistidos por IA, se recomienda utilizar un marco de generación ("reimplementa esto desde cero") en lugar de un marco de traducción ("deobfuscar esto") para mitigar la propagación de identificadores envenenados.
• Limitaciones: El estudio se centró en dos arquetipos de código y un modelo específico (Opus 4.6). Se requiere más investigación para generalizar estos hallazgos a otros modelos (GPT-4o, Gemini) y tipos de código.

Conclusión Final:
El estudio revela una vulnerabilidad sutil donde la "traducción" de código ofuscado prioriza la fidelidad léxica de la tabla de cadenas decodificada sobre la inferencia semántica, incluso cuando el modelo sabe la verdad. La única mitigación efectiva encontrada fue cambiar fundamentalmente la naturaleza de la tarea de "traducción" a "generación", lo que sugiere que la arquitectura cognitiva del modelo responde más al marco de la tarea que a las instrucciones de verificación explícitas.