Analyse du fonctionnement et des capacités du dépôt REA, un outil d'IA pour décompiler et reconstruire des applications binaires

La plupart des logiciels ne livrent jamais leur code source. Pour savoir ce qu’ils font vraiment, il faut les décortiquer, et ça prend vite des heures.

Comment y arriver sans perdre son temps, et sans sortir du cadre légal ? Dans cet article, on voit ce que REA sait faire, et où il s’arrête.

Analyse du fonctionnement de REA : ce qu’il est, ce qu’il ne fait pas

REA est un serveur MCP et un outil en ligne de commande, ce qui veut dire qu’il sert d’intermédiaire entre ton agent de codage et des outils d’analyse de logiciels.

MCP, c’est le protocole qui branche une application sur des outils externes. Si ça reste flou, ce guide pratique explique comment connecter une IA à tes outils.

Attention au nom : REA ne décompile rien seul. L’analyse tourne sur ton ordinateur, et la profondeur d’un binaire natif dépend du moteur que tu installes à part.

REA ne garantit pas que la version qu’il t’aide à écrire soit complète ni sans erreur. Il faut tester le résultat avant de t’y fier.

Autre point, souvent oublié : les résultats partent vers l’agent, donc vers le fournisseur du modèle. Pour Claude Code, le réglage des données et le type de compte changent la durée de conservation. Vérifie-les avant d’analyser un logiciel sensible.

Commence par un logiciel dont tu détiens la licence, et laisse hors de la discussion les secrets sensibles.

Comment l’agent IA pilote Ghidra, Hopper ou IDA via REA

L’agent de codage n’ouvre pas le binaire lui-même. Il demande une analyse au serveur MCP de REA, qui transmet la demande à l’outil adapté, puis renvoie les résultats à l’agent.

Pour un binaire natif, REA sort le pseudocode, l’assembleur, les chaînes, les symboles et les appels. Pour aller au fond, il faut pourtant Hopper, Ghidra ou IDA installé. Sans l’un d’eux, n’attends pas d’analyse profonde : installe-le d’abord.

Côté ligne de commande, voici ce qu’il faut retenir, et une règle qu’on oublie souvent :

• La commande npx -y rea-agents@latest analyze /chemin/vers/binaire --provider ghidra --json lance une analyse native avec Ghidra et produit une sortie JSON.
• inspect existe à côté de analyze, et des commandes spécialisées traitent JavaScript et Electron.
• rea --help affiche le catalogue complet des commandes de ta version installée.
• Chaque commande tourne à part : si tu veux réutiliser un résultat, enregistre-le dans un fichier.

Installation : une commande et Node.js suffisent pour démarrer

La commande pour démarrer est npx rea-agents setup.

Avant de la lancer, vérifie la version de Node.js : il faut la 22.19 ou plus dans la série 22, la 24.11 ou plus dans la série 24, ou la 26 ou plus récente.

Pour aller plus loin après l’installation, le guide débutant sur Codex montre les premiers pas. Personne ne retient la version de Node installée il y a deux ans, alors vérifie avant de lancer, pas après une erreur rouge.

Le setup te demande ton agent, affiche les changements avant de les appliquer et garde tes anciens réglages, mais il n’installe aucun moteur d’analyse, donc il faut ajouter à part ce dont tu as besoin :

• Pour un binaire natif, installe Hopper, Ghidra ou IDA.
• Pour un APK, installe JADX en mode sans interface graphique, avec un JDK complet, sur Linux, macOS ou Windows x64.
• Pour un site web, installe un navigateur de la famille Chrome.
• Pour du JavaScript ou du .NET, bonne nouvelle : rien de plus à installer.

Ce que REA sait analyser : natif, JavaScript, .NET, Android et sites web

Binaires natifs : pseudocode, assembleur et appels

Pour un programme compilé en langage machine, REA peut renvoyer du pseudocode, de l’assembleur, des chaînes, des symboles, des appels et des références.

