Resumo Técnico: CODEFUSE-DEBENCH

Declaração do Problema

A descompilação de binários é um pilar da segurança de software e da engenharia reversa, visando recuperar código de máquina executável em código-fonte de alto nível. No entanto, as metodologias de avaliação existentes sofrem de limitações significativas:

1. Excesso de Dependência em Similaridade Sintática: Métricas atuais frequentemente focam em consistência superficial (por exemplo, linhas de código, correspondência em nível de caractere) ou escores de legibilidade de um único eixo.
2. Desalinhamento com Utilidade Prática: Essas métricas falham em medir o valor real de engenharia do código descompilado. Um descompilador pode produzir código visualmente limpo que é semanticamente incorreto, ou código difícil de ler, mas fiel ao comportamento.
3. Falta de Frameworks Abrangentes: Não existe um framework padronizado e automatizado que avalie simultaneamente legibilidade, recompilabilidade e funcionalidade através de configurações de compilação e arquiteturas diversas.

Essa lacuna cria confusão para usuários que tentam utilizar código descompilado para aplicações a jusante (por exemplo, correção de falhas, migração) e obscurece as verdadeiras capacidades e modos de falha dos descompiladores modernos.

Metodologia: Framework DEBENCH

Os autores propõem o DEBENCH, um paradigma de avaliação impulsionado pela reutilizabilidade que avalia descompiladores ao longo de três dimensões ortogonais: Legibilidade, Recompilabilidade e Funcionalidade.

1. Construção do Benchmark

• Suite de Testes Atômica: O DEBENCH compreende 240 funções de teste atômicas agrupadas em 8 arquivos-fonte dimensionais cobrindo desafios diversos de engenharia reversa (Fluxo de Controle, Tipos de Dados, Operações de Memória, Chamadas de Função, C++ Orientado a Objetos, Especialização em Tempo de Compilação, Interação com Sistema e Desafios Especiais).
• Diversidade: Essas fontes são compiladas em 640 binários distintos variando cinco eixos:
  • Compiladores: GCC, Clang
  • Níveis de Otimização: -O0, -O1, -O2, -O3, -Os
  • Símbolos de Depuração: Com -g, Removidos
  • Arquiteturas: x86, x64, ARM32, ARM64
• Princípios de Design: A suite enfatiza Atmicidade (isolando características específicas da linguagem) e Complexidade Progressiva (categorizando casos em níveis de dificuldade L1–L5 baseados em complexidade de fluxo de controle/dados, resistência à otimização e risco de perda semântica).

2. Pipeline de Avaliação

O framework emprega um pipeline totalmente automatizado de três estágios:

• Estágio 1: Legibilidade (URAF)

  • Utiliza uma abordagem de LLM como Juiz com o Unified Readability Assessment Framework (URAF).
  • Avalia o código contra a fonte ground-truth através de 18 sub-dimensões organizadas em 5 níveis: Clareza Léxica, Intelligibilidade Estrutural, Fidelidade do Sistema de Tipos, Transparência Semântica e Coerência Contextual.
  • Emprega três juízes LLM independentes (GLM-4.7, Qwen3.5-Plus, MiniMax-M2.5) para mitigar viés.

• Estágio 2: Recompilabilidade

  • Implementa um pipeline de Reparo Iterativo impulsionado por LLM.
  • Um agente automatizado analisa diagnósticos do compilador (GCC/Clang) e delega correções a um LLM.
  • Opera sob um orçamento fixo de 50 iterações.
  • Os resultados são categorizados em três níveis: Sucesso Total (FS), Falha de Link (LF) e Falha de Compilação (CF).

• Estágio 3: Funcionalidade

  • Utiliza rastreamento dinâmico diferencial baseado em Frida para comparar o binário original contra o binário recompilado.
  • Observa o comportamento em tempo de execução em três granularidades: Nível de Programa (consistência de stdout), Nível de Função (correspondência de registrador/valor de retorno) e Nível de Instrução (similaridade de sequência).
  • Classifica os resultados em: Stdout Exato, Parcial, Falha e Não Suportado.

Contribuições Principais

