Riepilogo Tecnico: CODEFUSE-DEBENCH

Enunciato del Problema

La decompilazione binaria è una pietra angolare della sicurezza informatica e del reverse engineering, con l'obiettivo di recuperare il codice macchina eseguibile trasformandolo in codice sorgente di alto livello. Tuttavia, le metodologie di valutazione esistenti soffrono di limitazioni significative:

1. Eccessiva dipendenza dalla similarità sintattica: Le metriche attuali si concentrano spesso su coerenza superficiale (ad esempio, righe di codice, corrispondenza a livello di carattere) o punteggi di leggibilità su un singolo asse.
2. Disallineamento con l'utilità pratica: Queste metriche non riescono a misurare il reale valore ingegneristico del codice decompilato. Un decompilatore potrebbe produrre codice visivamente pulito ma semanticamente errato, oppure codice difficile da leggere ma fedele dal punto di vista comportamentale.
3. Mancanza di framework completi: Non esiste un framework standardizzato e automatizzato che valuti simultaneamente leggibilità, ricompilabilità e funzionalità attraverso impostazioni di compilazione e architetture diverse.

Questo divario crea confusione per gli utenti che tentano di utilizzare il codice decompilato per applicazioni a valle (ad esempio, patching, migrazione) e oscura le vere capacità e le modalità di fallimento dei moderni decompilatori.

Metodologia: Framework DEBENCH

Gli autori propongono DEBENCH, un paradigma di valutazione guidato dalla riutilizzabilità che valuta i decompilatori lungo tre dimensioni ortogonali: Leggibilità, Ricompilabilità e Funzionalità.

1. Costruzione del Benchmark

• Suite di test atomica: DEBENCH comprende 240 funzioni di test atomiche raggruppate in 8 file sorgente dimensionali che coprono sfide diverse di reverse engineering (Flusso di Controllo, Tipi di Dati, Operazioni di Memoria, Chiamate di Funzione, C++ Orientato agli Oggetti, Specializzazione a Tempo di Compilazione, Interazione di Sistema e Sfide Speciali).
• Diversità: Queste fonti sono compilate in 640 binari distinti variando cinque assi:
  • Compilatori: GCC, Clang
  • Livelli di Ottimizzazione: -O0, -O1, -O2, -O3, -Os
  • Simboli di Debug: Con -g, Rimossi (Stripped)
  • Architetture: x86, x64, ARM32, ARM64
• Principi di Progettazione: La suite enfatizza l'Atomicità (isolare specifiche caratteristiche del linguaggio) e la Complessità Progressiva (categorizzare i casi in livelli di difficoltà L1–L5 basati sulla complessità del flusso di controllo/dati, resistenza all'ottimizzazione e rischio di perdita semantica).

2. Pipeline di Valutazione

Il framework impiega una pipeline completamente automatizzata in tre fasi:

• Fase 1: Leggibilità (URAF)

  • Utilizza un approccio LLM-as-Judge con il Unified Readability Assessment Framework (URAF).
  • Valuta il codice rispetto al sorgente ground-truth attraverso 18 sotto-dimensioni organizzate in 5 livelli: Chiarezza Lessicale, Intelligibilità Strutturale, Fedeltà del Sistema di Tipi, Trasparenza Semantica e Coerenza Contestuale.
  • Impiega tre giudici LLM indipendenti (GLM-4.7, Qwen3.5-Plus, MiniMax-M2.5) per mitigare i bias.

• Fase 2: Ricompilabilità

  • Implementa una pipeline di Riparazione Iterativa guidata da LLM.
  • Un agente automatizzato analizza i diagnostici del compilatore (GCC/Clang) e delega le correzioni a un LLM.
  • Opera con un budget fisso di 50 iterazioni.
  • Gli esiti sono categorizzati in tre livelli: Successo Completo (FS), Fallimento di Link (LF) e Fallimento di Compilazione (CF).

• Fase 3: Funzionalità

  • Utilizza il tracciamento dinamico differenziale basato su Frida per confrontare il binario originale con quello ricompilato.
  • Osserva il comportamento a runtime a tre granularità: Livello Programma (coerenza stdout), Livello Funzione (corrispondenza registri/valori di ritorno) e Livello Istruzione (similarità sequenziale).
  • Classifica i risultati in: Stdout Esatto, Parziale, Fallimento e Non Supportato.

Contributi Chiave

