LLM et reverse engineering — analyser le malware automatiquement

Le reverse engineering de malware assiste par LLM represente l'une des avancees les plus significatives en analyse de code malveillant depuis l'introduction des debuggers interactifs. Face au volume croissant de malwares -- plus de 500 000 nouvelles souches identifies par jour selon Kaspersky Security Bulletin 2026 -- les analystes malware ne peuvent plus se permettre d'analyser chaque echantillon manuellement. L'integration de LLM dans des outils comme Ghidra et IDA Pro permet de transformer des fonctions desassemblees en descriptions fonctionnelles comprehensibles, d'extraire automatiquement les IOC (Indicators of Compromise), de classifier les fonctions par type (crypto, network, persistance, C2), et de generer des rapports d'analyse en quelques minutes plutot qu'en plusieurs heures. Cet article presente l'architecture technique complete d'un pipeline de reverse engineering assiste par LLM, le code Python pour l'integration Ghidra/LLM, une analyse de cas reels (BlackSuit ransomware, Nitrogen loader 2026), les considerations pour le depoiement en production, et les limites importantes a connaitre pour eviter les pieges des hallucinations LLM sur du code desassemble complexe.

Architecture du pipeline Ghidra + LLM

Le pipeline de reverse engineering LLM se compose de quatre etapes principales :

