REA peut cartographier une application JavaScript ou Electron locale à partir des fichiers que vous êtes autorisé à examiner, même sans disposer de son arborescence de code source. Le résultat utile est une piste de preuves pour un comportement : quel module l’expose, où un appel franchit une frontière de processus et quels éléments doivent encore être vérifiés séparément. Ce guide s’appuie sur la documentation actuelle du projet REA, vérifiée le 14 octobre 2026. BIG CHANGE n’a pas exécuté REA sur une application.

Le grand changement

  • Ce qui a changé : REA fournit à un agent de programmation une carte structurée des modules, imports, source maps, routes et échanges IPC d’Electron à partir d’un dossier d’application ou d’un ASAR fourni. Chaque constat peut renvoyer aux fichiers qui l’ont produit.
  • Pourquoi c’est important : Un développeur qui enquête sur une fonctionnalité peut suivre une API nommée ou un canal IPC dans l’application empaquetée avant de décider quoi inspecter manuellement. La question devient plus précise et les preuves plus faciles à vérifier.
  • Ce qu’il faut surveiller : Les chemins statiques sont des possibilités, pas la preuve que l’application les emprunte pendant son utilisation. Une affirmation sur un comportement précis nécessite toujours une observation indépendante ou un test sur une cible autorisée.

Avant de commencer

Ce parcours s’adresse à un développeur qui possède une application JavaScript ou Electron locale, ou qui est autorisé à l’inspecter. Il faut le dossier d’application extrait ou son fichier app.asar , ainsi qu’un chemin absolu vers celui-ci. Le manifeste du paquet indique rea-agents version 6.4.0 et exige Node.js 22.19 ou plus récent dans la branche 22.x, 24.11 ou plus récent dans la branche 24.x, ou 26 et ultérieur. npm est également nécessaire. Sous Linux, l’analyse statique JavaScript/Electron de REA exige un programme compatible avec procps ps sur REA PATH pour vérifier la propriété des processus, comme l’explique son guide d’installation. Ce sont des exigences pour l’hôte REA, distinctes de celles de l’application cible.

Le flux statique JavaScript ne nécessite ni Hopper, Ghidra, IDA, navigateur ni processus Electron en cours d’exécution. Ces outils relèvent d’autres flux REA. Vérifiez vos droits d’inspection et conservez une copie des fichiers d’origine afin de savoir précisément quel artefact a produit chaque résultat. Utilisez le morluto/rea dépôt officiel ou le paquet npm qui y est lié ; un dépôt au nom similaire ne prouve pas sa provenance.

1. Configurer REA ou utiliser la CLI ponctuelle

Pour un agent de programmation connecté, la commande de configuration documentée est :

Terminal
npx rea-agents setup

Examinez les changements proposés à la configuration de l’agent, approuvez ceux que vous souhaitez, puis redémarrez-le. Pour une inspection depuis le terminal, la commande documentée ci-dessous appelle le paquet pour cette exécution. @latest sélectionne la version disponible au moment de l’exécution ; consignez la version résolue avec vos preuves, car le détail des sorties peut évoluer. La version 6.4.0 ci-dessus est celle du manifeste consulté lors de la vérification de cet article, le 14 octobre.

2. Analyser les fichiers fournis

Remplacez le chemin d’exemple par le chemin absolu du dossier de l’application autorisée ou de son ASAR :

Terminal
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json > app-evidence.json

Le guide de la CLI avertit que les éléments de preuve complets peuvent être très volumineux. Enregistrez-les dans un fichier, puis consultez un résumé ou la vue d’un module choisi. Évitez de coller tout le résultat dans un prompt. Si la commande échoue, conservez l’erreur et le chemin cible pour le diagnostic ; un code de sortie nul peut tout de même s’accompagner d’une couverture partielle, d’avertissements ou de constats non résolus. Sous Windows, le README montre un chemin tel que "D:/apps/example".

