REA : rétro-ingénierie du comportement applicatif et des binaires natifs avec des agents

À qui il s’adresse

REA s’adresse à celles et ceux qui ont besoin de rétro-ingénierie au sein de leur agent : développeurs et mainteneurs qui veulent comprendre le comportement d’une application ou inspecter des binaires natifs, des applications JavaScript et Electron, des assemblys .NET et des sites web ; il convient aussi à ceux qui maintiennent des applications de bureau Electron ou des services .NET et veulent voir ce que fait réellement une dépendance tierce ou une version historique. Il connecte ces outils d’inspection à votre agent, ces mêmes outils s’utilisent aussi directement dans le terminal, et l’analyse se fait en local. Le critère est simple : si la question à laquelle vous devez répondre est « que fait réellement ce programme ou ce fichier ? » et que la réponse se cache dans les binaires, les artefacts empaquetés ou le comportement à l’exécution, cela vaut la peine de l’installer. Cas où il ne convient pas : la cible n’est pas un fichier ou une application que vous avez le droit d’inspecter ; votre environnement ne peut pas installer la version de Node.js exigée ; ou vous cherchez un service d’analyse purement en ligne qui ne touche jamais aux fichiers locaux.

Première tentative en 3 minutes

Le chemin principal recommandé est unique : utiliser la commande setup officielle pour enregistrer le serveur MCP de REA et installer les instructions correspondantes, puis redémarrer votre agent.

npx rea-agents setup

Prérequis : Node.js 22.x (au moins 22.19), 24.x (au moins 24.11) ou 26+, plus npm, installés localement. Exécutez la commande ci-dessus dans un terminal ; elle enregistre le serveur MCP et installe les consignes d’utilisation correspondantes. Si la connexion échoue, vérifiez d’abord que votre version de Node.js satisfait aux exigences ci-dessus.

Après redémarrage, faites un appel à faible risque pour confirmer la connexion : demandez à l’agent d’inspecter statiquement un fichier JavaScript local. Avant l’action, précisez sa nature — la documentation officielle indique que l’inspection statique JavaScript et .NET se contente de lire les fichiers fournis sans exécuter l’application ; cette étape ne lance donc pas le programme cible. Signaux de succès observables : la commande setup se termine et l’agent redémarré peut restituer le résultat d’inspection du fichier, ce qui signifie que les outils REA sont disponibles dans l’agent. La documentation officielle ne liste ni les noms exacts ni les paramètres de chaque outil ; seuls comptent les outils que l’agent enregistre après redémarrage. Outre l’appel via l’agent, vous pouvez utiliser les mêmes outils directement dans le terminal — c’est l’usage secondaire décrit par la documentation officielle.

Cas d’usage

Cas 1 : comprendre un fichier JavaScript sans l’exécuter. Scénario : vous recevez un fichier JS empaqueté ou obfusqué et voulez savoir ce qu’il fait avant de décider de l’exécuter. Méthode : transmettez le chemin du fichier à l’agent et laissez-le l’analyser avec l’inspection statique JavaScript de REA. Résultat attendu : l’agent lit le fichier et produit ses conclusions sans jamais exécuter ce code ; même logique pour les assemblys .NET, dont l’inspection statique ne fait que lire les fichiers ; conclusions statiques et observations à l’exécution peuvent aussi se corroborer mutuellement.

Cas 2 : capturer le comportement runtime d’une cible. Scénario : l’analyse statique ne révèle rien et vous devez observer comment le programme s’exécute réellement. Avant toute action, confirmez impérativement les effets de bord : la documentation officielle précise que la capture runtime exécute la cible choisie ou interagit avec elle en utilisant vos droits utilisateur, et que chaque guide runtime décrit ses propres effets ; après avoir confirmé la cible et son impact, demandez à l’agent d’effectuer la capture. Si la cible implique des données utilisateur réelles ou un environnement de production, validez d’abord les étapes sur une copie isolée. Résultat attendu : l’agent renvoie des informations sur le comportement runtime de la cible ; ce qui est modifié exactement relève du guide runtime correspondant.

Limites d’usage

Distinguez lecture et écriture : l’inspection statique JavaScript et .NET lit seulement des fichiers et n’exécute aucune application ; la capture runtime est une opération à effet réel qui exécute la cible ou interagit avec elle avec vos droits utilisateur. Aucun mécanisme d’annulation unifié n’est documenté officiellement : ne présumez qu’aucune étape n’est réversible.

Sur le lieu de l’analyse, la documentation officielle indique que REA analyse les cibles en local ; cela décrit seulement où l’analyse a lieu et ne constitue pas une conclusion de sécurité, et le présent guide ne porte pas non plus de jugement indépendant sur les flux de données ni les frontières de confidentialité. L’emplacement local des artefacts d’analyse et leur nettoyage ne sont pas expliqués sur la page officielle : point non confirmé.

Informations absentes de la page officielle et à vérifier vous-même avant d’agir : noms et paramètres exacts de chaque outil d’inspection, systèmes d’exploitation et clients agents pris en charge, nécessité ou non d’identifiants de compte, contenu précis de chaque guide runtime. Les exigences de version peuvent évoluer avec le projet ; avant d’exécuter setup, c’est la version actuelle de la page officielle qui fait foi.