Analyser un binaire avec un agent IA : ce que REA change vraiment

Quand une entreprise doit comprendre le comportement d’un logiciel compilé sans disposer de son code source, un agent de codage ne peut pas simplement « lire » l’application comme un projet classique. Reverse Engineer Anything (REA) propose de le connecter à des outils spécialisés pour explorer le binaire. Pour un responsable IT, la question utile n’est pas de savoir si l’agent peut remplacer l’analyse humaine, mais s’il facilite une investigation précise et vérifiable.

Dans son article du 17 octobre 2026, InfoQ présente le fonctionnement et les démonstrations de REA. Le projet relie des agents de codage comme Claude Code et Codex à des outils de rétro-ingénierie tels que Ghidra, Hopper et IDA.

De la question métier à l’exploration du binaire

Reverse Engineer Anything (REA) relie des agents de codage, dont Claude Code et Codex, à des outils de rétro-ingénierie tels que Ghidra, Hopper et IDA pour explorer des binaires compilés.

Le mécanisme repose sur des serveurs MCP. MCP est un protocole qui permet à un agent d’accéder à des outils par une interface définie. Concrètement, les serveurs MCP exposent les fonctions des outils : l’agent peut interroger un désassembleur, examiner des fonctions et leurs références croisées, suivre le comportement d’un programme, puis confronter des hypothèses au binaire de manière itérative. L’agent propose donc des pistes à tester dans l’outil ; cette boucle ne dispense pas de vérifier les résultats.

InfoQ indique aussi que REA prend en charge l’analyse statique de JavaScript et d’applications Electron, ainsi que d’assemblies .NET ; ces investigations peuvent s’effectuer sans moteur d’analyse natif. InfoQ précise que REA fonctionne localement et ne prétend pas récupérer le code source original.

Un cas fictif pour cadrer une investigation

Imaginons une PME qui doit comprendre une fonction précise d’une application ancienne, mais qui n’a pas accès à son code source. Ce scénario est hypothétique : il ne décrit pas un client ni un résultat observé. Avant de choisir un outil, l’équipe devrait transformer l’irritant en question testable : quel comportement veut-elle éclaircir, sur quelle version du programme, et avec quel élément de comparaison ?

Une demande comme « comprendre toute l’application » est difficile à borner. Une question plus étroite — par exemple, déterminer comment une fonction donnée traite une entrée dans un environnement de test autorisé — facilite la définition du périmètre et des preuves attendues. REA peut aider à explorer les fonctions et leurs liens ; il ne constitue pas, à lui seul, une explication validée du système métier.

La démarche de l’équipe pourrait être de fournir à l’agent une cible et un résultat attendu, puis de faire examiner les fonctions pertinentes avec l’outil de rétro-ingénierie. Chaque hypothèse utile devrait être confrontée au comportement du binaire et consignée avec le contexte de l’essai. Cette discipline importe particulièrement si les conclusions doivent guider une maintenance ou une décision d’achat.

Ce que les démonstrations établissent, et ce qu’elles n’établissent pas

Les exemples publiés par le projet donnent une idée des tâches montrées. Parmi les démonstrations citées, REA suit l’implémentation du presse-papiers de Notion dans Electron et reconstruit une fonction de panoramique sonore de DX-Ball, avec des tests couvrant les 3 205 cas x86 d’origine et les 63 octets compilés de la fonction. InfoQ mentionne aussi une reconstruction de calculs d’angles de projectiles à partir du code 16 bits du jeu DOS Touhou 4.

Ces résultats sont des démonstrations rapportées par InfoQ, et non une mesure indépendante de fiabilité pour un logiciel métier. Dans l’exemple de DX-Ball, les tests correspondent à la fonction présentée ; cela ne prouve pas qu’un agent reconstruira de la même manière une application complète, des règles métier ou un système insuffisamment documenté. Le périmètre d’un résultat doit rester attaché à la fonction, au binaire et aux tests concernés.

Arbitrer avant d’engager du temps ou des données

Le projet est publié sous licence MIT, et son fonctionnement local est un élément à prendre en compte. Ni l’un ni l’autre ne suffit à décider qu’un essai convient à une entreprise : il faut aussi cadrer les autorisations d’analyse, la confidentialité du binaire, les outils utilisés et les personnes qui valideront les conclusions.

Les coûts sont à estimer selon le périmètre réel : temps d’installation et de configuration, disponibilité ou licence des outils associés, temps d’analyse humaine, environnement de test et documentation à produire. Les informations disponibles ne permettent pas de chiffrer ces postes.

InfoQ rappelle que les utilisateurs doivent disposer des autorisations nécessaires et respecter les lois applicables. Ce point doit être traité avant toute analyse, en particulier si le logiciel appartient à un tiers ou si le binaire contient des éléments sensibles.

Pour une reprise applicative plus large, cette investigation peut compléter, mais ne remplace pas, un audit de maintenabilité applicative portant sur le code, les dépendances et l’exploitation.

Checklist avant un essai encadré

Avant d’évaluer un agent IA pour l’analyse d’un binaire, l’équipe peut consigner les décisions suivantes :

• Définir une question limitée et le comportement précis à éclaircir.
• Confirmer l’autorisation d’analyser le binaire et les conditions applicables.
• Identifier le format à examiner et vérifier la compatibilité avec les outils envisagés, parmi Ghidra, Hopper ou IDA.
• Déterminer quelles données peuvent être utilisées dans l’environnement d’analyse et qui y aura accès.
• Définir comment une hypothèse sera vérifiée, par exemple avec un comportement de référence ou des tests ciblés.
• Prévoir un livrable distinguant les observations, les hypothèses de l’agent et les conclusions validées par l’équipe.
• Estimer le temps de préparation, d’analyse et de revue avant de décider si l’essai mérite d’être poursuivi.

Un essai utile devrait ainsi répondre à une question circonscrite, conserver les éléments permettant de vérifier les conclusions et expliciter ce qui reste incertain. Si la seule promesse attendue est de retrouver le code original, REA ne la formule pas : InfoQ précise que le projet ne prétend pas récupérer ce code. Le bon critère de décision est plutôt la valeur d’une investigation ciblée, au regard de son coût, de ses autorisations et des preuves que l’équipe peut réellement examiner.