REA en trois schémas : architecture, fonctionnement et usage

REA (Reverse Engineer Anything) donne à un agent de code les outils d'un rétro-ingénieur. Ce n'est ni un décompilateur ni un service en ligne : c'est un serveur MCP et une CLI, publiés sous licence MIT, qui tournent sur la machine du développeur et pilotent des outils existants. Trois schémas suffisent à comprendre l'essentiel : ce qu'on installe et où, ce qui se passe quand l'agent appelle REA, et la méthode pour comprendre une fonctionnalité avant de la déboguer ou de la reproduire.

Le dépôt morluto/rea, créé le 14 avril 2026, résume son ambition en une ligne : « One MCP for reverse engineering across binaries, applications, and runtime behavior »¹. Il comptait 76 998 étoiles le 11 octobre au matin selon un testeur⁵, et 369 860 le 23 octobre d'après l'API GitHub. Le paquet npm rea-agents en était à la version 6.7.0, publiée le 18 octobre⁴.

Schéma 1 : ce qu'un développeur installe, et où

Côté développeur, l'installation tient en une commande : npx rea-agents setup. Elle ne télécharge pas un logiciel de plus dans un coin du poste ; elle déclare REA comme serveur MCP auprès de l'agent que vous utilisez déjà (Claude Code, Codex, Cursor ou tout client qui accepte un serveur MCP local) et installe une skill, c'est-à-dire des instructions d'enquête que l'agent lira. Pour Claude Code, la documentation précise que l'enregistrement va dans ~/.claude.json et la skill dans ~/.claude/skills, donc pour tous les projets ouverts avec ce client².

Trois réflexes viennent de la même documentation. D'abord, --dry-run renvoie un plan en lecture seule avant toute écriture, et le setup sauvegarde la configuration existante. Ensuite, pour réserver REA à un usage précis, un profil séparé via la variable CLAUDE_CONFIG_DIR évite de l'exposer à tous vos projets. Enfin, le setup épingle la version exacte installée dans l'enregistrement MCP².

Reste la question des moteurs. REA analyse lui-même le JavaScript, les applications Electron et les assemblies .NET, sans rien installer d'autre. Pour le code natif, il lui faut Ghidra, IDA ou Hopper, que vous installez vous-même, en acquérant la licence d'IDA ou de Hopper ; pour Android, JADX et un JDK complet ; pour le firmware, Binwalk ou Unblob sous Linux ; pour un site web, un navigateur de la famille Chrome¹. Sans moteur natif, REA s'arrête à l'identification du format : le test de HackerNoon obtient un provider_unavailable sur un binaire Rust⁵.

Le schéma montre la frontière que beaucoup ratent. La FAQ du projet est explicite : « REA analyzes targets locally. Your agent receives the tool results, and its model provider has its own data policy »¹. Le binaire ne part pas ; ce que l'agent en a extrait, si. Analyser un code sensible avec un modèle hébergé reste donc une décision de conformité, que l'on traite comme pour n'importe quel envoi de code à un fournisseur.

Schéma 2 : ce qui se passe quand l'agent appelle REA

Vous posez une question à votre agent ; l'agent choisit un outil REA et lui passe le chemin de la cible. REA identifie le format, puis l'oriente vers le bon traitement. Pour un bundle JavaScript ou une assembly .NET, il lit les fichiers sans exécuter l'application. Pour un binaire natif, il ouvre une session de pont vers Ghidra, IDA ou Hopper. Pour une APK, il passe par JADX. Pour un site ou un processus, il peut observer l'exécution, et c'est là que la prudence s'impose : la capture « runs or interacts with the selected target using your user permissions »¹.

Chaque réponse revient sous forme de preuves : un constat, l'endroit où il a été trouvé, et la liste de ce que l'outil n'a pas pu résoudre. Le README le promet en une phrase, « results include the evidence and limitations behind each conclusion »¹, et les tests indépendants le confirment : 744 limitations explicites sur une application Electron de 100 Mo⁵, une trace qui répond « this is not evidence that the feature is absent » plutôt que d'inventer⁵.

Le pont vers Ghidra ou Hopper est authentifié par un jeton aléatoire par session et un socket réservé à l'utilisateur courant. La politique de sécurité du projet en fixe la portée sans détour : « This is not a sandbox and does not protect against malicious processes already running as the same operating-system user »³. Ouvrir un binaire inconnu, c'est le faire analyser par le moteur avec vos permissions. Nous détaillons le confinement dans REA n'est pas un sandbox.

Schéma 3 : comprendre une fonctionnalité pour la déboguer ou la reproduire

Le README présente REA par son cas d'usage : voir une fonctionnalité dans une application, comprendre comment elle marche, « show the evidence, and build a version for your project »¹. La méthode qui tient la route commence avant l'agent. Le test d'Analytics Vidhya sur le sélecteur rapide d'Obsidian l'illustre : les auteurs ont écrit leur prédiction du classement avant de lancer l'enquête, ce qui a rendu la sortie vérifiable ; avant de faire confiance à la trace, l'agent a contrôlé que la classe du sélecteur héritait bien de celle qui contenait le calcul. Sept minutes de travail actif, 1,83 dollar, et une formule confrontée à 24 classements relevés à la main⁶.