1. Decompilation Ghidra : utiliser Ghidra en mode headless pour decompiler le binaire et exporter les fonctions decompilees en pseudo-C ou en bytecode annote
2. Preprocessing : normaliser le code decompile (renommer les variables generiques, identifier les structures de donnees connues, resoudre les appels d'API Windows)
3. Analyse LLM : soumettre chaque fonction au LLM pour classification, description fonctionnelle et extraction d'IOC
4. Agregation et rapport : consolider les analyses par fonction en un rapport d'ensemble identifiant les capabilities du malware, les IOC et les recommandations de detection

Ghidra headless integration -- scripts et API

L'integration de Ghidra en mode headless avec un LLM permet d'automatiser l'analyse de larges volumes d'echantillons. Ghidra headless (ghidraRun) permet d'executer des scripts Ghidra Python/Java sans interface graphique, ideale pour l'integration dans des pipelines CI/CD ou des systemes de sandboxing automatises.

import subprocess, json, requests

GHIDRA_HOME = "/opt/ghidra"
OLLAMA_URL = "http://localhost:11434/api/generate"

def analyze_with_ghidra(binary_path):
    # Executer Ghidra headless + script d'export des fonctions
    cmd = [
        GHIDRA_HOME + "/support/analyzeHeadless",
        "/tmp/ghidra_projects", "malware_analysis",
        "-import", binary_path,
        "-postScript", "/opt/ghidra_scripts/export_functions.py",
        "-deleteProject"
    ]
    subprocess.run(cmd, capture_output=True, timeout=300)
    with open("/tmp/ghidra_output.json") as f:
        return json.load(f)

def classify_function(func_data):
    # Classification LLM de la fonction desassemblee
    prompt = (
        "Tu es un expert en analyse malware. Analyse cette fonction et reponds en JSON avec: "
        "category (benign/crypto/network/c2/persistence/evasion/injection/unknown), "
        "description (1-2 phrases), iocs (liste: IPs, URLs, cles registre), confidence (0.0-1.0).\n"
        "Fonction: " + func_data.get("name", "unknown") + "\n"
        "Code:\n" + func_data.get("pseudo_c", "")[:1500]
    )
    resp = requests.post(OLLAMA_URL, json={
        "model": "llama3.3:70b", "prompt": prompt, "stream": False, "format": "json"
    }, timeout=60)
    try:
        return json.loads(resp.json().get("response", "{}"))
    except json.JSONDecodeError:
        return {"category": "unknown", "confidence": 0.0}

def analyze_malware_sample(binary_path):
    functions = analyze_with_ghidra(binary_path)
    print(f"Analyzing {len(functions)} functions...")
    results = []
    for func in functions[:50]:
        if func.get("size", 0) < 10:
            continue
        classification = classify_function(func)
        results.append({**func, **classification})
        cat = classification.get("category", "unknown")
        if cat not in ["benign", "unknown"]:
            print(f"[{cat.upper()}] {func['name']} @ {func.get('address', '?')}")
    return results

# Usage: results = analyze_malware_sample("/tmp/suspect.exe")

Function classification automatique -- benigne, malveillante, crypto, C2

La classification automatique des fonctions par LLM distingue plusieurs categories fonctionnelles caracteristiques des malwares :

La precision LLM sur la classification de fonctions malware varie selon la qualite de la decompilation Ghidra et le niveau d'obfuscation du binaire. Sur des malwares non packes et bien decompiles, une precision de 80 a 90% est atteignable avec Llama 3.3 70B. Sur des binaires fortement obfusques ou packes, la precision chute a 50-65% et une analyse manuelle des fonctions critiques reste indispensable.

IOC extraction par NLP -- domaines, IPs, hashes et registry keys

L'extraction d'IOC par NLP est l'un des cas d'usage les plus immediatement valorisables de l'analyse LLM malware. Plutot que de rechercher manuellement les chaines de caracteres dans le binaire, le LLM peut identifier semantiquement les IOC dans le code decompile :

• Domaines C2 : URLs et domaines hardcodes dans les fonctions de communication, y compris ceux passes via des encodages simples (XOR, base64, ROT13)
• Adresses IP : IPs hardcodees dans les fonctions de connexion, y compris converties en format decimal (0xC0A80101 = 192.168.1.1)
• Cles de registre : chemins de persistance Registry, souvent concatènes via des appels successifs a strcat ou sprintf
• Noms de fichiers et chemins : chemins de depot de payload, noms de services crees, emplacement des fichiers voles
• Mutex names : noms de mutex uniques utilises pour eviter les doubles infections (excellent IOC de haute fiabilite)

Enrichissement des analyses avec la threat intelligence

L'enrichissement des analyses LLM malware avec la threat intelligence ameliore significativement la precision et la contextualisation des findings. En integrant des feeds de threat intelligence (MISP, OpenCTI, VirusTotal) dans le contexte du LLM, l'agent peut corréler les IOC extraits avec des campagnes connues, identifier la famille probable du malware et suggerer des regles YARA ou Sigma adaptees. Le workflow enrichi fonctionne ainsi : extraction d'IOC par le pipeline LLM, recherche des IOC dans les bases de TI (hashes VirusTotal, domaines dans AbuseIPDB, TTP dans MITRE ATT&CK), injection des resultats de TI dans un prompt de synthese, et generation d'un rapport contextualise incluant les liens avec des acteurs de menace connus. Par exemple, la detection d'un mutex specifique comme "rpg9bvpn" associe a des domaines de C2 dans des pays specifiques peut permettre au LLM d'identifier la campagne comme liee au groupe APT avec un niveau de confiance eleve, en s'appuyant sur les IOC repertories dans les bases de TI integrées. Cette capacite de correlation entre analyse technique et threat intelligence transforme l'analyse malware d'une activite purement technique en une analyse de renseignement actionnable pour le SOC. La mise en oeuvre d'une base de TI integree est documentee dans notre article sur le SOC augmente par IA. Pour les obligations reglementaires de partage d'information sur les malwares, consultez notre guide NIS 2 qui impose des procedures de signalement d'incidents incluant les informations sur les malwares identifies.

Automatisation du reporting d'analyse malware

L'automatisation du reporting d'analyse malware par LLM est l'etape finale du pipeline qui transforme les donnees techniques en livrables actionables. Le LLM peut generer plusieurs types de rapports adaptes a differentes audiences : un rapport technique detaille pour les analystes malware (liste exhaustive des fonctions, IOC, TTP MITRE ATT&CK), un rapport executif pour le RSSI et le COMEX (impact potentiel, recommandations de remediation prioritaires, comparaison avec des incidents precedents), et des regles de detection operationnelles pour le SOC (regles YARA pour la detection de l'echantillon, regles Sigma pour la detection des comportements, requetes SIEM pret a deployer). La generation de ces regles de detection par LLM est particulierement precieuse : au lieu d'ecrire manuellement une regle YARA en analysant les patterns de l'echantillon, le LLM genere automatiquement une regle basee sur les IOC uniques identifies, que l'analyste n'a plus qu'a valider et tester avant deploiement. Notre guide sur la gestion des incidents integre ces livrables d'analyse malware dans le processus de reponse aux incidents et de remediation.

