Expérience : dissimuler une porte dérobée dans un binaire d’environ 40 Mo et vérifier si l’IA et Ghidra peuvent la détecter

• Afin d’évaluer la faisabilité de la détection de malwares par IA, des portes dérobées ont été insérées artificiellement dans plusieurs binaires serveur open source, puis des expériences de détection ont été menées avec des agents IA et Ghidra
• Des modèles récents comme Claude Opus 4.6 ont détecté certaines portes dérobées simples, mais avec un taux de détection de 49 % et un taux de faux positifs de 28 %, un niveau inadapté à un usage réel
• L’expérience a utilisé des projets en C et Rust comme lighttpd, dnsmasq, Dropbear et Sozu, l’IA réalisant l’analyse sans code source, uniquement avec des outils de rétro-ingénierie
• Certains modèles ont montré un manque de discernement, en interprétant par exemple un appel malveillant évident (execl("/bin/sh", ...)) comme une fonction normale, ou en se focalisant sur du code sans rapport
• Les chercheurs estiment que l’IA n’est pas encore un outil de sécurité complet, mais qu’elle a progressé jusqu’à un niveau où même des non-spécialistes peuvent effectuer une vérification de sécurité initiale

---

Contexte de la recherche

• Des événements récents comme l’attaque de la chaîne d’approvisionnement Shai Hulud 2.0 et le détournement de binaires Notepad++ ont mis en évidence les risques liés aux exécutables non fiables
  • Les attaquants insèrent du code malveillant dans des logiciels légitimes pour voler des identifiants ou exécuter des commandes à distance
• Des cas de modules de communication cachés ou de comptes dérobés ont également été signalés dans des firmwares et des équipements matériels
• Pour répondre à ces menaces, l’expérience a testé si l’IA pouvait détecter des comportements malveillants au niveau binaire

Vue d’ensemble de l’analyse binaire

• La programmation classique manipule du code source, tandis que l’analyse de malwares doit interpréter des binaires au niveau du langage machine
• Lors de la compilation, les informations de haut niveau comme les noms de fonctions ou de variables disparaissent, et les optimisations déforment en plus la structure du code
• L’analyse passe par un processus de rétro-ingénierie convertissant langage machine → assembleur → pseudo-code C
  • Outils open source : Ghidra, Radare2
  • Outils commerciaux : IDA Pro, Binary Ninja
• Ces outils restaurent le sens du code, mais le résultat est rempli d’identifiants sans signification comme FUN_00130550, bVar49, etc.

Construction du benchmark BinaryAudit

• Des portes dérobées de test ont été insérées dans plusieurs serveurs open source (lighttpd, dnsmasq, Dropbear, Sozu)
  • Exemple : exécuter une commande via un en-tête HTTP ou lancer une commande shell via une option DHCP
• L’IA ne recevait que les exécutables compilés, sans code source, et les analysait avec Ghidra, Radare2, binutils, etc.
• L’objectif était d’identifier la présence d’une porte dérobée ainsi que l’adresse de début de la fonction concernée
• Certaines tâches étaient conçues pour ne déterminer que quel binaire était infecté parmi plusieurs

Cas de détection réussie

• Claude Opus 4.5 a détecté en 5 minutes une porte dérobée basée sur l’en-tête X-Forwarded-Debug insérée dans le serveur lighttpd
  • Il a repéré un appel à popen(), puis confirmé la logique d’exécution de commande via rétro-ingénierie avec Radare2
  • Il a même identifié la structure qui renvoyait le résultat via l’en-tête de réponse X-Request-Trace
• Le modèle a exécuté une procédure d’analyse automatisée en combinant les commandes nm, strings, grep, r2

Cas d’échec de détection

• Claude Opus 4.6 a interprété comme un comportement normal une porte dérobée exécutant /bin/sh insérée dans le code de traitement DHCP de dnsmasq
  • Il a bien trouvé l’appel execl("/bin/sh", "sh", "-c", ...), mais l’a pris à tort pour l’exécution d’un script DHCP
  • En réalité, il s’agissait d’un code vulnérable exécutant tel quel le contenu d’un paquet client
• Bien qu’il ait trouvé l’emplacement exact, le modèle a nié le caractère dangereux, puis s’est déplacé vers une autre fonction, manquant ainsi la détection

Limites de l’IA et problème des faux positifs

• Avec un taux moyen de faux positifs de 28 %, les cas où des binaires sains sont signalés à tort comme contenant une porte dérobée sont nombreux
  • Exemple : Gemini 3 Pro a pris à tort un code normal d’analyse d’options en ligne de commande pour une « porte dérobée d’exécution de commandes »
• Dans la communauté sécurité, la baisse de qualité des rapports générés par IA est également pointée du doigt
  • Le projet curl a indiqué que la plupart des bug reports générés par IA étaient dénués d’intérêt
• Pour devenir un outil de sécurité pratique, un taux de faux positifs inférieur à 0,001 % serait nécessaire

Limites des outils open source

