LLM4Decompile: Descompilando código binario con LLM

Rendimiento y entrenamiento del modelo

• Se informa que un modelo más pequeño de 6B supera a uno de 33B; los comentaristas atribuyen esto al subentrenamiento de los modelos grandes y a la sensibilidad a la calidad de los datos, los programas de LR, etc.
• El modelo descompilador se ajusta a partir de DeepSeek-Coder; entrenarlo desde cero se considera inviable dado que solo hay ~4B tokens frente a billones para los LLM generales.
• Se comentan necesidades aproximadas de hardware: ~2GB de VRAM para 1B de parámetros, ~14GB para 7B, ~80GB para 33B.

Comparación con GPT‑4 y otros LLM

• GPT‑4 funciona sorprendentemente bien en descompilación pese a no tener entrenamiento específico para la tarea.
• Produce C sintácticamente válido (recompilable) con más frecuencia que el modelo especializado, pero es peor en corrección semántica (re-ejecutabilidad).
• También se informa del uso de GPT‑4/3.5 para desofuscar JavaScript y embellecer código, con éxito parcial pero no completo.

Relación con descompiladores tradicionales e ingeniería inversa

• Varios señalan que los descompiladores modernos de código nativo (IDA, Ghidra, Binja, rev.ng, etc.) son referencias sólidas y deberían formar parte de los benchmarks, usando métricas previas como gotos, complejidad ciclomática y distancia de edición de grafos.
• Algunos profesionales sostienen que la descompilación de binarios complejos, especialmente ensamblador escrito a mano o código altamente optimizado, probablemente no pueda ser totalmente automática; las herramientas principalmente amplifican el esfuerzo experto.
• Otros señalan la diversidad de compiladores, la no determinismo y la falta de biyección entre binarios y código fuente como límites duros; el round-tripping exacto a menudo es imposible.

Evaluación, corrección y “alucinaciones”

• El proyecto actualmente mide:
  • Recompilabilidad: ¿compila el C generado?
  • Re-ejecutabilidad: ¿pasa el binario recompilado los casos de prueba?
• Las tasas de re-ejecutabilidad son bajas (≈10–15%), incluso cuando la recompilabilidad es mucho mayor, lo que subraya las brechas semánticas.
• Hay debate sobre si el round-tripping o los binarios idénticos son una métrica realista; muchos destacan la calidad de las pruebas y el fuzzing como comprobaciones más prácticas.
• Algunos proponen verificación formal: el LLM genera código más una prueba; un verificador no basado en LLM comprueba la equivalencia. Otros cuestionan la viabilidad y los límites de la indecidibilidad.

Casos de uso, alcance y direcciones futuras

• Usos sugeridos: ayudar en ingeniería inversa, análisis de seguridad, análisis de malware y JavaScript ofuscado, detección de toolchain, elevación a representaciones intermedias (p. ej., RzIL) y experimentos de atribución de autoría.
• Muchos ven los LLM como “copilotos” superpuestos a desensambladores/IR existentes más que como descompiladores autónomos.
• La generación de conjuntos de datos a partir de C de código abierto (y posiblemente código sintético) se considera una ventaja clave de esta línea de investigación.