Les deux sorties n'ont pas le même statut. Déboguer son propre logiciel, ou un composant dont on est acquéreur légitime, relève d'un cadre connu : en droit européen, la Cour de justice a admis en 2021 la décompilation pour corriger des erreurs affectant le fonctionnement, dans la mesure nécessaire et dans le respect des conditions contractuelles, l'éditeur pouvant se réserver cette correction. Reproduire une fonctionnalité d'un logiciel tiers est un autre sujet. Le droit d'auteur ne protège pas la fonctionnalité en elle-même, mais son code et ses éléments graphiques, et d'autres protections peuvent jouer (brevet, secret des affaires, contrat, concurrence déloyale) ; et un agent qui lit le décompilé puis écrit la réimplémentation fragilise toute défense clean-room. La documentation de REA le dit elle-même : pour une vraie séparation, l'implémentation doit se faire dans un environnement qui ne peut lire ni REA, ni la cible, ni les sorties d'analyse, « A separate account or container must enforce those restrictions »². Nous détaillons ces points d'attention, qui ne sont pas un conseil juridique, dans clean-room ou reverse engineering.

Le disclaimer du projet ferme la porte aux usages illégitimes : pas d'aide pour contourner un DRM, une vérification de licence ou un anti-triche, ni pour « copying proprietary software or reproducing its protected code and assets »⁷. Il rappelle aussi que la décompilation assistée par IA « may be incomplete or incorrect », d'où l'étape 4 du schéma.

Ce que ces trois schémas changent pour une équipe

Le premier schéma dit où placer REA : dans un profil dédié, avec une version épinglée, et avec un choix de modèle cohérent avec la sensibilité de la cible. Le deuxième dit où se trouve le risque : dans la capture à l'exécution et dans l'ouverture de binaires inconnus, pas dans la lecture statique de votre propre code. Le troisième dit où se trouve la valeur : une compréhension vérifiée, transformée en test, plutôt qu'une affirmation d'agent prise pour argent comptant. Les limites mesurées en octobre (sorties de plusieurs centaines de mégaoctets, catalogue de 207 outils en 6.7.0⁸, couverture partielle sur le code dynamique) sont détaillées dans les limites réelles de REA ; la lecture d'une sortie, dans lire une sortie REA.

Questions fréquentes

REA fonctionne-t-il avec n'importe quel agent ?

Avec tout agent qui accepte un serveur MCP local, selon la FAQ du projet. Le setup configure automatiquement les clients pris en charge ; les autres s'enregistrent à la main.

Faut-il acheter une licence pour utiliser REA ?

REA est sous licence MIT. Les moteurs commerciaux qu'il pilote, comme IDA Pro ou Hopper, restent à acquérir légalement ; Ghidra est gratuit. Le JavaScript, Electron et .NET ne demandent aucun moteur.

Mon binaire est-il envoyé dans le cloud ?

Non, l'analyse est locale. En revanche, les résultats d'outils que l'agent lit partent vers le fournisseur du modèle, selon sa politique de données. Pour un code sensible, utilisez un modèle local ou un fournisseur dont le contrat convient.

Par quoi commencer ?

Par un programme que vous avez écrit vous-même, dont vous connaissez le source : c'est le seul cas où chaque réponse de l'agent se vérifie immédiatement. Ensuite seulement, un composant que vous êtes autorisé à examiner, en environnement isolé.

REA abaisse le coût de la compréhension d'un logiciel ; il n'en supprime ni le cadre ni la vérification. Notre offre AI Cyber aide les équipes à mettre en place ces usages, du confinement des agents à la défragilisation du code existant en boîte blanche.

Sources

1. morluto/rea, README (cibles, FAQ, showcases) — github.com/morluto/rea, consulté le 23 octobre 2026.
2. morluto/rea, Installation and setup (dry-run, sauvegardes, profil séparé, séparation clean-room) — docs/installation.md, consulté le 23 octobre 2026.
3. morluto/rea, Security Policy — SECURITY.md, consulté le 23 octobre 2026.
4. npm, paquet rea-agents (version 6.7.0 du 18 octobre 2026) — npmjs.com, consulté le 23 octobre 2026.
5. Ishank Choudhary, I Tested REA, GitHub's Viral Reverse Engineering Tool, on a Real Electron App — hackernoon.com, 14 octobre 2026 (tests du 11 octobre, REA 6.4.0).
6. Aayush Tyagi, Reverse Engineer Anything (REA): Can AI Really Crack Closed Code? — analyticsvidhya.com, 18 octobre 2026.
7. morluto/rea, Disclaimer — DISCLAIMER.md, consulté le 23 octobre 2026.
8. Javier Cañete Arroyo (Jacar Systems), REA: ingeniería inversa con tu agente de código, probada con Ghidra y Electron — jacar.es, 19 octobre 2026 (rea-agents 6.7.0).