Resumen Técnico: CrackMeBench

Declaración del Problema

Las evaluaciones actuales para agentes de modelos de lenguaje se centran predominantemente en la síntesis de código fuente (por ejemplo, HumanEval, SWE-bench) o en el rendimiento amplio de capturar la bandera (CTF) en ciberseguridad (por ejemplo, CyberSecEval, Cybench). Sin embargo, la ingeniería inversa de binarios permanece subespecificada en el contexto de agentes autónomos. Específicamente, existe una falta de evaluación precisa sobre si un agente, dado únicamente un ejecutable compilado, puede recuperar la lógica de validación y producir una entrada válida (contraseña, serie, artefacto o generador de claves) aceptada por ese programa.

La ingeniería inversa de binarios pone a prueba capacidades distintas en comparación con la codificación a nivel de fuente: los agentes deben clasificar formatos de archivo, razonar sobre código despojado o pobre en símbolos, determinar la confiabilidad de la salida del descompilador, formular hipótesis dinámicamente e invertir transformaciones no diseñadas para la legibilidad. A diferencia de la reparación de código fuente, los agentes no pueden confiar en nombres semánticos o pruebas de repositorio; a diferencia de los CTF amplios, el objetivo puede reducirse a un problema de validación determinista.

Metodología: CrackMeBench

Los autores presentan CrackMeBench, una evaluación diseñada para evaluar agentes de modelos de lenguaje en tareas de ingeniería inversa de estilo CrackMe con fines educativos. El marco se basa en un modelo de evaluación de oráculo ejecutable, donde el éxito se define por la aceptación de una solución candidata por parte del programa, en lugar de la plausibilidad de una explicación textual.

Diseño de la Evaluación e Inventario de Tareas

La evaluación v0 consta de 20 tareas divididas en dos conjuntos:

1. Calibración Pública (8 tareas): Binarios sanitizados de desafíos educativos CrackMe públicos (por ejemplo, Enigma CrackMe, SirCrackaLot). Estos sirven como comprobaciones de validez externa pero se tratan como datos de calibración debido a la posible fuga de soluciones en informes públicos.
2. Puntuación Principal Generada (12 tareas): Tareas construidas a partir de plantillas semilladas en C, Rust y Go. Estas se dividen además en:
   • Núcleo (6 tareas): Se centran en la recuperación literal, codificaciones reversibles, restricciones aritméticas, generadores de claves simples y anti-depuración benigna.
   • Difícil (6 tareas): Introducen predicados opacos, validadores descifrados en tiempo de ejecución, artefactos criptográficos de juguete, razonamiento de sumas de verificación y ruido en tiempo de ejecución de Rust/Go.

Entorno de Ejecución y Protocolo

• Sandbox: Los agentes operan en un contenedor Docker de Linux sin acceso a red.
• Sistema de archivos:
  • /task (Solo lectura): Contiene el binario del desafío, metadatos y documentos públicos.
  • /work (Lectura-Escritura): El directorio de trabajo del agente para scripts y envíos.
  • /harness (Solo lectura): Contiene comandos de ayuda (list_tools, submit) y el manifiesto de herramientas.
• Acceso a herramientas: La lista exacta de herramientas instaladas (clasificación estática, desensamblado, depuración, ejecución simbólica y herramientas de compilación) se inyecta explícitamente en el prompt mediante un manifiesto JSON, evitando la dependencia de priores del modelo.
• Esquema de envío: Los agentes deben enviar un objeto JSON especificando una password, una ruta de artifact o una ruta de script keygen.
  • Para las tareas keygen, el script enviado se ejecuta contra nombres de usuario ocultos para verificar la generalización, evitando soluciones codificadas.
• Puntuación: Un oráculo privado fuera del espacio de trabajo del agente valida los envíos contra el binario original. Las métricas incluyen pass@1 y pass@3 (éxito en 1 o 3 intentos), tiempo de reloj, uso de tokens y trazas de comandos.

