Multi-View Decompilation for LLM-Based Malware Classification

Sintesi Tecnica: Decompilazione Multi-Vista per la Classificazione di Malware Basata su LLM

Definizione del Probleo
Gli analisti di malware si affidano frequentemente al codice pseudo-C decompilato per ispezionare binari compilati quando il codice sorgente non è disponibile. Sebbene i Large Language Models (LLM) abbiano mostrato potenziale nell'automatizzare la classificazione di tale codice decompilato come benigno o malevolo, le pipeline esistenti si basano tipicamente sull'output di un singolo decompiler. Gli autori sostengono che tale assunzione sia fragile perché la decompilazione è un processo euristico e con perdita di informazioni. Diversi strumenti compiono scelte distinte riguardo al recupero del flusso di controllo, alla denominazione delle variabili, all'inferenza dei tipi e alla semplificazione delle espressioni. Di conseguenza, la vista di un singolo decompiler può oscurare comportamenti malevoli o introdurre artefatti specifici dello strumento che possono trarre in inganno un LLM, mentre un altro strumento potrebbe esporre lo stesso comportamento in modo più chiaro.

Metodologia
Per investigare se molteplici viste di decompilazione forniscano prove complementari, gli autori hanno costruito un benchmark bilanciato di 100 programmi in C (50 utility benigne e 50 campioni malevoli coprendo famiglie come Mirai, MyDoom e rootkit). Ogni programma è stato compilato in un file oggetto ELF a 64 bit per architettura x86 e decompilato utilizzando due strumenti open-source ampiamente diffusi: Ghidra e RetDec.

Lo studio ha valutato un panel di cinque LLM istruiti per l'istruzione (inclusi GPT-5.4-mini, Claude Haiku 4.5, Llama-3.3-70B, Qwen3-35B e Gemini-2.5-flash-lite) attraverso tre impostazioni di prompting:

1. Vista Singola (Single-View): L'LLM classifica l'output di Ghidra o RetDec indipendentemente.
2. Multi-Vista (Multi-View): L'LLM riceve entrambe le viste decompilate in un singolo prompt, con l'istruzione di trattarle come rappresentazioni complementari dello stesso binario.
3. Consenso Innescato dal Disaccordo (Disagreement-Triggered Consensus): Il sistema esegue prima le predizioni a vista singola; se concordano, l'etichetta viene accettata. Se discordano, viene attivato un prompt multi-vista per risolvere il conflitto.

La valutazione si è concentrata sulla classe malevola, dando priorità a recall e F1 score, poiché i falsi negativi (mancata rilevazione di malware) sono particolarmente costosi negli scenari di triage.

Risultati Chiave

• Variabilità del Decompiler: La scelta del decompiler impatta significativamente le prestazioni di classificazione. Nessuno strumento è stato universalmente superiore; ad esempio, Ghidra ha prodotto risultati migliori per i modelli Qwen e GPT, mentre RetDec ha performato meglio per Llama-3.3-70B.
• Guadagni di Performance: L'impostazione Multi-Vista ha costantemente superato i baseline a vista singola nella maggior parte delle famiglie di modelli. Ha migliorato l'F1 score della classe malevola fino a +13,9 punti (per Gemini-2.5-flash-lite) e +7,9 punti (per Llama-3.3-70B) rispetto al miglior risultato a vista singola.
• Meccanismo di Miglioramento: I guadagni sono stati guidati principalmente da un aumento della recall. L'analisi dei disaccordi nelle predizioni ha mostrato che quando un decompiler oscurava un comportamento malevolo (portando a un falso negativo), l'altro spesso esponeva prove sufficienti affinché l'LLM identificasse correttamente il campione come malevolo.
• Efficienza del Modello: L'approccio multi-vista è stato particolarmente efficace per i modelli più piccoli e a minor costo, permettendo loro di colmare il divario di performance con modelli più grandi e costosi (es. Gemini Pro).
• Regola di Consenso: La regola del consenso innescato dal disaccordo è stata competitiva ma generalmente non ha superato il prompting multi-vista diretto, suggerendo che il beneficio della combinazione delle viste vada oltre la semplice risoluzione di espliciti disaccordi.

Significatività e Contributi
Il lavoro apporta tre contributi primari:

1. Un Benchmark Curato: Un dataset di output accoppiati di Ghidra e RetDec per 100 programmi C benigni e malevoli, che consente una valutazione riproducibile della variabilità dei decompiler.
2. Una Formulazione Multi-Vista: Una nuova pipeline che tratta i molteplici output dei decompiler come prove complementari invece di fare affidamento su una singola rappresentazione canonica.
3. Validazione Empirica: La prova che la diversità dei decompiler è un metodo semplice, che non richiede addestramento, per migliorare il triage del malware basato su LLM.

Rivendicazioni di Significatività
Gli autori posizionano questo lavoro come una soluzione pratica per il triage del malware nel mondo reale. Essi sottolineano che il prompting multi-decompiler migliora i tassi di rilevamento (specificamente la recall) senza richiedere l'addestramento di modelli, l'accesso al codice sorgente o complesse architetture ensemble. Sfruttando decompiler open-source esistenti e LLM pronti all'uso, questo approccio offre un modo efficace in termini di costi per mitigare la natura "fragile" della decompilazione a vista singola, garantendo che i comportamenti malevoli oscurati dalle euristiche di uno strumento non vengano trascurati.

Limitazioni
Gli autori riconoscono diverse limitazioni:

• Il benchmark utilizza file oggetto rilocabili (.o) piuttosto che eseguibili completi, il che potrebbe non catturare appieno il contesto dei binari distribuiti.
• Lo studio assume una decompilazione pulita; non valuta le prestazioni contro binari pesantemente offuscati, impacchettati (packed) o protetti da tecniche anti-decompilazione.
• Le conclusioni si basano su due decompiler specifici (Ghidra e Ret dec) e potrebbero variare con strumenti proprietari o un numero maggiore di viste.