1. Paradigma de Avaliação Impulsionado pela Reutilizabilidade: Desloca o foco da similaridade sintática para a utilidade prática, avaliando conjuntamente legibilidade, recompilabilidade e funcionalidade.
2. Infraestrutura Automatizada de Ponta a Ponta (DEBENCH): O primeiro framework a integrar pontuação de LLM como juiz, reparo iterativo de compilação e verificação de comportamento dinâmico em um benchmark grande escala e multidimensional.
3. Insights Empíricos: Fornece uma caracterização sistemática de cinco descompiladores principais (IDA, Ghidra, RetDec, Angr, BinaryAI) e três LLMs de reparo, revelando modos de falha e limites de capacidade invisíveis para avaliações de eixo único.

Principais Descobertas

O estudo produz quatro descobertas primárias que desafiam suposições convencionais:

1. O Penhasco da Reutilizabilidade: Existe uma lacuna íngreme e reproduzível entre recompilabilidade e equivalência comportamental.

   • O melhor par descompilador–LLM (IDA + Qwen3.5-Plus) alcança 73,8% de recompilabilidade, mas apenas 22,3% de sobreposição comportamental em nível de programa (Exato + Parcial).
   • A correspondência Stdout Exato é de apenas 1,2%.
   • Isso representa um penhasco de ~50 pontos percentuais entre código que pode ser compilado e código que se comporta corretamente.

2. Desacoplamento de Legibilidade e Funcionalidade: Escolhas de compilação que maximizam a legibilidade não necessariamente maximizam a funcionalidade.

   • Otimização: A agressiva -O3 produz os menores escores de legibilidade, mas a maior funcionalidade (16,0% Exato+Parcial vs. 8,6% para -O0).
   • Compilador: O Clang produz escores de legibilidade mais baixos que o GCC, mas resulta em 2,6× mais funcionalidade (26,5% vs. 10,2% Exato+Parcial).

3. Lacunas Assimétricas (Descompilador vs. LLM): O investimento em engenharia deve visar os motores dos descompiladores, não modelos de reparo maiores.

   • Alterar descompiladores (por exemplo, RetDec para IDA) sob um LLM fixo causa uma variação de 20× na funcionalidade (1,1% para 22,3%).
   • Alterar LLMs sob um descompilador fixo causa apenas uma variação de 1,6× (13,9% para 22,3%).

4. Decomposição de Falhas: As falhas caem em três categorias com reparabilidade distinta:

   • Ruído Sintático: Reparável por LLMs (por exemplo, cabeçalhos ausentes, erros de sintaxe).
   • Colapso do Sistema de Tipos: Responsável por ~19% dos erros (por exemplo, tipos conflitantes, incompatibilidades de ponteiro). Parcialmente reparável, mas frequentemente leva a desvios comportamentais.
   • Perdas Irreversíveis a Montante: Irreparáveis por LLMs. Inclui idiomáticas de realocação específicas de ARM64 (ADRP+ADD) e recursos de ABI C++ (vtables, despacho virtual) que os descompiladores falham em reconstruir.

Significado e Implicações

O artigo reestrutura a qualidade do descompilador como um contínuo de múltiplos eixos em vez de um escore único. Argumenta que a "legibilidade moderada" frequentemente superestima a utilidade a jusante em aproximadamente 3×.

Os autores identificam três direções prioritárias para a engenharia do lado do descompilador para fechar a lacuna da tradução sintática para a reconstrução semântica:

1. Reconstrução de Tipos Compostos: Recuperar tipos complexos que sobrevivem ao descarte de símbolos.
2. Realocação Simbólica em Nível IR: Rastrear realocações (especialmente em ARM64) sem colapsá-las em aritmética opaca.
3. Passagens de Front-end Conscientes da ABI C++: Especificamente para reconstruir vtables e despacho virtual para lidar com código C++ Orientado a Objetos.

O estudo conclui que, embora LLMs sejam eficazes para reparo em nível superficial, os gargalos fundamentais residem na capacidade dos motores descompiladores de recuperar estrutura semântica e informações de tipo, necessitando de inovação em nível de motor em vez de ajuste em nível de prompt.