REA expose un point de terminaison MCP local et un catalogue de workflows d’agent qui convertissent les objectifs d’investigation en séquences d’appels d’outils. Des agents comme Claude Code, Codex, Cursor, Gemini CLI et Grok Build se connectent au serveur MCP de REA ; la configuration installe côté agent des instructions spécialisées qui apprennent au modèle à demander des instantanés, des analyses statiques et des exécutions par des fournisseurs natifs. Lorsqu’un agent demande une analyse approfondie, REA sélectionne le fournisseur natif configuré — Ghidra, Hopper ou IDA — le lance si nécessaire, exécute des scripts de décompilation ciblés et renvoie des résultats structurés : chaînes, références croisées de symboles, extraits de pseudo-code et preuves à l’échelle du fichier.

La valeur de REA tient à sa méthode : les agents partent d’éléments observables — captures d’écran, captures réseau, traces IPC ou exécutions de processus enregistrées — et REA les aide à les relier au code. Par exemple, un agent peut parcourir l’export d’une application Electron pour trouver un gestionnaire du presse-papiers, suivre les liens vers le processus preload et les échanges IPC, puis demander l’analyse native du binaire du processus principal pour en examiner l’implémentation. REA regroupe les chemins d’appels et de références, les routines décompilées et des éléments de preuve concis. L’agent peut ainsi expliquer pourquoi il pense qu’une fonction met en œuvre une fonctionnalité et présenter les octets ou le pseudo-code précis à l’appui de cette conclusion.

REA privilégie l’analyse locale : les outils s’exécutent sur la machine de l’enquêteur, les artefacts bruts y sont conservés et les preuves renvoyées peuvent être intégrées par l’agent à un compte rendu de session reproductible. Cette architecture facilite la confidentialité et la conformité, mais oblige aussi les équipes à gérer elles-mêmes les licences des outils natifs et les limites de ressources. REA propose des adaptateurs de fournisseurs, des réglages de délai d’expiration au démarrage pour les gros binaires, des scripts de secours hors ligne avec objdump ou rizin, ainsi que des invites facultatives pour installer Hopper. Avant de déployer les investigations pilotées par des agents à grande échelle, les opérateurs devraient automatiser les vérifications de disponibilité des fournisseurs et définir des règles d’enregistrement et de conservation des preuves.

REA se révèle particulièrement utile pour des tâches concrètes : comprendre un logiciel ancien dont le code source a disparu, comparer des versions pour isoler des régressions, documenter des formats de fichiers ou des protocoles non documentés, et automatiser la reproduction dans le cadre d’une migration ou de la mise en place d’une compatibilité. Les équipes peuvent configurer un agent pour recueillir des exemples, exécuter des traces statiques et dynamiques, générer du pseudo-code annoté et ébaucher une implémentation de remplacement. Les démonstrations fournies avec REA illustrent des pipelines complets — collecte de preuves, reproduction guidée par des tests unitaires et vérification sur les jeux d’entrées d’origine — qui en font un véritable outil de livraison, et non un simple gadget d’investigation.

La rétro-ingénierie se situe à la croisée des possibilités techniques et des contraintes juridiques. REA présente clairement ses avertissements et encourage l’analyse locale pour réduire les risques de partage involontaire, mais les équipes restent responsables des licences, des autorisations et du périmètre autorisé. L’interopérabilité autorisée, la recherche en sécurité et la préservation des logiciels sont des justifications courantes ; en revanche, copier à l’identique du code protégé ou utiliser des clés de licence piratées est interdit. Des contrôles opérationnels — vérifications juridiques préalables, accès restreint aux fonctions sensibles, journaux d’audit des cibles analysées et règles strictes sur les résultats reproduits — sont indispensables pour limiter les risques juridiques.