L'agent au désassembleur : REA, GhidraMCP et ce que CrackMeBench en dit

La rétro-ingénierie a vécu un mois étrange. En octobre 2026, pointer un agent de code sur un binaire est passé de la démonstration à la boîte à outils : REA (« Reverse Engineer Anything ») est sorti sous licence MIT et relie Claude Code, Codex, Cursor, Gemini CLI ou Grok Build à Ghidra, Hopper ou IDA via le Model Context Protocol ; l'index communautaire des projets de rétro-ingénierie assistée par IA a dépassé 120 dépôts, dont 74 serveurs ou plugins MCP ; JEB 5.48 et Ghidra 12.1 sont arrivés ; et trois articles ont mesuré, sans emballement, ce que ces agents savent et ne savent pas faire. Voici l'état des lieux au 27 octobre 2026, avec les chiffres qui comptent et les erreurs à éviter.

Le mois en dates

À quoi ressemble la pile

Toutes les installations du moment ont les mêmes quatre couches, et la synthèse publiée sur DEV Community compte quatre endroits où ça casse avant le premier prompt : le client agent, le serveur MCP, l'extension du moteur, le moteur lui-même.

REA est le plus large des serveurs : au-delà du pseudo-code, des chaînes, des symboles et des références croisées sur du code natif, il lit les bundles Electron (modules, source maps, IPC entre renderer, preload et main), les métadonnées et le CIL .NET, les manifestes et méthodes décompilées d'APK, les régions extraites d'un firmware, les réglages de build Go, le WebAssembly, les captures sauvegardées et même des crashs Linux enregistrés. L'analyse native profonde exige toujours un Ghidra, Hopper ou IDA installé ; Android demande jadx et un JDK ; l'extraction de firmware demande Binwalk ou Unblob sous Linux. Son propre avertissement refuse le contournement de DRM, les cheats et les contournements de licence, et sa documentation dit clairement qu'une analyse locale n'est pas une analyse hors ligne : les résultats des outils partent chez le fournisseur du modèle.

Les agents sont-ils bons ? Trois mesures

CrackMeBench (arXiv 2605.10597) construit des CrackMes depuis des gabarits C, Rust et Go, donne à l'agent un bac à sable Docker sans réseau, cinq minutes par tâche et trois soumissions notées ; le score est un générateur de série ou de clé que le binaire accepte.

La chute entre les CrackMes générés et les publics est le résultat : sur les huit vrais, le meilleur modèle en résout trois. Reveree arrive à la même conclusion par un autre chemin : sur 88 épreuves de picoCTF et NYU-CTF, le modèle de base compte plus que la stratégie de prompt, les modèles plus gros ou plus récents ne sont pas systématiquement meilleurs, et les échecs se concentrent aux étapes de compréhension, où davantage de budget, de persistance ou d'effort de raisonnement ne sauve presque rien. L'article montre aussi la mémorisation : les modèles reproduisent des flags picoCTF à partir de la seule description, tandis que NYU-CTF ne montre presque aucun rappel. L'état de l'art d'avril liste les limites structurelles : budgets de tokens, code obfusqué, et garde-fous faibles autour des programmes analysés.

Une première session qui fonctionne

L'étude de cas de Quesma est le gabarit honnête : une ROM Atari River Raid de 8 Ko, chargée comme du code 6502 brut, objectif vies infinies. Claude a identifié la plateforme, trouvé la routine des vies et proposé le patch ; un humain l'a appliqué avec dd. Il a aussi cru que le jeu était Centipede, n'a pas su rebaser le programme quand Ghidra l'a chargé à la mauvaise adresse, et certains appels d'outil ont pris trente secondes.

Là où ça mord

Un binaire est une entrée non fiable, et c'est désormais une entrée non fiable pour un modèle qui exécute des outils. L'état de l'art d'avril juge faibles les garde-fous autour des programmes analysés ; la synthèse DEV décrit des chaînes placées dans des binaires pour manipuler l'agent.

En pratique

Le résumé honnête pour une équipe sécurité en octobre 2026 : l'agent est un analyste junior rapide qui ne dort jamais, ment sans ciller, et doit rester dans une VM. Confiez-lui le tri, le nommage et l'explication des motifs connus ; gardez le patch, le retypage et les conclusions pour des humains. Le billet suivant regarde l'autre moitié de l'histoire : ce que les décompilateurs LLM eux-mêmes réussissent et ratent.