Prompt-Motion/ReaReverse

REA

Utilisez REA lorsqu'une affirmation dépend d'un binaire ou d'un package livré, de la décompilation, des preuves passives de l'environnement d'exécution de l'application, ou d'une comparaison avec un comportement non établi par le code source disponible. Pour l'analyse ordinaire d'un référentiel source complet, utilisez les outils normaux du référentiel et n'exécutez pas de commandes REA de préparation ou de fournisseur.

Connectez-vous uniquement lorsque nécessaire

L'installation de cette compétence fournit des instructions ; elle n'enregistre pas le serveur MCP REA, n'installe pas de moteurs d'analyse et n'ajoute pas d'outils à un agent déjà en cours d'exécution.

Si les outils REA sont disponibles et que leur enregistrement n'est pas connu comme étant obsolète, procédez directement à la cible. N'exécutez pas de diagnostics ou de configuration avant chaque investigation. Utilisez la liste réelle des outils et les schémas d'entrée du serveur connecté ; une compétence installée depuis la branche principale du référentiel peut décrire des capacités absentes d'une ancienne version npm. Conservez des preuves en ligne complètes lorsque ce serveur n'annonce pas de références conservées.

Si les outils sont absents, qu'un appel est bloqué par le client, ou qu'un fournisseur requis est indisponible, lisez connexion et récupération. Diagnostiquez le blocage observé, poursuivez un travail utile pris en charge, et reprenez tâche originale après la réparation. L'approbation du client, le PATH du shell, l'enregistrement et la disponibilité du moteur ont des remèdes différents ; évitez de répéter la configuration pour tous.

1. Diagnostiquez sans modifier la configuration de REA ou du client. npx peut télécharger le package et écrire dans le cache npm. Pour Codex, exécutez npx -y rea-agents@latest doctor --client codex --json. Remplacez par le client actuellement pris en charge : claude_code, claude_desktop, codex, cursor, gemini_cli, windsurf, devin, opencode, antigravity, copilot_cli, commandcode, vscode, grok_build, omp ou grok_bot. grok_bot n'a pas d'enregistrement de fichier local : doctor signale l'étape de chat Grok Bot, et la configuration n'écrit pas mcp.json. Si le client est inconnu, utilisez doctor --json et inspectez ses résultats d'enregistrement avant de choisir une portée de configuration.
2. Distinguez la raison. Un enregistrement manquant, malformé ou obsolète nécessite une réparation de configuration ciblée. Un enregistrement aligné sans outils dans la session active nécessite un redémarrage/reconnexion ; doctor ne peut pas prouver que l'agent actuel s'est connecté. Un fournisseur manquant n'affecte que les tâches nécessitant ce fournisseur : l'inspection statique JavaScript n'a besoin ni de Hopper ni de Ghidra, et l'inspection Android a des prérequis JADX/Java distincts (BYO).
3. Pour une réparation de configuration, préparez le plan en lecture seule : npx -y rea-agents@latest setup --client codex --dry-run --json. Utilisez l'ID du client actuel, montrez ses chemins proposés exacts, sauvegardes et modifications, et obtenez l'approbation avant que la configuration n'écrive dans la configuration ou n'installe Hopper. La configuration installe normalement aussi la compétence groupée correspondante ; incluez ce remplacement dans le plan examiné. Après approbation, appliquez la même portée avec npx -y rea-agents@latest setup --client codex --yes. Ajoutez --install-hopper uniquement si cette installation distincte était nécessaire et explicitement approuvée.
4. Redémarrez/reconnectez l'agent concerné. Vérifiez que les outils REA apparaissent réellement dans la session, puis reprenez l'investigation originale. S'ils restent absents, inspectez l'erreur de lancement MCP du client plutôt que de répéter la configuration.

La configuration REA n'installe ni ne met à niveau Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk ou Unblob. Utilisez les prérequis existants ; n'installez pas de logiciels non liés pour réparer l'enregistrement MCP. Pour un client non pris en charge, utilisez un enregistrement stdio manuel avec un package rea-agents à version figée ou continuez via la CLI.

Un repli CLI concret pour une arborescence JavaScript ou un ASAR fourni par l'opérateur est :

npx -y rea-agents@latest analyze-javascript-application /chemin/absolu/vers/app --json

Aucun enregistrement MCP ou moteur natif n'est requis. Lisez les preuves, graphique, limites et inconnues retournés avec le même soin qu'un résultat MCP ; la CLI retourne l'enregistrement des preuves directement. Ce repli n'établit pas que MCP est configuré. Les tâches CLI natives nécessitent toujours leur moteur sélectionné. Préférez une rea CLI existante. Lorsqu'aucune n'est installée et que l'acquisition du package REA est dans le champ autorisé, utilisez npx -y rea-agents@latest à sa place. La réparation de configuration commence par un plan de configuration en lecture seule ; affichez les chemins, sauvegardes et remplacement de compétence avant d'appliquer les modifications autorisées. Préservez l'approbation existante et les limites d'exécution cible. La configuration REA n'installe ni ne met à niveau de logiciels non liés, y compris Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk ou Unblob.

