REA : serveur MCP de rétro-ingénierie pour agents IA

Contexte

La rétro-ingénierie reste un métier à haut seuil d'entrée. Pour comprendre comment une application réalise une fonction précise, un chercheur peut devoir affronter dans un même projet des binaires natifs, du JavaScript empaqueté, des applications Electron, des assemblages .NET et des sites web en production. Chaque type de cible a sa propre chaîne d'outils. Le flux habituel oblige à passer d'un désassembleur à l'autre, comme Hopper, Ghidra ou IDA, à noter les indices à la main, puis à rédiger les conclusions.

REA, abréviation de Reverse Engineer Anything, veut changer ce flux. C'est un serveur MCP de rétro-ingénierie conçu pour les agents IA. Le projet est maintenu par morluto, écrit en TypeScript et distribué via le paquet npm rea-agents. Il ne cherche pas à devenir un nouveau décompilateur. Il se place au-dessus des moteurs d'analyse existants et offre à des agents comme Claude Code, Codex, Cursor et Gemini CLI une manière unique de les appeler.

Le projet propose aussi un site web, des guides, une vitrine de cas, une FAQ et des documents sur le contrat MCP. Le README existe en plus de dix langues, et une communauté Discord réunit questions et partages de réalisations.

Analyse approfondie

Comment REA permet-il à un agent IA de faire de la rétro-ingénierie sur une application sans code source ? REA expose les binaires natifs, les applications JavaScript et Electron, les assemblages .NET et les sites web par un point d'entrée MCP unique. L'agent l'appelle, et chaque conclusion revient avec ses preuves et l'énoncé de ses limites. Pour les cibles natives, le serveur peut piloter Hopper, Ghidra ou IDA s'ils sont installés. L'analyse JavaScript statique n'exige aucun moteur natif. Trois choix de conception ressortent. D'abord, les mêmes outils servent à l'agent et au terminal. Un développeur peut laisser l'agent faire une première passe, puis vérifier le résultat en ligne de commande. Ensuite, l'analyse s'exécute en local. Enfin, la convention des preuves et des limites répond à la principale faiblesse des modèles de langage dans ce domaine : une explication assurée mais sans fondement. Le lecteur peut suivre les preuves au lieu de croire sur parole. L'installation est courte. Avec Node.js et npm, on lance npx rea-agents setup, on choisit les agents à connecter et on relit les modifications listées par l'installateur. Celui-ci sauvegarde la configuration existante, puis on redémarre l'agent. Le README cite Claude Code, Codex, Cursor, Gemini CLI et Grok Build comme agents pris en charge, et d'autres disposent d'une documentation d'installation séparée. L'installation écrit aussi des instructions de flux de travail adaptées, afin que l'agent sache dans quel ordre employer les outils. Les topics du dépôt, dont agent-skills, binary-analysis et decompiler, confirment cette idée de livrer l'outil et la méthode ensemble.

Un détail pratique compte sous Linux. Ghidra, JADX, le lancement des outils de firmware, ainsi que l'analyse statique de JavaScript et d'Electron, exigent un ps compatible procps dans le PATH. REA s'en sert pour vérifier la propriété des processus. Les étapes de récupération figurent dans la section concernée de docs/installation.md.

Impact sur l'industrie

L'usage type est simple. Vous voyez dans une application de bureau une fonction que vous voulez comprendre. Vous demandez à l'agent de l'examiner avec REA. L'agent inspecte l'application sans source, explique le fonctionnement, cite ses preuves, puis peut aider à écrire une implémentation équivalente pour votre propre projet. La rétro-ingénierie passe ainsi d'une tâche de quelques spécialistes à un flux de travail qu'un agent peut assister.

Pour les développeurs indépendants et les petites équipes, cela réduit le coût de l'étude de la concurrence, du diagnostic de compatibilité et de la compréhension de logiciels hérités. Pour les chercheurs en sécurité, une interface MCP unique permet de combiner les forces de moteurs différents au lieu de les laisser isolés.

Les risques sont réels, et les sources en soulignent plusieurs. Rétro-concevoir le logiciel d'autrui soulève des questions de licence et de droit : l'utilisateur doit vérifier lui-même les termes de la licence et la loi locale. Les explications de l'agent demandent une relecture humaine, même avec des preuves, surtout lorsqu'elles reposent sur du code décompilé. La qualité de l'analyse native dépend aussi de l'état de Hopper, Ghidra ou IDA. Enfin, le README avertit que ce type d'outil se fait facilement imiter. Il faut obtenir REA uniquement depuis morluto/rea, rea.tools ou le paquet npm, car un dépôt au nom proche ne prouve pas un téléchargement officiel.

Perspectives

Trois points méritent d'être suivis. Le premier est la couverture : REA ira-t-il au-delà des quatre familles de cibles prises en charge aujourd'hui ? Le deuxième est le savoir communautaire. La vitrine de cas et l'approche agent-skills pourraient former une bibliothèque de méthodes réutilisables, si les contributeurs continuent d'ajouter des flux de travail éprouvés.

Le troisième est la convention elle-même. REA exige que chaque conclusion porte des preuves et des limites énoncées. Si d'autres outils d'agents adoptent cette habitude, la relecture d'analyses produites par machine deviendra plus simple dans tout le domaine. Sinon, l'approche de REA restera un exemple utile mais isolé.

Pour l'instant, le test pratique est modeste. Installez l'outil avec npx rea-agents setup, pointez-le sur une application que vous connaissez déjà, et vérifiez si les preuves citées tiennent. Cette expérience montrera vite jusqu'où vous pouvez lui faire confiance sur une application que vous ne comprenez pas.