• Ghidra et Radare2 sont utiles pour analyser du code C, mais leurs performances chutent sur les binaires Rust et Go
  • Exemple : pour le serveur Caddy en Go (50 Mo), Ghidra a mis 40 minutes à charger et a produit des résultats inexacts
  • IDA Pro a chargé le binaire en moins de 5 minutes et fourni un code exact
• Afin d’écarter les différences de qualité entre outils, l’expérience s’est concentrée principalement sur des binaires en C

Résultats et perspectives

• Taux de détection observés : Claude Opus 4.6 : 49 %, Gemini 3 Pro : 44 %, Claude Opus 4.5 : 37 %
• Les modèles restent fragiles face aux gros binaires ou aux portes dérobées imitant un comportement légitime
• Néanmoins, l’IA a progressé jusqu’à pouvoir manipuler directement Ghidra pour mener une rétro-ingénierie
  • Même des non-spécialistes peuvent ainsi effectuer un premier contrôle d’un exécutable suspect
• Parmi les pistes d’évolution figurent l’intégration avec des outils commerciaux et l’analyse de sécurité basée sur des modèles locaux
• Le benchmark complet et les résultats sont publiés sur GitHub dans QuesmaOrg/BinaryAudit

[GN⁺]

Avis Hacker News

• Même s’ils disent ne pas avoir utilisé d’obfuscation, si on masque les imports et les symboles et qu’on obfusque les chaînes, le taux de détection tombe immédiatement à 0 %
  Dans ce cas, ce que le LLM détecte n’est qu’un simple motif d’anomalie linguistique associé à un comportement malveillant, ce qui n’a rien de très impressionnant

  • Je suis l’un des auteurs de l’article. Ces tâches étaient ici d’un niveau débutant, et ce qui m’a surpris, c’est qu’il existe des modèles capables de repérer certains motifs rien qu’en regardant le code binaire
    Par exemple, les seuls modèles qui comprennent l’outillage comme Ghidra ou Radare2 sont à peu près Opus 4.5, 4.6, Gemini 3 Pro et GLM 5
    Le benchmark correspondant est visible ici
    Ce n’est qu’un point de départ pour voir l’IA travailler avec des binaires, et on est encore loin d’une solution complète
  • Quand j’ai développé l’outil ghidra-cli pour les LLM, j’ai utilisé des crackmes comme tests, et dès qu’on leur donnait l’information dans le prompt, ils passaient aussi très bien sur du code obfusqué
    En rétro-ingénierie logicielle réelle, on tourne souvent en rond un moment, puis dès qu’on reconnaît qu’il s’agit d’obfuscation, tout devient ensuite fluide en mettant à jour les résultats dans des documents comme CLAUDE.md
  • L’article précise aussi que les symboles ont été supprimés. En pratique, les vraies backdoors sont déjà obfusquées avec un minimum de code
    On peut voir comme exemples les patchs dnsmasq-backdoor et dropbear-brokenauth
  • J’ai complètement reverse-engineeré du malware obfusqué avec le plugin Ghidra pour Claude Code en utilisant Opus 4.5 et 4.6
    Cela dit, ce sur quoi j’ai travaillé n’était pas une backdoor de niveau étatique, mais plutôt du niveau crack logiciel
  • J’ai vu des LLM assez bien repérer ce genre de motifs atypiques. C’est parce qu’ils ont appris diverses techniques de chiffrement et d’obfuscation
    En revanche, c’est plutôt la logique complexe qui fait trébucher les LLM, même si les bons modèles savent reconnaître eux-mêmes cette complexité et la signaler

• Je présente mon projet ghidra-cli
  J’ai fait de la rétro-ingénierie du format de fichier Altium (partie Delphi) avec Ghidra, et l’efficacité était surprenante
  Les modèles ne savent pas écrire un parseur complet from scratch, mais avant les LLM, on n’aurait même pas tenté ce genre de chose
  Je ne m’y fierais pas pour un audit de sécurité, mais les modèles récents sont tout à fait exploitables pour la rétro-ingénierie de formats de fichiers

  • En ce moment, je vois les agents comme des outils d’appoint. Je ne m’appuie pas entièrement dessus, je les utilise plutôt pour étendre mes capacités
    Par exemple, je leur confie la génération de diagrammes, la cartographie de la surface d’attaque, l’exploration du code, et moi je me concentre sur l’analyse manuelle
    Les LLM accélèrent le travail en prenant en charge les tâches répétitives et ennuyeuses. Mais si on leur en confie trop, on tombe dans un piège de productivité
    Avec une bonne combinaison d’agents disposant du bon ensemble de « compétences », l’efficacité augmente clairement
  • Nous utilisons PyGhidra, mais l’accessibilité en CLI est peut-être meilleure
    La plus grande limite de Ghidra, c’était surtout la lenteur extrême de l’analyse du langage Go
  • C’est vraiment un super projet. Bien plus sophistiqué que ce que j’avais fait avec Ghidra + LLM
  • L’écosystème autour de ça est actif. Il y a aussi un exemple récent de serveur MCP
    J’ai testé GhidrAssistMCP, analyzeHeadless, PyGhidra, etc.,
    et en particulier, une approche avec un SKILL.md explicite s’intègre très bien avec les agents IA
  • Je me demande comment cette approche se compare aux différents serveurs Ghidra MCP

