Outil REA de rétro-ingénierie : comment analyser une application avec l’IA ?

L’outil REA de rétro-ingénierie permet à un agent IA d’examiner une application sans son code source, puis d’expliquer comment elle fonctionne. REA, pour « Reverse Engineer Anything », est un projet open source sous licence MIT, publié sur GitHub dans le dépôt morluto/rea.

Vous avez repéré une fonctionnalité dans un logiciel et vous voulez savoir comment elle marche, sans documentation ni sources ? Plutôt que de jongler entre un décompilateur, les DevTools et des scripts maison, vous confiez l’enquête à votre agent de code (Claude Code, Codex, Cursor, Gemini CLI…), qui s’appuie sur REA.

Dans cet article, nous voyons ce que fait REA, comment l’installer et dans quels cas il est utile. Nous passons aussi en revue ses limites et les précautions à prendre avant d’analyser un logiciel.

Qu’est-ce que l’outil REA de rétro-ingénierie ?

REA est à la fois un serveur MCP et une interface en ligne de commande qui donnent à un agent IA de vrais outils de rétro-ingénierie. MCP (Model Context Protocol) est le protocole qui permet à un agent d’appeler des outils installés sur votre machine. Les mêmes outils restent utilisables à la main, depuis un terminal.

Le projet couvre plusieurs types de cibles : binaires natifs, applications JavaScript et Electron, assemblys .NET et sites web. Ses auteurs précisent que REA évolue vite et que les nouvelles versions apportent de fréquents correctifs, d’où l’importance de rester à jour.

Comment REA aide à comprendre le fonctionnement d’une application

Le principe est simple : votre agent interroge REA, REA inspecte la cible, puis renvoie ses constats accompagnés des preuves et des limites correspondantes. L’agent s’en sert pour poser de nouvelles questions, expliquer un comportement ou écrire et tester sa propre implémentation.

Un exemple de demande typique : « Comprends comment fonctionne la recherche dans cette application, montre-moi les preuves, puis propose une fonctionnalité similaire pour mon projet. »

Ce fonctionnement en preuves compte beaucoup. Vous pouvez relancer la même analyse en ligne de commande et vérifier ce que l’agent affirme, au lieu de lui faire confiance les yeux fermés.

Quelles sont les principales fonctionnalités de REA ?

REA relaie chaque demande aux outils adaptés à la cible et renvoie ses résultats avec leurs preuves. Voici les cibles les plus courantes, d’après le README officiel :

Cible	Ce que REA renvoie	Prérequis
Binaires natifs	Pseudo-code, assembleur, chaînes, symboles, appels et références	Hopper, Ghidra ou IDA
JavaScript et Electron	Modules, imports, source maps, routes, IPC et add-ons natifs	Node.js et npm
Assemblys .NET	Métadonnées, instructions CIL, dépendances natives déclarées	Aucun (analyse statique)
Sites web	Structure de la page, scripts, observations réseau, captures d’écran	Un navigateur de la famille Chrome
APK Android	Manifeste, classes, méthodes décompilées	JADX et un JDK complet

La liste réelle est plus longue : firmwares, captures réseau, bases SQLite, comportement d’un processus. Un test indépendant publié sur HackerNoon compte environ 170 outils MCP exposés par REA.

Analyser des binaires, des applications JavaScript et Electron

Binaires natifs. REA ne décompile pas lui-même : il pilote Hopper, Ghidra ou IDA et renvoie leur pseudo-code et leur assembleur. Le pseudo-code reste une interprétation du décompilateur, pas le code d’origine. Ghidra et IDA doivent déjà être installés ; l’assistant d’installation peut en revanche proposer d’installer Hopper, avec votre accord.

JavaScript et Electron. C’est la cible la plus simple pour débuter. REA lit un dossier d’application ou une archive ASAR sans exécuter l’application, puis en déduit les modules, les imports, les fenêtres, les scripts preload, les ponts contextBridge et les canaux IPC. Aucun moteur d’analyse natif n’est nécessaire.

Le projet décrit un cas concret : suivre le pont du presse-papiers de Notion, de l’interface jusqu’au processus principal en passant par preload et IPC. Quand un canal est construit dynamiquement, REA le signale comme non résolu au lieu de deviner.

Comment installer et utiliser l’outil REA de rétro-ingénierie ?

L’installation passe par un assistant qui affiche ses modifications avant de les appliquer. Vous pouvez ensuite laisser votre agent piloter REA, ou lancer les mêmes analyses vous-même dans un terminal.

Les prérequis et la commande d’installation

REA demande Node.js 22.x (version 22.19 ou plus), 24.x (24.11 ou plus) ou 26 et au-delà, ainsi que npm. Selon un tutoriel de SitePoint, les systèmes pris en charge sont macOS 12+, Ubuntu 24.04+, Fedora 41+ et Arch Linux 64 bits, avec un mode Windows expérimental limité à Ghidra. Pour l’analyse native, il faut en plus Hopper, Ghidra ou IDA.

La commande d’installation recommandée est la suivante :

npx rea-agents setup