CFG analysis et detection patterns d'obfuscation

L'analyse du Control Flow Graph (CFG) par LLM permet d'identifier des patterns d'obfuscation qui ne sont pas visibles a l'analyse des fonctions individuelles. Un CFG avec un nombre inhabituel de blocs basiques sans relation semantique claire peut indiquer une obfuscation par insertion de dead code ou par opaque predicates. Le LLM peut analyser une representation textuelle du CFG (exportee depuis Ghidra) et identifier ces patterns structurels caracteristiques de familles de packers specifiques (UPX, Themida, VMProtect).

La detection des techniques d'evasion courantes par LLM inclut : l'identification du sleep-based evasion (appels a Sleep() avec des delais specifiques typiques des sandboxes), la detection du timing-based anti-debug (RDTSC timing checks, GetTickCount comparisons), et la reconnaissance des patterns de process hollowing ou de reflective loading caracteristiques des loaders sophistiques.

Comparaison Ghidra LLM vs IDA Pro avec Claude et GPT

La comparaison des approches LLM pour le reverse engineering entre Ghidra et IDA Pro revele des differences significatives :

• Ghidra + LLM local (Ollama) : entierement gratuit et open source, qualite de decompilation inferieure a IDA Pro sur les binaires x64 complexes, mais adequate pour la majorite des malwares communs. Ideal pour les organisations avec contraintes de budget et de souverainete.
• IDA Pro + Claude API : meilleure qualite de decompilation, integration native via le plugin IDA-Claude, mais cout eleve (licence IDA Pro + credits API Anthropic) et problemes potentiels de confidentialite en envoyant du code malveillant vers l'API cloud.
• Binary Ninja + LLM : alternative de plus en plus populaire, bon compromis qualite/prix, API Python clean facilitant l'integration LLM.

Pour les equipes avec des contraintes de conformite (analyse de malwares clients confidentiels), le LLM local via Ollama est le seul choix acceptable. Pour les equipes de threat intelligence publique, l'API Claude ou GPT-4 offre generalement une meilleure qualite d'analyse.

Cas reel -- analyse ransomware BlackSuit et Nitrogen 2026

L'analyse des ransomwares BlackSuit et Nitrogen en 2026 illustre l'efficacite reelle des pipelines LLM. BlackSuit, actif depuis 2023 et evolution de Royal ransomware, utilise un chiffrement hybride RSA-AES avec des cles uniques par victime. Le pipeline Ghidra + LLM a permis d'identifier en 18 minutes : les routines de chiffrement AES-256 et RSA-4096, les mecanismes d'anti-analyse (IsDebuggerPresent, timing checks), les chemins de persistance (HKCU/Software/Microsoft/Windows/CurrentVersion/Run), et les domaines C2 hardcodes XOR-encodes. L'analyse manuelle de la meme souche necessiterait 4 a 6 heures pour un analyste experience. Nitrogen, un loader utilise pour distribuer BlackCat/ALPHV, utilise quant a lui une technique de side-loading DLL particulierement difficile a detecter. Le LLM a identifie le pattern de LoadLibrary atypique et le path de DLL hijacking en analysant les imports anormaux et les appels SetCurrentDirectory precedant les LoadLibrary. Pour les aspects de detection de ces menaces dans votre SOC, consultez notre article sur le SOC augmente par IA.

Limites et hallucinations sur le desassemblage

Les hallucinations LLM sur le desassemblage sont le risque principal de cette approche et doivent etre geres avec rigueur. Les sources d'hallucinations incluent :