Configuración de la Evaluación

La evaluación v0 probó tres modelos con un presupuesto de tiempo de 5 minutos y un máximo de tres envíos puntuables por tarea:

• GPT-5.5 (vía Azure OpenAI)
• Claude Opus 4.7
• Kimi K2

Resultados Clave

La evaluación destaca un gradiente de rendimiento agudo basado en la dificultad de la tarea y la capacidad del modelo:

Tareas Generadas (Puntuación Principal):

• GPT-5.5: Logró un 92% de pass@3 (11/12 tareas). Resolvió las 6 tareas de núcleo y 5/6 tareas difíciles (fallando solo en la tarea de serie de Rust).
• Claude Opus 4.7: Logró un 58% de pass@3 (7/12 tareas). Resolvió 5/6 tareas de núcleo y 2/6 tareas difíciles.
• Kimi K2: Logró un 42% de pass@3 (5/12 tareas). Resolvió 4/6 tareas de núcleo y solo 1/6 tareas difíciles.

Tareas de Calibración Pública:
El rendimiento disminuyó significativamente en todos los modelos en el conjunto público, probablemente debido a un ruido de implementación más rico y convenciones desconocidas:

• GPT-5.5: 3/8 (38%)
• Claude Opus 4.7: 2/8 (25%)
• Kimi K2: 1/8 (12%)

Observaciones Cualitativas:

• Brechas Operativas vs. Semánticas: El modo de fallo principal para los modelos de menor rango no fue necesariamente una falta de comprensión semántica, sino una ineficiencia operativa. GPT-5.5 convirtió con más frecuencia constantes recuperadas en scripts de validación y envió rápidamente. Otros modelos a menudo gastaron el presupuesto de tiempo en exploración estática amplia o clasificación de ruido en tiempo de ejecución sin producir un candidato verificable.
• Sobreajuste: Los agentes a veces identificaron sitios de validación pero fallaron en invertirlos o se sobreajustaron a ejemplos visibles en tareas de generadores de claves, un comportamiento detectado específicamente por el oráculo de nombres de usuario ocultos.
• Uso de herramientas: El manifiesto de herramientas explícito y las salidas de comandos despojadas (eliminando secuencias ANSI) fueron críticos para mantener una interfaz consistente y evitar la explosión del contexto.

Significado y Afirmaciones

El artículo afirma que CrackMeBench establece un entorno de prueba reproducible para medir la transición de los agentes del razonamiento de código fuente al análisis de binarios autónomo. Su significado radica en:

1. Enmarcado de Oráculo Ejecutable: Cambia la métrica de evaluación de "prosa plausible" a "éxito ejecutable", reduciendo la ambigüedad y obligando a los agentes a producir artefactos generalizables (contraseñas, generadores de claves) en lugar de solo descripciones.
2. Alcance Controlado: Al restringir el alcance a programas educativos y construidos con propósito sin acceso a red, la evaluación aísla el comportamiento de ingeniería inversa sin recompensar capacidades ofensivas (análisis de malware, elusión de DRM).
3. Análisis Granular de Fallos: El marco proporciona etiquetas de fallo estructuradas (por ejemplo, "encontró-verificación-pero-no-inverso", "fallo en configuración simbólica") y trazas detalladas, permitiendo un diagnóstico preciso de las limitaciones de los agentes.
4. Línea Base de Evaluación: Los resultados demuestran que, aunque los agentes actuales pueden resolver muchas tareas de ingeniería inversa controladas, siguen siendo débiles en desafíos públicos similares a la realidad, indicando un camino claro para futuras mejoras en el análisis autónomo de binarios.

Los autores enfatizan que CrackMeBench no es una herramienta para la seguridad ofensiva, sino un paso metodológico hacia la comprensión de cómo los agentes pueden analizar binarios compilados de forma autónoma en un entorno seguro y auditable.