Choisissez vos agents, relisez les modifications proposées et validez. L’assistant ajoute le serveur MCP de REA et des instructions de travail adaptées, en sauvegardant au passage votre configuration existante. Il prend en charge Claude Code, Codex, Cursor, Gemini CLI et Grok Build. Redémarrez ensuite votre agent.

Pour tester sans agent, analysez une application Electron déjà présente sur votre machine :

npx -y rea-agents@latest analyze-javascript-application /chemin/absolu/vers/app --json

Le résultat liste les modules, les imports, les frontières Electron et les preuves associées. Pour un usage régulier, installez la commande rea :

npm install --global rea-agents
rea --help

La commande rea doctor vérifie votre installation en lecture seule : système non pris en charge, moteur d’analyse manquant, configuration à jour ou non. Pour mettre REA à jour, utilisez rea update. Selon le tutoriel de SitePoint, REA refuse par défaut l’accès au système de fichiers. Si une analyse est refusée, vérifiez les dossiers autorisés dans la documentation officielle.

Quels sont les avantages et les limites de REA ?

REA est d’autant plus utile qu’on le prend pour ce qu’il est : un assistant d’enquête, pas un outil qui rend le code source d’origine.

Les points forts

• Des résultats appuyés sur des preuves. Chaque constat est accompagné de ses limites, et les liens ambigus restent signalés comme inconnus.
• Une analyse locale. REA examine la cible sur votre machine. L’agent reçoit toutefois les résultats, et son fournisseur de modèle applique sa propre politique de données.
• Une bonne vitesse sur JavaScript. Lors d’un test sur HackerNoon, une archive app.asar de 100 Mo a été analysée en 52 secondes, sans aucun échec d’analyse.
• Un projet ouvert. Le code est sous licence MIT. Les outils commerciaux comme IDA ou Hopper restent à acquérir légalement.
• Une installation réversible. L’assistant montre son plan, puis sauvegarde la configuration existante avant d’y toucher.

Les limites

• Pas de code source d’origine. REA renvoie du pseudo-code, de l’assembleur, des modules et leurs relations.
• Une analyse statique. Un module présent dans un paquet n’est pas la preuve qu’il s’exécute.
• Des angles morts sur les grosses applications. Dans le test cité plus haut, REA a manqué les deux scripts preload d’une application réelle et a tronqué les relations de 365 fichiers pour rester dans son budget de résultat. Il a aussi laissé passer une vérification d’expéditeur cachée derrière une fonction utilitaire.
• Un coût élevé pour l’agent. La liste des outils près de 170 fonctions pèse environ 1,95 Mo de JSON, ce qui peut saturer le contexte d’un petit modèle.
• Un moteur natif à installer. Sans Hopper, Ghidra ou IDA, REA identifie un binaire (format, empreinte) sans le comprendre.
• Un projet qui bouge vite. Pensez à figer ou à mettre à jour la version avec rea update.

Les précautions à prendre lors de l’analyse d’un logiciel

• Restez dans le cadre légal. Le projet réserve REA à la recherche légale, à l’enseignement, à l’interopérabilité, à la préservation de logiciels et aux logiciels que vous possédez ou avez le droit d’examiner. Une licence d’utilisation ou la loi de votre pays peut limiter la rétro-ingénierie : ce n’est pas un conseil juridique.
• Téléchargez REA depuis les sources officielles. Ce sont le dépôt GitHub morluto/rea, le site rea.tools et le paquet npm rea-agents. Un nom de dépôt similaire ou un README copié ne prouve rien.
• Isolez les cibles inconnues. L’analyse statique n’exécute pas l’application, mais la capture à l’exécution lance ou sollicite la cible avec vos droits d’utilisateur. Pour un binaire suspect, utilisez une machine virtuelle sans identifiants.
• Protégez les résultats. Les instantanés d’analyse peuvent contenir du code propriétaire et des chemins locaux. Gardez-les en local et limitez les dossiers autorisés.
• Utilisez des licences légitimes. Les copies crackées d’IDA, de Hopper ou de JEB ne sont pas autorisées.
• Vérifiez ce que dit l’agent. Relancez la commande rea correspondante pour contrôler chaque affirmation importante.

Conclusion : pourquoi utiliser REA pour la rétro-ingénierie ?

REA vaut le détour si vous voulez comprendre un logiciel sans son code source, avec un agent IA qui montre ses preuves. L’outil REA de rétro-ingénierie réunit au même endroit les binaires natifs, JavaScript et Electron, .NET, les sites web et bien d’autres cibles.

Pour débuter, le plus simple est l’analyse statique d’une application Electron : elle ne demande aucun moteur natif. Gardez en tête ses limites, surtout sur les grosses applications, et vérifiez toujours les conclusions de l’agent.

Prêt à l’essayer ? Lancez npx rea-agents setup, puis testez REA sur une application que vous avez le droit d’analyser et dont vous connaissez déjà le fonctionnement. Vous repérerez vite où il est fiable et où il l’est moins. Le site officiel rea.tools propose des guides et des études de cas pour aller plus loin.