• Mauvaise interpretation du pseudo-C Ghidra : Ghidra produit parfois un pseudo-C non standard que le LLM peut mal interpreter, concluant a une fonctionnalite incorrecte
• Confusion entre techniques similaires : le LLM peut confondre une routine de compression legitime avec du chiffrement C2, ou un mutex de singleton application avec un mutex d'anti-sandboxing
• Confabulation d'IOC : le LLM peut "voir" des domaines ou des IPs dans du code qui n'en contient pas, en extrapolant incorrectement des chaines encodees
• Identification incorrecte de la famille de malware : des techniques similaires sont utilisees par des familles differentes ; le LLM peut faire des attributions incorrectes

Les regles de validation pour contrer ces hallucinations : toujours verifier manuellement les IOC "decouverts" par le LLM en cherchant les chaines correspondantes dans le binaire brut (strings + grep), valider les classifications de fonctions critiques avec une analyse manuelle, et utiliser plusieurs LLM en parallele et comparer les resultats (consensus analysis). Pour les aspects de membership inference et de reconstruction de donnees d'entrainement, voir notre article sur les membership inference attacks.

Analyse de packers et d'obfuscation avancee

L'analyse des packers et de l'obfuscation avancee par LLM presente des defis specifiques. Les packers (UPX, Themida, VMProtect, Obsidium) modifient la structure du binaire de telle sorte que le code original n'est pas visible avant l'execution (unpacking en memoire). Le LLM peut aider a identifier le packer utilise via les signatures du stub d'entry point, guider le processus d'unpackage (identification du OEP -- Original Entry Point), et analyser le code unpacke resultant. Pour l'obfuscation a base de code virtualization (VMProtect, Code Virtualizer), le LLM peut analyser le bytecode VM et tenter de reconstruire la semantique des instructions virtualisees, bien que cette tache reste l'une des plus difficiles et avec le plus haut taux d'hallucinations. Des outils specialises comme ScyllaHide (anti-anti-debug) et x64dbg avec des scripts Python sont utilises conjointement avec le LLM pour le dynamic unpacking et l'analyse comportementale complementaire a l'analyse statique Ghidra. La combinaison analyse statique LLM (Ghidra) et analyse dynamique (sandbox + traces d'execution) donne les meilleurs resultats sur les echantillons fortement obfusques. Pour les aspects de detection des malwares packes dans votre infrastructure, notre article sur le LLM et analyse reseau Wireshark complete cette approche avec la detection comportementale reseau des malwares actifs. La politique de securite concernant le traitement des echantillons malware doit etre documentee dans votre PSSI.

FAQ -- LLM et reverse engineering malware

Qu'est-ce que l'analyse malware automatisee par LLM apporte par rapport a l'analyse manuelle ?

L'analyse malware automatisee par LLM apporte trois avantages principaux par rapport a l'analyse manuelle. La vitesse : un pipeline Ghidra + LLM peut produire une analyse initiale complete en 15 a 30 minutes, contre 4 a 8 heures pour un analyste experience. La couverture : le LLM analyse systematiquement toutes les fonctions du binaire, sans les biais de selection humaine qui tendent a se concentrer sur les fonctions au nom reconnaissable. L'accessibilite : un analyste de niveau intermediaire peut obtenir une analyse de qualite proche de celle d'un expert en utilisant le LLM comme guide et explicateur. Les limites sont complementaires : le LLM excelle sur l'analyse initiale et l'extraction d'information structuree, l'analyste humain reste indispensable pour les binaires fortement obfusques, les techniques vraiment nouvelles non representees dans les donnees d'entrainement, et la validation critique des conclusions LLM avant leur integration dans des IOC de production.

Comment Ghidra s'integre-t-il avec les LLM en pratique ?