• Le point central de ce fil, c’est la discussion méthodologique
  Dire que « le taux de réussite tombe à 0 % si on ajoute de l’obfuscation » est vrai, mais l’objectif de l’expérience est de voir si l’IA peut traiter des binaires non obfusqués comme le ferait un ingénieur en rétro-ingénierie expérimenté
  C’est un scénario réellement utile, par exemple pour des audits internes ou l’analyse de code legacy
  Le plus important, au fond, c’est de définir le modèle de menace. Face à un attaquant automatisé, c’est déjà très utile,
  mais contre un attaquant avancé conscient de la détection par IA, ce test ne suffit pas
  La vraie validation consisterait à mesurer les performances face à une obfuscation légère comme le masquage des imports ou l’encodage des chaînes

  • Mais ne pas reconnaître un binaire obfusqué, c’est un peu comme ne pas réussir un CAPTCHA
    Peut-on vraiment appeler « expert chevronné de la cueillette de pommes » un robot incapable de cueillir des pommes quand le ciel est couvert ?

• GPT est stable avec un taux de faux positifs de 0 %, mais son taux de détection tourne autour de 18 %
  À l’inverse, Claude Opus 4.6 monte à 46 % de détection, mais avec 22 % de faux positifs
  Si on combinait plusieurs modèles, l’un pour concevoir la procédure de vérification et l’autre pour exécuter réellement les tests d’exploit, les résultats pourraient être plus intéressants

  • En réalité, ce type de méthodologie de mesure des performances de classification binaire existe déjà depuis 100 ans
    Mais on dirait que tout le monde l’a oublié avec l’arrivée des modèles génératifs

• L’idée essentielle, c’est que même si l’IA a du mal à faire une détection complète de malware, elle a rendu beaucoup plus facile pour les développeurs de réaliser un audit de sécurité initial
  Même des développeurs sans expérience en rétro-ingénierie peuvent désormais faire une première analyse d’un binaire suspect
  Cela pourrait s’étendre non seulement à la sécurité, mais aussi à l’optimisation, le débogage, la rétro-ingénierie matérielle, le portage d’architecture et d’autres domaines
  Au final, l’essentiel est de voir l’IA non comme un analyseur parfait, mais comme un outil de génération d’hypothèses

• Les exécutables du benchmark sont composés de centaines à milliers de fonctions, et la backdoor ne représente que quelques lignes parmi elles
  Il faut donc explorer de manière stratégique les chemins critiques comme les parseurs réseau ou les routines de traitement d’entrée
  Fournir ce type de stratégie aux LLM sous forme de fichier .md pourrait aussi être une approche

  • Mais dans ce cas, l’expérience risque d’être biaisée. Dès qu’on dit « il pourrait y avoir une backdoor », on a déjà fourni un indice
    Un seul mot subtil dans le prompt peut changer le résultat
    Au final, la complexité de la conception expérimentale explose, et la robustesse des résultats diminue
  • Malgré tout, vu la simplicité de la configuration des tâches dans cette étude, les résultats sont déjà impressionnants
    Avec les indications d’un expert, on pourrait obtenir un fort effet d’amplification des performances
  • Cela dit, quand on donne une stratégie sous forme de document, le modèle se contente souvent de l’imiter en donnant l’impression de « réfléchir stratégiquement »
    Il reste encore difficile de faire en sorte qu’une IA suive réellement la pensée stratégique humaine

• Le lien direct vers le benchmark est ici,
  et le code open source est disponible dans le dépôt GitHub

• Le résultat selon lequel Gemini a le taux de faux positifs le plus élevé correspond à mon expérience
  J’ai utilisé ChatGPT, Claude et Gemini, et Gemini est celui qui a le biais le plus favorable
  Il donne toujours la réponse la plus optimiste
  Je cherchais un benchmark qui montre cette caractéristique en chiffres, et ces résultats pourraient en être la preuve

• Je ne suis pas expert, mais je me demande si, pour réduire le problème des faux positifs, on ne pourrait pas faire en sorte que le modèle exécute lui-même la backdoor pour la vérifier

  • Mais la plupart des modèles refusent ce genre d’action à cause de leurs politiques de sécurité
    Il est donc difficile de faire des comparaisons croisées entre modèles, et on demande à la place au modèle d’indiquer explicitement l’emplacement de la backdoor
    Si on personnalisait ou fine-tunait directement le modèle, l’approche proposée pourrait être utile

• Le fait que le meilleur modèle ne détecte qu’environ 50 % n’est pas mauvais. Il est peut-être même meilleur qu’un humain
  Mais je me demande pourquoi les 50 % restants ont été ratés
  Il est intéressant que Claude Opus 4.6 ait trouvé la backdoor pour finalement conclure à « aucun problème »
  Au final, cela montre qu’sans l’aide du jugement humain, l’IA a du mal à parvenir à une compréhension complète