1. Paradigma di Valutazione Guidato dalla Riutilizzabilità: Sposta il focus dalla similarità sintattica all'utilità pratica valutando congiuntamente leggibilità, ricompilabilità e funzionalità.
2. Infrastruttura Automatizzata End-to-End (DEBENCH): Il primo framework a integrare la valutazione tramite LLM-as-judge, la riparazione iterativa di compilazione e la verifica del comportamento dinamico su un benchmark su larga scala e multidimensionale.
3. Riscontri Empirici: Fornisce una caratterizzazione sistematica di cinque decompilatori mainstream (IDA, Ghidra, RetDec, Angr, BinaryAI) e tre LLM di riparazione, rivelando modalità di fallimento e limiti di capacità invisibili alle valutazioni su singolo asse.

Risultati Chiave

Lo studio produce quattro risultati principali che sfidano le assunzioni convenzionali:

1. Il Baratro della Riutilizzabilità: Esiste un divario ripido e riproducibile tra ricompilabilità ed equivalenza comportamentale.

   • La migliore coppia decompilatore-LLM (IDA + Qwen3.5-Plus) raggiunge il 73,8% di ricompilabilità ma solo il 22,3% di sovrapposizione comportamentale a livello di programma (Esatto + Parziale).
   • La corrispondenza Stdout Esatto è solo dell'1,2%.
   • Questo rappresenta un baratro di circa 50 punti percentuali tra il codice che può essere compilato e il codice che si comporta correttamente.

2. Disaccoppiamento tra Leggibilità e Funzionalità: Le scelte di compilazione che massimizzano la leggibilità non necessariamente massimizzano la funzionalità.

   • Ottimizzazione: L'aggressiva -O3 produce i punteggi di leggibilità più bassi ma la funzionalità più alta (16,0% Esatto+Parziale contro l'8,6% per -O0).
   • Compilatore: Clang produce punteggi di leggibilità inferiori rispetto a GCC ma risulta in una funzionalità 2,6 volte superiore (26,5% contro 10,2% Esatto+Parziale).

3. Divari Asimmetrici (Decompilatore vs LLM): L'investimento ingegneristico dovrebbe mirare ai motori dei decompilatori, non a modelli di riparazione più grandi.

   • Cambiare decompilatore (ad esempio, da RetDec a IDA) con un LLM fisso causa un'oscillazione di 20 volte nella funzionalità (1,1% vs 22,3%).
   • Cambiare LLM con un decompilatore fisso causa solo un'oscillazione di 1,6 volte (13,9% vs 22,3%).

4. Decomposizione dei Fallimenti: I fallimenti rientrano in tre categorie con riparabilità distinta:

   • Rumore Sintattico: Riparabile dagli LLM (ad esempio, intestazioni mancanti, errori di sintassi).
   • Collasso del Sistema di Tipi: Rappresenta circa il 19% degli errori (ad esempio, tipi conflittuali, mismatch di puntatori). Parzialmente riparabile ma spesso porta a derive comportamentali.
   • Perdite Irreversibili a Monte: Irriparabili dagli LLM. Include idiomi di relocation specifici per ARM64 (ADRP+ADD) e funzionalità ABI C++ (vtable, dispatch virtuale) che i decompilatori non riescono a ricostruire.

Significato e Implicazioni

Il documento ridefinisce la qualità del decompilatore come un continuo multi-assiale piuttosto che un singolo punteggio. Sostiene che una "leggibilità moderata" spesso sovrastima l'utilità a valle di circa 3 volte.

Gli autori identificano tre direzioni prioritarie per l'ingegneria lato decompilatore per colmare il divario dalla traduzione sintattica alla ricostruzione semantica:

1. Ricostruzione di Tipi Compositi: Recupero di tipi complessi che sopravvivono alla rimozione dei simboli.
2. Relocation Simbolica a Livello IR: Tracciamento delle relocation (specialmente su ARM64) senza collassarle in aritmetica opaca.
3. Passaggi Front-End Consapevoli dell'ABI C++: Specificamente per la ricostruzione di vtable e dispatch virtuale per gestire codice C++ Orientato agli Oggetti.

Lo studio conclude che, sebbene gli LLM siano efficaci per la riparazione a livello superficiale, i colli di bottiglia fondamentali risiedono nella capacità dei motori decompilatori di recuperare la struttura semantica e le informazioni sui tipi, rendendo necessaria un'innovazione a livello di motore piuttosto che un'ottimizzazione a livello di prompt.