pierandrearizzo01/Claude

REA

Utilisez REA lorsqu'une affirmation dépend d'un binaire ou d'un package livré, d'une décompilation, de preuves passives d'exécution d'application, ou d'une comparaison avec un comportement non établi par la source disponible. Pour l'analyse ordinaire d'un dépôt source complet, utilisez les outils de dépôt normaux et n'exécutez pas de diagnostics ou de commandes de fournisseur REA.

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, passez directement à la cible. N'exécutez pas de diagnostics ou de configuration avant chaque investigation. Utilisez la liste d'outils réelle et les schémas d'entrée du serveur connecté ; une compétence installée à partir de la branche principale du dépôt peut décrire des capacités absentes d'une version npm plus ancienne. Conservez des preuves intégrales en ligne 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 bloqueur observé, poursuivez le travail utile pris en charge, et reprenez la tâche originale après réparation. L'approbation du client, le PATH du shell, l'enregistrement et la disponibilité du moteur ont des correctifs différents ; évitez de répéter la configuration pour tous.

1. Diagnostiquez sans modifier la configuration REA ou du client. npx peut télécharger le package et écrire dans le cache de npm. Pour Codex, exécutez npx -y [email protected] doctor --client codex --json. Remplacez par le client pris en charge actuel : 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 limité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 JavaScript statique n'a besoin ni de Hopper ni de Ghidra, et l'inspection Android a des prérequis distincts BYO JADX/Java.
3. Pour une réparation de configuration, préparez le plan en lecture seule : npx -y [email protected] 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 la configuration ou n'installe Hopper. La configuration installe normalement la compétence groupée correspondante également ; incluez ce remplacement dans le plan examiné. Après approbation, appliquez la même portée avec npx -y [email protected] setup --client codex --yes. Ajoutez --install-hopper uniquement si cette installation séparée é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 verrouillé par version ou continuez via la CLI.

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

npx -y [email protected] analyze-javascript-application /absolute/path/to/app --json

Aucun enregistrement MCP ni moteur natif n'est requis. Lisez les preuves, graphiques, limitations et inconnues retournés avec le même soin qu'un résultat MCP ; la CLI retourne directement l'enregistrement de preuves. 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 CLI rea existante. Lorsqu'aucune n'est installée et que l'acquisition du package REA est dans la portée autorisée, utilisez npx -y [email protected] à sa place. La réparation de configuration commence par un plan de configuration en lecture seule ; montrez les chemins, sauvegardes et remplacement de compétence avant d'appliquer les modifications autorisées. Préservez les limites d'approbation et d'exécution de cible existantes. 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'archive à cible active ; les outils sans cible prennent leur propre chemin ou point d'extrémité explicite et n'en ont pas besoin.

• ASAR ou arbre JavaScript/Electron extrait : 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 APK Android, classes, méthodes ou références entrantes : inspect_android_package, puis outils Android ciblés lorsqu'ils sont 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'elle est annoncée. 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 ; consultez le guide du firmware.

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

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

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

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

• Capture HAR/SAZ/mitmproxy native/qlog aioquic conservée : inspect_web_network_capture. Sélectionnez les ordinaux d'enregistrement originaux lorsque c'est utile ; inspectez les champs producteurs et les sidecars d'octets/nombres sans récupérer les URL enregistrées ou revendiquer une attribution en direct. Consultez captures historiques pour le profil amont exact et les exclusions de justificatifs. La prise en charge de Qlog commence avec aioquic 1.5.0 JSON 0.3 ; la couverture de flux et les déclarations de perte de point d'extrémité ne récupèrent pas les corps ou n'établissent pas de perte réseau. Préférez un résumé détaillé, puis des pages de trace/flux qlog de type ; sélectionnez une trace, un ID de flux et une direction pour les pages de contribution/plage. Les faits conservent la portée tous-les-événements-enregistrés-avant-sélection. Les autres mises en page qlog et la corrélation PCAP ne sont pas prises en charge.

• Exécution Electron appartenant à l'utilisateur déjà ouverte : list_electron_targets. Avant une tentative d'Inspecteur 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/pagez les enregistrements pertinents ; les enregistrements n'établissent pas de trafic observé.

• Captures de paquets enregistrées : inspect_packet_capture avec les champs TShark sélectionnés, les filtres d'affichage et les 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 est par défaut de 50 trames correspondantes ; utilisez match_offset / match_limit pour les pages ultérieures, ou une limite nulle explicite pour une sortie correspondante complète. Préservez le digest source entre les pages. Cela n'effectue pas de capture en direct. Pour les résumés d'adresse/DNS/SNI/protocole, utilisez inspect_pcap_capture avec le résumé détaillé MCP, puis des pages pcap de type conservé. 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é du 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 d'un décodeur sélectionné, y compris les canaux et options. Interrogez et pagez les détails pertinents avant de choisir les paramètres ; cela ne scanne pas le matériel.

• Traces logiques/de signaux enregistrées : decode_signal_recording avec le décodeur, le canal et les paramètres de protocole explicites. Sur Linux avec util-linux prlimit, fournissez sigrok-cli 0.7.2 via REA_SIGROK_COMMAND ; voir guide d'enregistrement. La sortie est par défaut de 50 lignes littérales ; sélectionnez les classes d'annotation et pagez 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 digests source entre les pages. Ceci lit des fichiers existants ; n'acquiert pas de signaux matériels.

• Artéfact 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 colle JavaScript et les chemins candidats explicitement et préservez l'ambiguïté URL/chemin. Pas de récupération implicite ou d'exécution de cible ; WAT n'est pas la source originale. Voir le guide WASM.

• Porteur de bytecode EVM local explicite : inspect_evm_interface avec un encodage raw ou hex choisi par l'appelant. Préservez les digests porteur/décodés et traitez les sélecteurs, chaînes d'arguments et mutabilité comme des candidats inférés ; cela n'effectue pas de recherche de chaîne ou d'exécution de cible. Pour l'interface inférée complète sans hex ou stdout en double, découvrez la prise en charge et sélectionnez detail: "summary" ; les preuves complètes restent conservées sous leur identité originale. Utilisez le parent_evidence_id retourné pour une fonction exacte ou des 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ètres de construction Go intégrés : 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 source ; l'absence de métadonnées ne prouve pas qu'un binaire n'est pas Go, et les enregistrements de texte non analysés restent explicites. Voir le guide binaire Go.

• Métadonnées de dépendances Rust cargo-auditable intégrées : inspect_rust_binary avec le fichier local explicite ELF, PE ou Mach-O mince. 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épendance 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 en lecture seule /rustc/<40-hex>/. Voir le guide binaire 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 les limites SQLite natives. Lisez le schéma d'abord (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 table sélectionnée et 20 lignes ; demandez schema_scope: "database" pour le schéma stocké complet. Préservez 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 active a été copiée atomiquement. Voir le guide SQLite.

• Fichier ELF Linux explicite pour la mise en page hors ligne, les symboles, les relocalisations ou les 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 ses limites d'inférence/couverture ; voir le guide binaire hors ligne.

• Core ELF x86-64 Linux 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 uniquement aident ; voir le guide de crash enregistré.

• Arbres 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 des outils d'analyse ciblés directement ; appelez binary_overview lorsque le contexte de métadonnées ou d'inventaire est utile et disponible auprès 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 de 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. Le headless moderne...