Analyser un binaire avec un agent IA : ce que Reverse Engineer Anything relie vraiment

Reverse Engineer Anything (REA) relie des agents de programmation, dont Claude Code et Codex, à des outils d’analyse comme Ghidra, Hopper et IDA. Le compte rendu d’InfoQ publié le 17 octobre 2026 décrit un projet open source destiné à inspecter des binaires compilés et à suivre des fonctions ou des comportements ; il précise aussi que REA ne prétend pas retrouver le code source original. Le compte rendu d’InfoQ sur Reverse Engineer Anything.

Pour un développeur, l’intérêt n’est donc pas de demander à un agent de « décompiler l’application » comme si le résultat restituait le dépôt d’origine. Il s’agit plutôt de l’aider à explorer des éléments observables du programme compilé et à confronter des hypothèses à l’analyse. Cette distinction change la manière d’évaluer le projet : il faut regarder quelles pistes l’agent peut explorer, puis quelles preuves permettent à une personne de vérifier ses conclusions.

1. Distinguer l’agent du moteur d’analyse

REA utilise des serveurs MCP pour exposer des outils de rétro-ingénierie à des agents. Le compte rendu décrit des actions comme interroger un désassembleur, examiner des fonctions et leurs références croisées, suivre le comportement d’un programme et tester des hypothèses à partir du binaire. MCP sert ici de liaison entre l’agent et ces outils ; il ne transforme pas à lui seul une interprétation produite par l’agent en résultat fiable. Pour situer ce rôle de liaison, voir aussi notre article sur MCP et ses usages pour les développeurs.

La boucle de travail décrite est importante : l’agent formule ou affine une piste, consulte les éléments accessibles par les outils, puis poursuit l’examen. Un développeur qui évalue REA devrait donc pouvoir séparer les observations issues du désassembleur des explications rédigées par l’agent. Si une réponse affirme qu’une fonction remplit un rôle précis, la question utile est : quelles instructions, références ou traces de comportement étayent cette interprétation ?

2. Choisir le périmètre avant d’essayer

Les outils mentionnés ne sont pas interchangeables par défaut. InfoQ indique que REA se connecte à Ghidra, Hopper et IDA. Le projet couvre également l’analyse statique d’applications JavaScript et Electron ainsi que d’assemblages.NET ; selon le compte rendu, cette analyse peut se faire sans moteur d’analyse natif. Ce sont des périmètres rapportés, pas la promesse qu’un même parcours ou la même profondeur d’analyse s’applique à chaque cible.

Cette grille est un protocole d’évaluation proposé, pas le compte rendu d’un essai exécuté. Avant de lancer une analyse, choisissez une question assez circonscrite pour que les éléments examinés puissent être relus : par exemple, localiser le chemin associé à une fonctionnalité donnée, plutôt que demander une compréhension complète d’une application.

3. Lire les démonstrations comme des exemples, pas comme un benchmark

Les showcases du projet cités par InfoQ illustrent des tâches différentes : suivre l’implémentation du presse-papiers dans Notion, reconstituer une fonction de panoramique sonore du jeu DX-Ball, ou retrouver des calculs d’angles dans du code 16 bits de Touhou 4. Pour la fonction de DX-Ball, le compte rendu rapporte des tests correspondant aux 3 205 cas x86 d’origine et aux 63 octets de fonction compilée. C’est un exemple concret de validation sur un cas précis ; cela ne constitue pas, à lui seul, une comparaison générale des agents ou une garantie pour d’autres binaires.

Pour reproduire l’évaluation dans votre propre contexte, consignez la cible autorisée, le format analysé, l’outil utilisé, la question posée et les éléments qui permettent de vérifier la réponse. Quand un résultat peut être testé indépendamment, définissez à l’avance ce qui compterait comme confirmation ou échec. Une explication convaincante ne remplace pas cette vérification.

4. Séparer les faits observés des hypothèses

Imaginez, à titre purement hypothétique, qu’une équipe cherche quelle fonction d’un ancien programme participe à une opération de copie. Elle peut demander à l’agent d’explorer les références pertinentes, puis examiner les éléments remontés dans l’outil. Une première piste n’établit pas encore que la fonction réalise toute l’opération : elle peut seulement justifier une étape d’enquête supplémentaire. Le compte rendu de l’évaluation devrait conserver cette différence entre observation, hypothèse et conclusion validée.

Cette discipline est d’autant plus utile que l’on peut demander à un agent de résumer une chaîne d’analyse en langage naturel. Pour garder une trace exploitable, associez chaque affirmation importante à l’élément technique qui la soutient et notez ce qui reste incertain. L’article d’InfoQ rapporte aussi des interrogations de praticiens sur ce que REA apporte par rapport à l’usage direct de Ghidra avec un agent. La question mérite d’être posée lors d’une évaluation : le projet simplifie-t-il réellement le parcours ciblé, ou faut-il comparer ce parcours à une configuration directe ? Le compte rendu ne fournit pas de mesure indépendante permettant de trancher cette comparaison.

5. Vérifier l’autorisation et les limites d’usage

Le fait qu’un outil fonctionne localement ne donne pas automatiquement le droit d’analyser n’importe quel logiciel. InfoQ indique que REA est publié sous licence MIT et rapporte que ses utilisateurs restent responsables d’obtenir les autorisations nécessaires et de respecter les lois applicables. Avant une analyse, définissez donc le périmètre autorisé et les conditions d’accès au binaire. Ne confondez pas la licence du projet avec les droits portant sur le programme examiné.

En pratique, REA se comprend comme une couche qui donne à des agents un accès outillé à des tâches de rétro-ingénierie, et non comme un mécanisme de récupération du code source. Son intérêt se juge sur une question délimitée, les éléments effectivement examinés et la possibilité de contrôler les conclusions. Pour replacer ce cas particulier dans les usages plus larges des agents de développement, consultez aussi notre guide sur les agents de code comme outils d’enquête architecturale.