Lire une sortie REA : preuves, pseudocode et hallucinations

Le 11 octobre 2026, Ishank Choudhary a lancé REA 6.4.0 sur une application Electron de 100 Mo. La sortie comptait 744 limitations explicites et annonçait zéro script preload là où le code en chargeait deux. La première information signale ce que l'outil n'a pas pu établir ; la seconde est une erreur qu'il ne signale pas. Une relecture sérieuse sépare ces deux cas avant de signer un rapport.

Ce que REA rend, d'après son propre dépôt

Le README de REA promet que chaque conclusion arrive avec les preuves et les limitations qui la fondent¹. En analyse native, l'outil renvoie du pseudocode et de l'assembleur produits par Ghidra, Hopper ou IDA. Sur une application JavaScript ou Electron, il reconstruit des modules, des imports, des canaux IPC et des relations entre fichiers. Chaque constat arrive avec sa localisation dans l'artefact analysé. Le dépôt prévient aussi, dans son avertissement, que la décompilation, la reconstruction et l'analyse assistée par IA peuvent être incomplètes ou fausses, et qu'il faut vérifier la preuve sous-jacente avant de s'appuyer sur une conclusion qui engage².

Entre l'outil et vous, il y a l'agent. REA renvoie des faits outillés ; le modèle de langage les résume, les relie et en tire une explication. Les erreurs de lecture naissent presque toujours à cette étape.

Trois états à séparer à la relecture

Nous relisons une sortie d'agent en classant chaque affirmation dans l'un de trois états. Ce découpage est notre méthode de revue ; REA ne le fournit pas sous ce nom.

Vu : l'affirmation pointe vers un fichier, un décalage, une fonction, une chaîne que vous pouvez ouvrir. Vous la vérifiez avec grep ou dans le décompilateur. Inféré : l'agent a déduit un comportement d'un motif, d'un nom de fonction, d'une habitude de framework. C'est souvent juste et jamais prouvé. Inconnu : l'outil n'a pas pu résoudre un chemin, un nom minifié, un appel dynamique. Règle de relecture : une affirmation inférée ne remonte jamais dans un rapport comme une affirmation vue.

Les inconnues sont la partie la plus fiable

Les 744 limitations du test de Choudhary, dont 365 liées au budget de résultat, ressemblent à du bruit. Elles constituent la partie de la sortie qui ne vous trompera pas. Sur une trace de canal qui ne donnait rien, REA a précisé qu'aucune entité du graphe ne correspondait à la chaîne recherchée et que ce résultat ne prouvait pas l'absence de la fonctionnalité³. L'outil refuse de conclure à l'absence.

Mise à jour du 21 octobre 2026. Connor Turland a publié le 20 octobre son analyse de Slack 4.52.171 : 43 004 éléments marqués inconnus, dont des expressions minifiées comme U.dZ.SLEEP_AND_WAKE⁴. Le même passage a pourtant reconstitué la logique d'un contrôle de notifications de Slack en une dizaine de minutes. Beaucoup d'inconnues et une découverte exacte cohabitent dans la même sortie.

Deux pièges de lecture

Prendre un comptage pour une preuve de complétude. Sur l'application de 100 Mo, REA a compté cinq fenêtres, comme les cinq appels new BrowserWindow( du code, et deux API contextBridge, conformes elles aussi. Il a annoncé zéro preload : les deux fichiers étaient chargés à travers un helper qui construit le chemin à l'exécution, et l'auteur suppose, sans l'avoir confirmé, que ce helper a bloqué la résolution statique³. Le zéro s'est propagé : zéro membre exposé. Sur une application jouet, REA a aussi rapporté zéro contrôle d'expéditeur alors qu'un checkSender(e) existait derrière un helper. Un zéro dans une sortie REA signifie que l'outil n'a rien trouvé, et se vérifie à la main.

Croire que le code plausible est le code qui tourne. Aayush Tyagi a fait analyser le quick switcher d'Obsidian 1.14.4 (Analytics Vidhya, 18 octobre 2026). Avant de faire confiance à la fonction de score trouvée, l'agent a vérifié que la classe QuickSwitcherModal, minifiée en oie, hérite bien de la classe qui porte le pipeline. Tyagi résume le risque : « Finding plausible-looking scoring code and assuming it is the code that runs is the classic failure mode here. »⁵ Son protocole mérite d'être copié : écrire une prédiction testable avant de lancer l'agent, puis confronter le résultat à 24 classements relevés à la main. La table de vérification a fait apparaître une ambiguïté de décalage d'une unité que la formule rédigée cachait. Le tout a pris 7 minutes 8 secondes de travail actif pour 1,83 dollar.

Du constat à la preuve : le golden master

Une sortie REA est une hypothèse documentée. Pour une migration, elle devient utile le jour où vous la transformez en tests. Le principe du golden master s'y prête : l'application d'origine produit les sorties de référence, la nouvelle doit les reproduire. Chaque règle métier vue dans le binaire devient un cas de test ; chaque règle inférée devient un cas à faire confirmer par les métiers avant d'écrire la moindre ligne. Nous détaillons la mécanique dans les tests de non-régression par golden master, et la démarche d'ensemble dans comprendre une application legacy sans son code source.

Côté coûts et volumes, une sortie lisible a un prix en contexte : voir les limites réelles de REA. Pour le cas Electron en détail : ce qu'une analyse REA révèle d'une application Electron.

Pour l'architecture de l'outil et son installation, voir REA expliqué en trois schémas.

Questions fréquentes

REA hallucine-t-il ?

Les outils que REA pilote renvoient des faits localisés. L'agent qui les interprète peut se tromper, et un résultat vide peut masquer un fichier non résolu. Vérifiez chaque affirmation qui engage une décision.

Que signifie une inconnue ?

Que l'outil n'a pas pu résoudre un élément. Elle ne prouve pas que la fonctionnalité est absente ; REA l'écrit lui-même dans ses messages.

Comment valider une sortie ?

Recouper avec grep ou le décompilateur, écrire une prédiction avant l'analyse, puis transformer les constats en tests exécutés sur l'application d'origine.

Faire relire par des gens qui vérifient

La méthode en trois états est celle que nous appliquons dans AI Cyber, notre offre de défragilisation du code en boîte blanche : un constat d'agent n'entre dans un rapport qu'avec sa preuve, ou avec le test qui le démontre. Pour le cadre général de la rétro-ingénierie par agents côté sécurité, voir ce que la rétro-ingénierie par agents change pour les équipes sécurité.

Sources

1. morluto/rea, README, github.com/morluto/rea, consulté le 15 octobre 2026.
2. morluto/rea, DISCLAIMER.md, github.com, consulté le 15 octobre 2026.
3. 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).
4. Connor Turland, What is REA (Reverse Engineer Anything)? I ran it on Slack to find out, atcyrus.com, 20 octobre 2026.
5. Aayush Tyagi, Reverse Engineer Anything (REA): Can AI Really Crack Closed Code?, analyticsvidhya.com, 18 octobre 2026.