Attention, la profondeur dépend du moteur installé, comme Hopper, Ghidra ou IDA. Sans l’un d’eux, pas d’analyse approfondie. Vérifie ça avant de commencer, sinon tu perds du temps à chercher pourquoi le résultat est maigre.

JavaScript et Electron : modules, IPC et archives ASAR

Une application Electron, c’est du JavaScript, et ça se lit sans la lancer. REA examine ses modules, ses imports, ses routes et ses cartes de source.

Il regarde aussi les échanges IPC, les messages que se passent les différentes parties de l’appli. Un module natif appelé au passage ? REA le signale, et là il faudra un moteur.

Bonne nouvelle pour toi : si tu as un dossier d’application déjà extrait, ou une archive ASAR (le format qu’Electron utilise pour regrouper son code), REA analyse les fichiers sans moteur d’analyse de binaires natifs.

Pour ce cas, pas besoin de chercher Ghidra ou IDA. Tu gagnes du temps, et ça, on ne va pas s’en plaindre.

Applications .NET : métadonnées et instructions CIL

Pour une appli .NET, REA lit les métadonnées (la description des classes et des fonctions) et les instructions CIL (le langage intermédiaire dans lequel le code est compilé).

Il compare aussi deux versions compilées et repère les dépendances natives déclarées. Tout ça sans lancer l’appli, ce qui évite les mauvaises surprises. Pour suivre une mise à jour, commence par là.

APK Android, sites web et captures réseau

Selon la cible, ce que REA examine et ce qu’il faut installer changent, donc regarde ça avant de te lancer.

Trois cas documentés par le projet, à lire avec prudence

Le projet publie trois cas : DX-Ball, Notion et TH04. Ce sont ses propres exemples, sans reprise indépendante. Rien ne dit donc que ça marche pareil sur ton logiciel.

L’expérience de huit minutes reste un témoignage non confirmé. Tant que personne ne la refait, elle ne vaut que comme récit.

Un projet qui présente ses propres exemples a de bonnes raisons de les trouver réussis, alors teste d’abord l’outil sur un binaire que tu connais.

Chaque cas montre un point précis, avec sa limite :

• DX-Ball : une reconstruction en C d’une fonction de panoramique reproduit ses 63 octets compilés et passe 3 205 cas de test. Limite : une seule fonction est vérifiée, pas le jeu entier.
• Notion : le presse-papiers est suivi depuis l’interface jusqu’au processus principal d’Electron, format riche compris. Limite : c’est un seul chemin de l’application, pas tout le logiciel.
• TH04 : le calcul d’angles doit respecter les unités propres au jeu. Limite : supposer des degrés ou des radians donne un résultat faux, donc l’unité doit être vérifiée avant de conclure.

Est-ce légal ? Ce que REA permet et ce qui reste hors de portée

REA vise la recherche, l’éducation, l’interopérabilité et la préservation logicielle, sur les logiciels que tu possèdes ou que tu as le droit d’examiner. En France, la décompilation nécessaire à l’interopérabilité d’un logiciel créé de façon indépendante est permise.

Première règle : avoir le droit d’utiliser le logiciel, et n’analyser que les parties nécessaires. Elles ne servent qu’à ce but, ne vont à personne sauf besoin d’interopérabilité, et ne permettent pas de créer un logiciel très proche.

Les licences de ces outils restent à respecter. REA ne fournit ni clé ni autorisation d’activation pour IDA Pro, Hopper ou JEB.

Pour un SaaS, REA ne voit que ce qui part vers le navigateur, jamais le code privé resté chez l’éditeur. Une analyse de page ou de flux réseau ne livre donc pas la logique du serveur.

Sur un service en ligne, passe plutôt par sa documentation et son API publique : tu gagneras du temps et tu resteras dans les clous.

REA est utile, à condition de savoir ce qu’il ne fait pas : il ne décompile rien tout seul, et ses résultats se vérifient toujours. Le moteur installé à côté fait la différence.

Ton prochain pas : teste REA sur un logiciel que tu possèdes et que tu connais bien. Tu verras vite si ses résultats sont fiables.