La référence sur la reconstruction d’artefacts indique que cette opération lit les fichiers sélectionnés comme des données sans exécuter l’application. Elle inventorie les chemins et empreintes des artefacts, analyse le JavaScript et TypeScript disponibles et signale les points d’entrée possibles, imports, source maps, routes, points de terminaison réseau, liens entre preload et renderer d’Electron, contextBridge API, appels et gestionnaires IPC, ainsi que les demandes de modules natifs. Le résultat attendu est un enregistrement Evidence comprenant un graphe, un résumé Electron statique, la couverture et les limites. Une .node est une relation à examiner, pas le décodage de ce module natif.

3. Suivre une fonctionnalité précise

Choisissez une fonctionnalité dont vous pouvez retrouver le nom, par exemple une action de menu ou une méthode d’API exposée. Notez son nom visible par l’utilisateur et recherchez dans le résultat REA le module correspondant, le canal IPC littéral ou la route. Suivez dans l’ordre les emplacements signalés : appel depuis le renderer ou la page, pont preload, transmission IPC, gestionnaire correspondant du processus principal, puis opération de fichier ou de service qu’il appelle. L’exemple CSV d’Electron de REA illustre ce schéma avec notes.exportCsv() , le canal notes:export et un rédacteur du processus principal. Ces noms appartiennent à l’application d’exemple ; la vôtre en aura d’autres.

Pour chaque lien, consignez l’empreinte de l’artefact, le chemin du fichier, l’emplacement et ce que le code montre réellement. Distinguez un canal littéral associé à un gestionnaire d’un canal calculé ou d’une association ambiguë. Consultez les champs de couverture et de limites avant de conclure à l’absence d’un module ou d’un gestionnaire. REA précise qu’un fichier mal formé ou indisponible, des octets compagnons d’ASAR manquants, des expressions non résolues ou une analyse bornée peuvent laisser des relations inconnues. Une source map peut révéler les noms du code d’origine, mais l’outil ne promet pas de retrouver l’arborescence source initiale.

4. Vérifier le comportement de façon indépendante

Formulez une affirmation réfutable à partir de la piste statique, par exemple : « cette action appelle ce canal et le gestionnaire écrit ce type de fichier ». Utilisez ensuite un environnement de test approuvé pour effectuer uniquement cette action et observer directement le résultat : fichier créé, état modifié ou trace recueillie avec vos propres autorisations. Consignez la version de l’application, l’empreinte de l’artefact, les étapes du test et le résultat observé. Si vous n’êtes pas autorisé à exécuter l’application, limitez l’affirmation au chemin de code statique. L’exemple de REA indique explicitement que le chemin déduit peut être vérifié par capture à l’exécution ; le graphe statique seul ne montre pas quelle branche a été exécutée.

La vérification est réussie lorsqu’un autre développeur peut retrouver les mêmes emplacements source, voir les limites de l’association statique et répéter votre contrôle ciblé. Une commande d’analyse réussie ne vérifie pas à elle seule le comportement à l’exécution et n’établit pas une réimplémentation fidèle de l’application.

Si le résultat est incomplet

Vérifiez d’abord que le chemin pointe vers un dossier extrait complet ou un ASAR et que les éventuels .asar.unpacked fichiers compagnons nécessaires sont présents. Examinez la couverture et les diagnostics de REA ; une source manquante ou en échec est inconnue, et non un constat négatif. Pour une grande application, la référence documente les sélections --source-path exactes, mais les fichiers non sélectionnés restent hors du périmètre d’analyse. Si une correspondance IPC littérale est ambiguë ou si le canal est calculé, examinez les fichiers cités et resserrez la question. Conservez l’ambiguïté dans les notes finales si elle subsiste.

Le code de REA est sous licence MIT, mais le logiciel cible et tout moteur d’analyse externe conservent leurs propres licences et conditions. L’analyse statique traite les fichiers cibles localement. Si vous transmettez les constats de REA à un agent de programmation, le fournisseur du modèle applique sa propre politique de données ; évitez d’envoyer des secrets ou des résultats propriétaires avant autorisation de votre organisation. Vérifiez les conditions et les coûts de l’agent et de tout moteur facultatif. La procédure et la version du paquet ont été vérifiées le 14 octobre 2026 et reposent sur la documentation.