LLM4Decompile: Descompilando código binário com LLM

Desempenho do modelo e treinamento

• O modelo menor de 6B supostamente supera um de 33B; comentaristas atribuem isso ao subtreinamento de modelos grandes e à sensibilidade à qualidade dos dados, agendas de LR etc.
• O modelo de descompilação é ajustado a partir do DeepSeek-Coder; treinamento do zero é visto como inviável, dado que há apenas ~4B tokens vs. trilhões para LLMs gerais.
• Necessidades aproximadas de hardware discutidas: ~2GB de VRAM para 1B de parâmetros, ~14GB para 7B, ~80GB para 33B.

Comparação com GPT‑4 e outros LLMs

• O GPT‑4 se sai surpreendentemente bem em descompilação, apesar de não ter treinamento específico para a tarefa.
• Ele produz C sintaticamente válido (recompilável) com mais frequência do que o modelo especializado, mas é pior em correção semântica (reexecutabilidade).
• Pessoas também relatam usar GPT‑4/3.5 para desofuscar JavaScript e embelezar código, com sucesso parcial, mas não completo.

Relação com descompiladores tradicionais e engenharia reversa

• Vários observam que descompiladores modernos de código nativo (IDA, Ghidra, Binja, rev.ng etc.) são fortes referências e deveriam fazer parte dos benchmarks, usando métricas anteriores como gotos, complexidade ciclomática e distância de edição de grafos.
• Alguns praticantes argumentam que a descompilação de binários complexos, especialmente assembly escrito à mão ou código fortemente otimizado, provavelmente não pode ser totalmente automática; as ferramentas principalmente ampliam o esforço do especialista.
• Outros apontam a diversidade de compiladores, a não determinismo e a ausência de bijeção entre binários e código-fonte como limites difíceis; a ida e volta exata muitas vezes é impossível.

Avaliação, correção e “alucinações”

• O projeto atualmente mede:
  • Recompilabilidade: o C gerado compila?
  • Reexecutabilidade: o binário recompilado passa nos casos de teste?
• As taxas de reexecutabilidade são baixas (≈10–15%), mesmo quando a recompilabilidade é muito maior, evidenciando lacunas semânticas.
• Há debate sobre se ida e volta ou binários idênticos são uma métrica realista; muitos enfatizam a qualidade dos testes e fuzzing como verificações mais práticas.
• Alguns propõem verificação formal: a LLM gera código mais uma prova; um verificador não-LLM checa a equivalência. Outros questionam a viabilidade e os limites da indecidibilidade.

Casos de uso, escopo e direções futuras

• Usos sugeridos: auxiliar engenharia reversa, análise de segurança, análise de malware e de JavaScript ofuscado, detecção de toolchain, elevação para representações intermediárias (por exemplo, RzIL) e experimentos de atribuição de autoria.
• Muitos veem LLMs como “copilotos” sobrepostos a desassembladores/IRs existentes, em vez de descompiladores independentes.
• A geração de conjuntos de dados a partir de C de código aberto (e possivelmente código sintético) é vista como uma vantagem-chave dessa direção de pesquisa.