Acheminez d'abord la cible

Choisissez le premier outil à partir de la cible fournie par l'utilisateur. Utilisez open_binary pour les workflows natifs ou d'archives de cible active ; les outils sans cible prennent leur propre chemin ou point de terminaison explicite et n'en ont pas besoin.

• Arborescence JavaScript/Electron extraite ou ASAR : analyze_javascript_application.

• Inventaire des membres d'archive/package (ZIP/APK/IPA/MSIX/AppX ou DMG) : open_binary avec le chemin local fourni ; utilisez inspect_artifact lorsque son graphique et ses résultats aident à répondre à la question.

• Code, classes, méthodes ou références entrantes Android APK : inspect_android_package, puis outils Android ciblés lorsqu'annoncés. L'inventaire des membres d'archive utilise toujours la route d'archive ci-dessus.

• Assembly managé PE/CLI : inspect_managed_artifact.

• Image de firmware : inspect_firmware_regions lorsqu'annoncé. Utilisez extract_firmware lorsque l'extraction est demandée, avec un nouveau répertoire de sortie absolu choisi par l'appelant. Ces outils utilisent Binwalk/Unblob fournis par l'appelant sur Linux ; voir le guide firmware.

• PE/ELF .NET NativeAOT : analyse Ghidra native. Le code natif peut produire du pseudocode ; consultez le workflow NativeAOT dans references/native-and-artifacts.md pour la récupération facultative des métadonnées et sa limite hôte/layout prise en charge.

• Page navigateur déjà ouverte appartenant à l'utilisateur : list_browser_targets.

• Action navigateur que l'agent doit effectuer (clic, saisie, navigation) : capture_browser_scenario avec actions déclarées. Voir observation d'exécution pour la connexion/lancement et les outils navigateur de suivi ciblés.

• Trafic Fiddler Everywhere ou capture .saz native : lisez le workflow Fiddler. Inspectez SAZ enregistré avec inspect_web_network_capture et format: "saz" ; connectez le serveur MCP séparé d'Everywhere pour le trafic en direct.

• Captures HAR/SAZ/mitmproxy native/aioquic qlog conservées : inspect_web_network_capture. Sélectionnez les ordinaux d'enregistrement originaux si utile ; inspectez les champs producteur et les sous-produits octets/nombres sans récupérer les URL enregistrées ni revendiquer d'attribution en direct. Voir captures historiques pour le profil en amont exact et les exclusions d'identification. Le support qlog commence avec aioquic 1.5.0 JSON 0.3 ; la couverture de flux et les déclarations de perte de point de terminaison ne récupèrent pas les corps ou n'établissent pas de perte réseau. Préférez le résumé de détail, puis le type trace/stream qlog pages ; sélectionnez une trace, un ID de flux et une direction pour les pages de contribution/plage. Les faits conservent la portée tous-événements-enregistrés-avant-sélection. Les autres mises en page qlog et la corrélation PCAP ne sont pas prises en charge.

• Runtime Electron déjà ouvert appartenant à l'utilisateur : list_electron_targets. Avant une tentative d'inspection electron-main, vérifiez les fusibles packagés avec inspect_electron_fuses ; EnableNodeCliInspectArguments désactivé signifie que l'application ignore --inspect.

• Découverte de champs de paquets : inspect_packet_fields recherche les protocoles installés et les noms/types de champs avant de choisir des champs pour inspect_packet_capture. Interrogez/parcourez les enregistrements pertinents ; les enregistrements n'établissent pas de trafic observé.

• Captures de paquets enregistrées : inspect_packet_capture avec des champs TShark sélectionnés, des filtres d'affichage et des règles de décodage. Nécessite Linux, util-linux prlimit et REA_TSHARK_COMMAND ; voir guide de capture. Les limites de paquets comptent les paquets d'entrée avant filtrage. La sortie par défaut est de 50 trames correspondantes ; utilisez match_offset / match_limit pour les pages suivantes, ou une limite nulle explicite pour une sortie complète correspondante. Préservez le résumé source à travers les pages. Ceci n'effectue pas de capture en direct. Pour les résumés d'adresse/DNS/SNI/protocole, utilisez inspect_pcap_capture avec résumé de détail MCP, puis les pages conservées de type pcap. Nécessite Wireshark 4.x tshark et capinfos, avec Linux prlimit ou Windows Job Objects ; voir résumés de paquets. Sélectionnez une question DNS exacte pour les pages d'adresse ; l'épuisement de la page ne prouve pas l'exhaustivité réseau. Ceci lit des enregistrements et n'acquiert pas de trafic.

• Découverte de décodeur : inspect_signal_decoders recherche les ID de décodeur installés ou l'aide du décodeur sélectionné, y compris les canaux et options. Interrogez et parcourez les détails pertinents avant de choisir les paramètres ; ceci ne scanne pas de matériel.