L'integration de Ghidra avec les LLM se fait via deux approches complementaires. L'approche headless utilise Ghidra en mode ligne de commande (analyzeHeadless) avec des scripts Python qui exportent le code decompile au format JSON, puis un script Python separé traite ces sorties et les soumet au LLM. Cette approche est ideale pour l'automatisation en pipeline CI/CD ou sandbox. L'approche interactive utilise des plugins Ghidra comme GhidrAssist (GitHub) qui integrent directement un LLM dans l'interface graphique Ghidra, permettant de selectionner une fonction, de demander une explication ou une classification, et de recevoir la reponse directement dans l'interface. La combinaison des deux approches est optimale : pipeline headless pour l'analyse initiale automatisee, interface interactive pour l'approfondissement sur les fonctions complexes.

Pourquoi les LLM hallucinent-ils sur le code desassemble ?

Les LLM hallucinent sur le code desassemble pour plusieurs raisons fondamentales. Premierement, le pseudo-C produit par les decompilateurs comme Ghidra est syntaxiquement proche du C standard mais semantiquement different : des constructions comme les goto, les tableaux de pointeurs de fonctions non resolus et les structures auto-referencees peuvent tromper le LLM. Deuxiemement, les LLM ont ete entraines principalement sur du code source "propre" (GitHub, StackOverflow) et ont moins d'exposition au pseudo-C de decompilateur, rendant leur comprehension moins robuste sur ce format specifique. Troisiemement, les techniques d'obfuscation intentionnelle (code virtualization, opaque predicates, dead code insertion) sont precisement conçues pour etre difficiles a analyser, meme pour des systemes expert. La validation systematique des conclusions LLM est donc non negociable pour une analyse malware de qualite production.

Quelle difference entre Ghidra et IDA Pro pour l'analyse LLM ?

Ghidra (NSA, open source et gratuit) et IDA Pro (Hex-Rays, commercial a 3000-4000 euros/an) different principalement par la qualite de leur decompilateur. IDA Pro avec Hex-Rays produit generalement un pseudo-C de meilleure qualite sur les binaires complexes (x64, ARM64, MIPS), avec moins d'artefacts de decompilation qui induisent les LLM en erreur. Ghidra est superieur en termes de support des architectures exotiques (microcontroleurs, PLC) et d'extensibilite via ses scripts. Pour l'analyse LLM, la meilleure qualite de decompilation d'IDA Pro se traduit directement par une meilleure precision des analyses LLM. Cependant, pour la majorite des malwares Windows x64, Ghidra produit des resultats suffisants et son cout nul le rend particulierement attractif pour les equipes avec des contraintes budgetaires.

Quels modeles LLM sont les plus performants pour l'analyse malware ?

Les modeles LLM les plus performants pour l'analyse malware en 2026 sont ceux qui combinent une forte capacite de raisonnement sur le code et une bonne connaissance des techniques de programmation systeme Windows. Claude Opus 4.7 (Anthropic) se distingue par sa comprehension fine du code C et son raisonnement sur les APIs Windows, mais pose des problemes de confidentialite si utilise sur des echantillons client. Llama 3.3 70B (Meta) en local via Ollama offre un excellent compromis entre performance et confidentialite pour les deployements enterprise. GPT-4o (OpenAI) presente une bonne performance generale mais des hallucinations plus frequentes sur le code fortement obfusque. Pour les cas d'usage specifiques (analyse de shellcode, analyse de macros VBA, analyse de scripts PowerShell), des modeles specialises fine-tunes sur des datasets de code malveillant (CodeBERT, CySecBERT) peuvent surpasser les modeles generalistes.

Conclusion

L'analyse malware assistee par LLM est passee du stade experimental a la pratique professionnelle en 2025-2026. Les pipelines Ghidra + LLM local deployables open source permettent a des equipes de taille modeste d'analyser des volumes de malwares precedemment impossibles a traiter. La cle est de traiter le LLM comme un premier analyste rapide qui produit une analyse initiale a valider, plutot que comme un oracle infaillible. Integrez ces pipelines dans vos workflows d'analyse, mais maintenez toujours la validation humaine sur les IOC de production et les classifications de securite critiques. Notre guide sur le pentest complet et notre article sur le red teaming LLM completent cette methodologie.