Ce qu'une analyse REA révèle d'une application Electron
Le 11 octobre 2026, Ishank Choudhary a passé une application Electron de 100 Mo à REA 6.4.0 : 52,2 secondes d'analyse, 421 fichiers JavaScript parsés, aucun moteur de décompilation installé. Electron est la cible où REA obtient ses meilleurs résultats, parce que tout le code de l'application voyage en JavaScript sur le disque de l'utilisateur.
Pourquoi Electron se lit sans décompilateur
Une application Electron embarque son code dans une archive app.asar, une concaténation de fichiers avec un index. Le README de REA range les applications JavaScript et Electron parmi les cibles qui n'exigent que Node.js et npm : REA lit les fichiers fournis sans lancer l'application et renvoie modules, imports, source maps, routes, canaux IPC et relations avec les add-ons natifs1. Ghidra, Hopper ou IDA n'entrent en jeu que si l'on veut descendre dans un add-on natif compilé.
REA lit aussi l'état des fuses Electron, ces interrupteurs gravés dans le binaire qui décident par exemple si l'application vérifie l'intégrité de son archive (EnableEmbeddedAsarIntegrityValidation) ou ne charge son code que depuis app.asar (OnlyLoadAppFromAsar). Sa documentation précise que l'outil lit ces octets sans lancer l'application, sans les modifier et sans réseau2.
Le test du 11 octobre, comptage par comptage
Choudhary a comparé chaque comptage de REA à un grep sur le source de PI-Desktop v0.16.13. Les fenêtres concordent (5 appels new BrowserWindow(, 5 annoncées), les API contextBridge aussi (2), comme les gestionnaires IPC : 4 côté processus principal, 6 transmissions et 5 écouteurs côté renderer. L'analyse a parcouru 3 114 427 nœuds d'arbre syntaxique sans échec de parsing et écrit 59,2 Mo de résultats.
Le même test montre les trous. REA a compté zéro script preload alors que l'application en charge deux, dont le chemin est construit à l'exécution par un helper. Ce zéro a vidé le comptage des membres exposés au renderer. Sur une application jouet, un contrôle d'expéditeur caché derrière une fonction d'aide est passé inaperçu. La sortie portait 744 limitations explicites, et aucune ne signalait les deux preloads manquants.
Mise à jour du 21 octobre : deux applications réelles
Mise à jour du 21 octobre 2026. Deux tests publiés depuis donnent une idée de l'échelle. Javier Cañete Arroyo (Jacar Systems) a analysé Hyper 3.4.1 avec REA 6.7.0 : un app.asar de 14 Mo, 2 236 fichiers, 18 canaux IPC, 6 add-ons natifs et un fichier de preuves de 253 Mo4. Connor Turland (Cyrus) a passé Slack 4.52.171 pour macOS : 52 secondes au second passage, un JSON de 158 Mo, 529 fichiers JavaScript, 1 904 modules, 45 canaux IPC et 8 add-ons natifs5. Il dit avoir compris la logique d'un contrôle de notifications en une dizaine de minutes.
Turland a aussi buté sur l'intégrité de l'archive : huit binaires natifs .node ne correspondaient pas à l'empreinte déclarée. REA a suggéré une re-signature par l'outil de packaging après l'écriture de l'archive, et Turland a relancé l'analyse en mode « enregistrer et continuer ». Sur la même application, REA a marqué 43 004 éléments comme inconnus, souvent des noms de canaux minifiés.
Ce qui échappe à l'analyse statique
Trois familles reviennent dans tous les tests. Les noms minifiés que REA ne sait pas résoudre, et qu'il range parmi les inconnues. Les chemins construits à l'exécution, comme les preloads de Choudhary. Et le code chargé depuis un serveur, qui n'est jamais sur votre disque : REA ne le verra pas, quelle que soit sa version. Un zéro dans un comptage se vérifie donc à la main, et les inconnues se lisent avec la même attention que les trouvailles (voir lire une sortie REA).
Le volume pèse aussi : 59, 158 ou 253 Mo de preuves débordent toute fenêtre de contexte. L'agent doit interroger REA par questions étroites. Les chiffres détaillés sont dans les limites réelles de REA.
Ce que ça change pour un éditeur
Si vous éditez une application Electron, partez du principe que sa structure, ses canaux IPC et sa logique côté client sont lisibles par n'importe quel agent en moins d'une minute. Les clés et la logique de valeur embarquées dans l'archive sont exposées au même titre : secrets et logique métier dans l'ASAR détaille quoi retirer du client, et le guide pour éditeurs où déplacer la valeur. Pour auditer votre propre application, l'analyse statique suffit et ne lance rien ; pour un binaire tiers inconnu, travaillez en environnement isolé (REA n'est pas un sandbox). Le cadre juridique change aussi : n'analysez qu'un logiciel que vous êtes autorisé à examiner, et sachez que décompiler celui d'un tiers relève de l'interopérabilité, de la correction d'erreurs ou d'une autorisation de l'éditeur, points d'attention détaillés dans clean-room ou reverse engineering.
Pour l'architecture de l'outil et son installation, voir REA expliqué en trois schémas.
Questions fréquentes
Faut-il Ghidra pour analyser une application Electron ?
Non. L'analyse statique JavaScript de REA tourne avec Node.js et npm. Un moteur natif ne sert que pour descendre dans les add-ons .node compilés.
REA lit-il le code serveur de l'application ?
Non. Il lit ce qui est installé sur le poste. Le code et les données servis à distance restent hors de portée.
Les noms minifiés sont-ils résolus ?
Souvent non, et REA les marque comme inconnus : 43 004 éléments dans le test sur Slack. La minification ralentit peu les comptages structurels, qui concordaient avec grep dans le test du 11 octobre.
Auditer avant d'être audité
L'offre AI Cyber part du code de vos applications, Electron compris, pour repérer ce qu'un agent extérieur pourrait en tirer et corriger avant publication.
Sources
- morluto/rea, README (tableau « What you can analyze »), github.com/morluto/rea, consulté le 15 octobre 2026.
- morluto/rea, Electron fuse state (docs/electron-fuses.md), github.com, consulté le 21 octobre 2026.
- 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).
- Javier Cañete Arroyo (Jacar Systems), REA: ingeniería inversa con tu agente de código, probada con Ghidra y Electron, jacar.es, 19 octobre 2026.
- Connor Turland, What is REA (Reverse Engineer Anything)? I ran it on Slack to find out, atcyrus.com, 20 octobre 2026.
Savoir ce qu'un agent lit de votre application Electron avant qu'un autre le fasse
Découvrir AI CyberArticles similaires
Lire une sortie REA : preuves, pseudocode et hallucinations
Une sortie REA mêle preuves localisées, déductions et inconnues. Méthode de revue en trois états, illustrée par les tests publics d'octobre 2026 (744 limitations sur une app Electron, 43 004 inconnues sur Slack), et passage au golden master.
Les limites réelles de REA : taille des sorties, coût, couverture
59,2 Mo de sortie pour une app Electron de 100 Mo, un catalogue d'outils de près de 2 Mo en 6.4.0, deux preloads manqués : les limites de REA mesurées par les tests indépendants d'octobre 2026, et ce que la 6.7.0 a changé au 20 octobre.
Applications Electron : secrets et logique métier exposés dans l'ASAR
L'archive app.asar d'une application Electron se lit sans la lancer : un agent équipé de REA y cartographie modules, canaux IPC et add-ons natifs en une minute. Ce qu'un éditeur doit retirer de son client, et ce que l'intégrité de l'archive protège ou non.
Votre logiciel est lisible par n'importe quel agent : guide pour éditeurs
Avec REA, un agent cartographie une application Electron, une assembly .NET ou une APK sans son code source. Ce qu'un éditeur ne peut plus cacher dans le client, où déplacer la valeur, et ce que la licence et le droit protègent encore.