• Traces logiques/signaux enregistrées : decode_signal_recording avec décodeur explicite, paramètres de canal et de protocole. Sur Linux avec util-linux prlimit, fournissez sigrok-cli 0.7.2 via REA_SIGROK_COMMAND ; voir guide d'enregistrement. La sortie par défaut est de 50 lignes littérales ; sélectionnez les classes d'annotation et parcourez avec line_offset / line_limit, ou null explicite pour toute la sortie restante. Les comptages de fenêtres sont des lignes d'affichage, pas des annotations ou des échantillons. Préservez les résumés sources à travers les pages. Ceci lit des fichiers existants ; il n'acquiert pas de signaux matériels.

• Artefact WebAssembly local explicite : inspect_wasm_artifact. Fournissez WABT 1.0.42 via REA_WABT_BIN_DIRECTORY ; conservez l'identité exacte octet/outil et le WAT décodé. Sélectionnez le glue JavaScript et les chemins candidats explicitement et préservez l'ambiguïté URL/chemin. Aucune récupération implicite ou exécution cible ; WAT n'est pas la source originale. Voir le guide WASM.

• Porteur de bytecode EVM local explicite : inspect_evm_interface avec raw ou hex codage choisi par l'appelant. Préservez les résumés porteur/décodé et traitez les sélecteurs, chaînes d'argument et mutabilité comme candidats inférés ; ceci n'effectue pas de recherche de chaîne ou d'exécution cible. Pour l'interface inférée complète sans hex ou stdout en double, découvrez le support et sélectionnez detail: "summary" ; les preuves complètes restent conservées sous leur identité originale. Utilisez le parent_evidence_id retourné pour la fonction exacte ou les pages bytecode_hex/stdout/stderr. La couverture candidate n'établit pas l'exhaustivité de l'interface. Voir le guide bytecode EVM.

• Métadonnées de compilateur, module ou paramètre de build Go embarquées : inspect_go_binary avec le fichier local explicite. Cette inspection intégrée sans cible ne nécessite aucune installation Go ou désassembleur. Préservez les octets de module bruts et les plages sources ; des métadonnées absentes ne prouvent pas qu'un binaire n'est pas Go, et les enregistrements de texte non parsés restent explicites. Voir le guide binaires Go.

• Métadonnées de dépendances Rust cargo-auditable embarquées : inspect_rust_binary avec le fichier ELF, PE, ou Mach-O fin local explicite. Cette inspection intégrée sans cible ne nécessite aucune installation Rust ou désassembleur. Préservez l'ordre des packages, les indices de dépendances et la plage de fichiers de section. Une section .dep-v0 manquante est une métadonnée nulle, pas une preuve que le binaire n'a pas de dépendances. Un hash de commit rustc est une inférence à partir d'un chemin /rustc/<40-hex>/ en lecture seule. Voir le guide binaires Rust.

• Capture instantanée de base de données SQLite locale explicite : inspect_sqlite_database. Inspectez avec Node.js 24.x >=24.15 ou 26+ fournissant des limites SQLite natives. Lisez d'abord le schéma (inventaire compact par défaut), ou sélectionnez une table ordinaire exacte et columns lorsque des lignes sont nécessaires. Les valeurs par défaut sont le schéma de la table sélectionnée et 20 lignes ; demandez schema_scope: "database" pour le schéma stocké complet. Préservez à la fois l'identité de la base de données et du WAL frère existant ; les échantillons de lignes signalent la troncature et ont un ordre non spécifié. Utilisez une capture instantanée quiescente plutôt que de supposer qu'une paire base de données/WAL en direct a été copiée atomiquement. Voir le guide SQLite.

• Fichier ELF Linux explicite pour la disposition hors ligne, symboles, relocalisations ou preuves d'atténuation statique : inspect_binary_layout. Cette opération sans cible utilise pwntools fourni par l'appelant sans ouvrir une base de données de désassembleur. Préservez ses emplacements bruts et limites d'inférence/couverture ; voir le guide binaires hors ligne.

• Core ELF Linux x86-64 fourni : inspect_recorded_crash. Lisez chaque thread enregistré, note brute et registre lié à la source sans ouvrir une cible en direct. Les PID historiques ne sélectionnent pas de processus en direct. Demandez include_debugger_context uniquement lorsque les candidats de mappage core-only aident ; voir le guide crash enregistré.

• Arborescences de type/nom/langue de ressources PE et références de groupe d'icônes statiques : inspect_pe_resources avec un chemin explicite. Cette opération portable ne nécessite aucune cible active ou moteur ; les charges utiles opaques conservent les plages de fichiers et SHA-256.

• Exécutable natif, bibliothèque ou base de données d'analyse : open_binary, puis utilisez les outils d'analyse ciblés directement ; appelez binary_overview lorsque le contexte de métadonnées ou d'inventaire est utile et disponible à partir du fournisseur sélectionné.

Pour une configuration IDA MCP existante, utilisez open_binary avec le binaire d'entrée original et provider_id: "ida" ; ne passez pas une base de données .idb ou .i64. Le profil attaché hérité lie l'entrée GUI déjà ouverte par SHA-256 et laisse sa base de données ouverte. L'hôte moderne..