Multi-View Decompilation for LLM-Based Malware Classification

Résumé technique : Décompilation multi-vues pour la classification de malwares basée sur les LLM

Énoncé du problème
Les analystes de malwares s'appuient fréquemment sur du code pseudo-C décompilé pour inspecter des binaires compilés lorsque le code source n'est pas disponible. Bien que les grands modèles de langage (LLM) aient montré un potentiel pour automatiser la classification de ce code décompilé comme bénin ou malveillant, les pipelines existants reposent généralement sur la sortie d'un seul décompilateur. Les auteurs soutiennent que cette hypothèse est fragile car la décompilation est un processus heuristique et avec perte. Différents outils font des choix distincts concernant la récupération du flux de contrôle, le nommage des variables, l'inférence de type et la simplification des expressions. Par conséquent, la vue d'un seul décompilateur peut masquer des comportements malveillants ou introduire des artefacts spécifiques à l'outil qui induisent un LLM en erreur, tandis qu'un autre outil pourrait exposer plus clairement le même comportement.

Méthodologie
Pour étudier si plusieurs vues de décompilation fournissent des preuves complémentaires, les auteurs ont construit un benchmark équilibré de 100 programmes C (50 utilitaires bénins et 50 échantillons malveillants couvrant des familles telles que Mirai, MyDoom et des rootkits). Chaque programme a été compilé en un fichier objet ELF x86 64 bits et décompilé à l'aide de deux outils open-source largement utilisés : Ghidra et RetDec.

L'étude a évalué un panel de cinq LLM optimisés pour l'instruction (incluant GPT-5.4-mini, Claude Haiku 4.5, Llama-3.3-70B, Qwen3-35B et Gemini-2.5-flash-lite) à travers trois configurations de prompting :

1. Vue unique (Single-View) : Le LLM classifie la sortie de soit Ghidra, soit RetDec de manière indépendante.
2. Multi-vues (Multi-View) : Le LLM reçoit les deux vues décompilées dans un seul prompt, avec l'instruction de les traiter comme des représentations complémentaires du même binaire.
3. Consensus déclenché par désaccord (Disagreement-Triggered Consensus) : Le système exécute d'abord des prédictions à vue unique ; si elles sont d'accord, l'étiquette est acceptée. Si elles divergent, un prompt multi-vues est déclenché pour résoudre le conflit.

L'évaluation s'est concentrée sur la classe malveillante, en privilégiant le rappel (recall) et le score F1, car les faux négatifs (manquer un malware) sont particulièrement coûteux dans les scénarios de triage.

Résultats clés

• Variabilité des décompilateurs : Le choix du décompilateur impacte significativement la performance de classification. Aucun outil n'était universellement supérieur ; par exemple, Ghidra donnait de meilleurs résultats pour les modèles Qwen et GPT, tandis que RetDec était plus performant pour Llama-3.3-70B.
• Gains de performance : La configuration Multi-Vue a systématiquement surpassé les bases à vue unique pour la plupart des familles de modèles. Elle a amélioré le score F1 de la classe malveillante jusqu'à +13,9 points (pour Gemini-2.5-flash-lite) et +7,9 points (pour Llama-3.3-70B) par rapport au meilleur résultat à vue unique.
• Mécanisme d'amélioration : Les gains ont été principalement portés par une augmentation du rappel. L'analyse des désaccords de prédiction a montré que lorsqu'un décompilateur masquait un comportement malveillant (menant à un faux négatif), l'autre exposait souvent des preuves suffisantes pour que le LLM identifie correctement l'échantillon comme malveillant.
• Efficacité des modèles : L'approche multi-vues a été particulièrement efficace pour les modèles plus petits et moins coûteux, leur permettant de réduire l'écart de performance avec les modèles plus grands et plus onéreux (ex: Gemini Pro).
• Règle de consensus : La règle de consensus déclenchée par désaccord est compétitive mais n'a généralement pas surpassé le prompting multi-vues direct, suggérant que le bénéfice de la combinaison des vues s'étend au-delà de la simple résolution des désaccords explicites.

Signification et contributions
L'article apporte trois contributions principales :

1. Un benchmark curaté : Un ensemble de données de sorties appariées Ghidra et RetDec pour 100 programmes C bénins et malveillants, permettant une évaluation reproductible de la variabilité des décompilateurs.
2. Une formulation multi-vues : Un nouveau pipeline qui traite les sorties de plusieurs décompilateurs comme des preuves complémentaires plutôt que de se fier à une seule représentation canonique.
3. Validation empirique : La preuve que la diversité des décompilateurs est une méthode simple, sans entraînement, pour améliorer le triage de malwares par LLM.

Revendications de signification
Les auteurs positionnent ce travail comme une solution pratique pour le triage de malwares en conditions réelles. Ils soulignent que le prompting multi-décompilateur améliore les taux de détection (spécifiquement le rappel) sans nécessiter d'entraînement de modèle, d'accès au code source ou d'architectures d'ensemble complexes. En exploitant des décompilateurs open-source existants et des LLM prêts à l'emploi, cette approche offre un moyen rentable de mitiger la nature « fragile » de la décompilation à vue unique, garantant que les comportements malveillants obscurcis par les heuristiques d'un outil ne soient pas manqués.

Limites
Les auteurs reconnaissent plusieurs contraintes :

• Le benchmark utilise des fichiers objets repositionnables (.o) plutôt que des exécutables complets, ce qui peut ne pas capturer pleinement le contexte des binaires déployés.
• L'étude suppose une décompilation propre ; elle n'évalue pas la performance face à des binaires fortement obfusqués, packés ou durcis contre la décompilation.
• Les conclusions sont basées sur deux décompilateurs spécifiques (Ghidra et RetDec) et peuvent varier avec des outils propriétaires ou un plus grand nombre de vues.