Prompt-Motion/ReaReverse

REA

Verwenden Sie REA, wenn eine Behauptung von einer ausgelieferten Binärdatei oder einem Paket, einer Dekompilierung, passiven Anwendungslaufzeitevidenz oder einem Vergleich mit Verhalten abhängt, das nicht durch verfügbaren Quellcode belegt ist. Verwenden Sie für die gewöhnliche Analyse eines vollständigen Quellcode-Repositorys die normalen Repository-Tools und führen Sie keine REA-Bereitschafts- oder Provider-Befehle aus.

Nur verbinden, wenn nötig

Die Installation dieses Skills liefert Anweisungen; sie registriert nicht den REA MCP- Server, installiert keine Analyse-Engines oder fügt Tools zu einem bereits laufenden Agenten hinzu.

Wenn REA-Tools verfügbar sind und ihre Registrierung nicht als veraltet bekannt ist, gehen Sie direkt zum Ziel. Führen Sie vor jeder Untersuchung keine Diagnose oder Einrichtung durch. Verwenden Sie die tatsächliche Werkzeugliste und Eingabeschemata des verbundenen Servers; ein aus dem Repository-Master installierter Skill kann Funktionen beschreiben, die in einer älteren npm-Version fehlen. Bewahren Sie vollständige Inline-Evidenz auf, wenn dieser Server keine beibehaltenen Referenzen anbietet.

Wenn Tools fehlen, ein Aufruf durch den Client blockiert wird oder ein erforderlicher Provider nicht verfügbar ist, lesen Sie Verbindung und Wiederherstellung. Diagnostizieren Sie den beobachteten Blocker, setzen Sie nützliche unterstützte Arbeit fort und nehmen Sie die ursprüngliche Aufgabe nach der Reparatur wieder auf. Die Zustimmung des Clients, der Shell-PATH, die Registrierung und die Engine- Verfügbarkeit haben unterschiedliche Abhilfemaßnahmen; vermeiden Sie es, die Einrichtung für alle zu wiederholen.

1. Diagnostizieren Sie, ohne die REA- oder Client-Konfiguration zu ändern. npx kann das Paket herunterladen und in den npm-Cache schreiben. Führen Sie für Codex folgenden Befehl aus: npx -y rea-agents@latest doctor --client codex --json. Ersetzen Sie den aktuellen unterstützten Client: claude_code, claude_desktop, codex, cursor, gemini_cli, windsurf, devin, opencode, antigravity, copilot_cli, commandcode, vscode, grok_build, omp oder grok_bot. grok_bot hat keine lokale Dateiregistrierung: doctor meldet den Grok Bot Chat-Schritt, und die Einrichtung schreibt kein mcp.json. Wenn der Client unbekannt ist, verwenden Sie doctor --json und überprüfen Sie seine Registrierungsergebnisse, bevor Sie einen Einrichtungsbereich wählen.
2. Unterscheiden Sie den Grund. Eine fehlende, fehlerhafte oder veraltete Registrierung erfordert eine gezielte Konfigurationsreparatur. Eine korrekte Registrierung ohne Tools in der aktiven Sitzung erfordert einen Neustart/Neuverbindung; doctor kann nicht beweisen, dass der aktuelle Agent verbunden ist. Ein fehlender Provider betrifft nur Aufgaben, die diesen Provider erfordern: Die statische JavaScript-Überprüfung benötigt weder Hopper noch Ghidra, und die Android-Überprüfung hat separate BYO-JADX/Java-Voraussetzungen.
3. Bereiten Sie für eine Konfigurationsreparatur den schreibgeschützten Plan vor: npx -y rea-agents@latest setup --client codex --dry-run --json. Verwenden Sie die ID des aktuellen Clients, zeigen Sie die genauen vorgeschlagenen Pfade, Backups und Änderungen an, und holen Sie die Zustimmung ein, bevor die Einrichtung die Konfiguration schreibt oder Hopper installiert. Die Einrichtung installiert normalerweise auch den passenden gebündelten Skill; schließen Sie diesen Austausch in den überprüften Plan ein. Wenden Sie nach der Zustimmung denselben Bereich mit npx -y rea-agents@latest setup --client codex --yes an. Fügen Sie --install-hopper nur hinzu, wenn diese separate Installation erforderlich und ausdrücklich genehmigt wurde.
4. Starten/verbinden Sie den betroffenen Agenten neu. Überprüfen Sie, ob die REA-Tools tatsächlich in der Sitzung erscheinen, und setzen Sie dann die ursprüngliche Untersuchung fort. Wenn sie weiterhin fehlen, überprüfen Sie den MCP-Startfehler des Clients, anstatt die Einrichtung zu wiederholen.

Die REA-Einrichtung installiert oder aktualisiert niemals Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk oder Unblob. Verwenden Sie vorhandene Voraussetzungen; installieren Sie keine nicht verwandte Software, um die MCP-Registrierung zu reparieren. Verwenden Sie für einen nicht unterstützten Client die manuelle stdio-Registrierung mit einem versionspinnen rea-agents-Paket oder fahren Sie über die CLI fort.

Ein konkreter CLI-Fallback für einen vom Bediener bereitgestellten JavaScript-Baum oder ASAR ist:

npx -y rea-agents@latest analyze-javascript-application /absoluter/pfad/zur/app --json

Es ist keine MCP-Registrierung oder native Engine erforderlich. Lesen Sie die zurückgegebenen Evidence, Diagramme, Einschränkungen und Unbekannten mit der gleichen Sorgfalt wie ein MCP-Ergebnis; die CLI gibt den Evidence-Datensatz direkt zurück. Dieser Fallback beweist nicht, dass MCP konfiguriert ist. Native CLI-Aufgaben erfordern weiterhin ihre ausgewählte Engine. Bevorzugen Sie eine vorhandene rea-CLI. Wenn keine installiert ist und die Beschaffung des REA-Pakets innerhalb des autorisierten Bereichs liegt, verwenden Sie stattdessen npx -y rea-agents@latest. Die Konfigurationsreparatur beginnt mit einem schreibgeschützten Einrichtungsplan; zeigen Sie Pfade, Backups und Skill-Austausch an, bevor Sie autorisierte Änderungen anwenden. Bewahren Sie die bestehende Genehmigung und die Grenzen der Zielausführung. Die REA-Einrichtung installiert oder aktualisiert niemals nicht verwandte Software, einschließlich Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk oder Unblob.

Zuerst das Ziel routen

Wählen Sie das erste Tool aus dem vom Benutzer angegebenen Ziel. Verwenden Sie open_binary für aktive native oder Archiv-Workflows; zielfreie Tools verwenden ihren eigenen expliziten Pfad oder Endpunkt und benötigen ihn nicht.

• ASAR oder extrahierter JavaScript/Electron-Baum: analyze_javascript_application.

• Archiv-/Paketmitgliederbestand (ZIP/APK/IPA/MSIX/AppX oder DMG): open_binary mit dem angegebenen lokalen Pfad; verwenden Sie inspect_artifact, wenn dessen Diagramm und Ergebnisse bei der Beantwortung der Frage helfen.

• Android APK-Code, Klassen, Methoden oder eingehende Referenzen: inspect_android_package, dann fokussierte Android-Tools, wenn angekündigt. Der Archivmitgliederbestand verwendet weiterhin den obigen Archivweg.

• Verwaltete PE/CLI-Assembly: inspect_managed_artifact.

• Firmware-Image: inspect_firmware_regions, wenn angekündigt. Verwenden Sie extract_firmware, wenn eine Extraktion angefordert wird, mit einem vom Aufrufer ausgewählten neuen absoluten Ausgabeverzeichnis. Diese Tools verwenden vom Aufrufer bereitgestelltes Binwalk/Unblob auf Linux; siehe die Firmware-Anleitung.

• .NET NativeAOT PE/ELF: native Ghidra-Analyse. Nativer Code kann Pseudocode liefern; konsultieren Sie den NativeAOT-Workflow in references/native-and-artifacts.md für optionale Metadatenwiederherstellung und seine unterstützte Host/Layout-Grenze.

• Benutzereigene Browserseite bereits geöffnet: list_browser_targets.

• Browseraktion, die der Agent ausführen muss (klicken, tippen, navigieren): capture_browser_scenario mit deklarierten Aktionen. Siehe Laufzeitbeobachtung für Verbinden/Starten und die fokussierten Folge-Browser-Tools.

• Fiddler Everywhere-Verkehr oder eine native .saz-Aufnahme: Lesen Sie die Fiddler-Workflow. Untersuchen Sie gespeicherte SAZ mit inspect_web_network_capture und format: "saz"; verbinden Sie den separaten MCP-Server von Everywhere für Live-Verkehr.

• Beibehaltene HAR/SAZ/native mitmproxy/aioquic qlog-Aufnahme: inspect_web_network_capture. Wählen Sie bei Bedarf ursprüngliche Datensatzordinals; überprüfen Sie Produzentenfelder und Byte/Nummer Sidecars, ohne aufgezeichnete URLs abzurufen oder Live-Zuschreibung zu beanspruchen. Siehe historische Aufnahmen für das genaue Upstream- Profil und die Ausnahmen von Anmeldeinformationen. Die Qlog-Unterstützung beginnt mit aioquic 1.5.0 JSON 0.3; Stream-Abdeckung und Endpunkt-Verlustdeklarationen stellen keine Körper wieder her oder stellen Netzwerkverlust fest. Bevorzugen Sie Detailzusammenfassung, dann Art qlog trace/stream Seiten; wählen Sie eine Spur, Stream-ID und Richtung für Beitrags-/Bereichsseiten. Fakten behalten den Bereich aller aufgezeichneten Ereignisse vor der Auswahl bei. Andere qlog-Layouts und PCAP-Korrelation werden nicht unterstützt.

• Benutzereigene Electron-Laufzeit bereits geöffnet: list_electron_targets. Versuchen Sie vor einem electron-main Inspector-Versuch, gepackte Sicherungen mit inspect_electron_fuses zu überprüfen; deaktiviertes EnableNodeCliInspectArguments bedeutet, dass die App --inspect ignoriert.

• Paketfeld-Erkennung: inspect_packet_fields durchsucht installierte Protokolle und Feldnamen/-typen, bevor Felder für inspect_packet_capture ausgewählt werden. Fragen/Seiten Sie die relevanten Datensätze ab; Registrierungen belegen keinen beobachteten Verkehr.

• Aufgezeichnete Paketaufnahmen: inspect_packet_capture mit ausgewählten TShark-Feldern, Anzeigefiltern und Decode-as-Regeln. Erfordert Linux, util-linux prlimit und REA_TSHARK_COMMAND; siehe Aufnahme-Anleitung. Paketgrenzen zählen Eingangspakete vor dem Filtern. Die Ausgabe standardmäßig 50 übereinstimmende Frames; verwenden Sie match_offset / match_limit für spätere Seiten oder explizite null Grenze für vollständige übereinstimmende Ausgabe. Bewahren Sie den Quell-Hash über Seiten hinweg. Dies führt keine Live-Aufnahme durch. Verwenden Sie für Adress-/DNS-/SNI-/Protokollzusammenfassungen inspect_pcap_capture mit MCP Detailzusammenfassung, dann beibehaltene Art pcap-Seiten. Erfordert Wireshark 4.x tshark und capinfos, mit Linux prlimit oder Windows Job Objects; siehe Paketzusammenfassungen. Wählen Sie eine genaue DNS-Frage für Adressseiten; Seitenerschöpfung beweist nicht Netzwerkvollständigkeit. Dies liest Aufnahmen und erfasst keinen Verkehr.

• Decoder-Erkennung: inspect_signal_decoders durchsucht installierte Decoder-IDs oder ausgewählte Decoder-Hilfe, einschließlich Kanäle und Optionen. Fragen und seiten Sie die relevanten Details ab, bevor Sie Einstellungen wählen; dies scannt keine Hardware.

• Aufgezeichnete Logik-/Signal-Spuren: decode_signal_recording mit explizitem Decoder, Kanal- und Protokolleinstellungen. Stellen Sie auf Linux mit util-linux prlimit sigrok-cli 0.7.2 über REA_SIGROK_COMMAND bereit; siehe Aufnahme-Anleitung. Die Ausgabe standardmäßig 50 Literalzeilen; wählen Sie Annotationsklassen und seiten Sie mit line_offset / line_limit oder explizitem null für alle verbleibenden Ausgaben. Fensterzählungen sind Anzeigezeilen, keine Annotationen oder Samples. Bewahren Sie Quell-Hashes über Seiten hinweg. Dies liest vorhandene Dateien; es erfasst keine Hardware-Signale.

• Explizites lokales WebAssembly-Artefakt: inspect_wasm_artifact. Stellen Sie WABT 1.0.42 über REA_WABT_BIN_DIRECTORY bereit; behalten Sie die genaue Byte-/Tool-Identität und dekodiertes WAT bei. Wählen Sie JavaScript-Kleber und Kandidatenpfade explizit aus und bewahren Sie URL-/Pfad- Mehrdeutigkeit. Kein impliziter Fetch oder Zielausführung; WAT ist kein ursprünglicher Quellcode. Siehe die WASM-Anleitung.

• Expliziter lokaler EVM-Bytecode-Träger: inspect_evm_interface mit vom Aufrufer ausgewähltem raw oder hex-Encoding. Bewahren Sie Träger-/dekodierte Hashes und behandeln Sie Selektoren, Argumentstrings und Veränderbarkeit als abgeleitete Kandidaten; dies führt keine Chain-Suche oder Zielausführung durch. Entdecken Sie für die vollständige abgeleitete Schnittstelle ohne hex oder duplizierten stdout die Unterstützung und wählen Sie detail: "summary"; vollständige Evidence bleibt unter ihrer ursprünglichen Identität erhalten. Verwenden Sie die zurückgegebene parent_evidence_id für exakte Funktion oder bytecode_hex/stdout/stderr-Seiten. Kandidatenabdeckung beweist keine Schnittstellenvollständigkeit. Siehe die EVM-Bytecode-Anleitung.

• Eingebettete Go-Compiler-, Modul- oder Build-Einstellungs-Metadaten: inspect_go_binary mit der expliziten lokalen Datei. Diese integrierte zielfreie Inspektion erfordert keine Go-Installation oder Disassembler. Bewahren Sie rohe Modulbytes und Quellbereiche; fehlende Metadaten beweisen nicht, dass eine Binärdatei kein Go ist, und ungeparste Textdatensätze bleiben explizit. Siehe die Go-Binär-Anleitung.

• Eingebettete cargo-auditable Rust-Abhängigkeitsmetadaten: inspect_rust_binary mit der expliziten lokalen ELF-, PE- oder Thin-Mach-O-Datei. Diese integrierte zielfreie Inspektion erfordert keine Rust-Installation oder Disassembler. Bewahren Sie Paketreihenfolge, Abhängigkeitsindizes und den Abschnittsdateibereich. Ein fehlender .dep-v0-Abschnitt sind null Metadaten, kein Beweis dafür, dass die Binärdatei keine Abhängigkeiten hat. Ein rustc-Commit-Hash ist eine Ableitung aus einem schreibgeschützten /rustc/<40-hex>/-Pfad. Siehe die Rust-Binär-Anleitung.

• Expliziter lokaler SQLite-Datenbank-Snapshot: inspect_sqlite_database. Untersuchen Sie mit Node.js 24.x >=24.15 oder 26+, das native SQLite-Grenzen bereitstellt. Lesen Sie das Schema zuerst (kompaktes Inventar standardmäßig) oder wählen Sie eine genaue normale Tabelle und columns, wenn Zeilen benötigt werden. Standardmäßig werden das ausgewählte Tabellenschema und 20 Zeilen verwendet; fordern Sie schema_scope: "database" für das vollständige gespeicherte Schema an. Bewahren Sie sowohl die Datenbank als auch die vorhandene WAL-Identität des Geschwisters; Zeilenproben melden Abschneidung und haben keine bestimmte Reihenfolge. Verwenden Sie einen ruhenden Snapshot anstatt anzunehmen, dass ein Live-Datenbank/WAL-Paar atomar kopiert wurde. Siehe die SQLite-Anleitung.

• Explizite Linux-ELF-Datei für Offline-Layout, Symbole, Relokationen oder statische Mitigations-Evidenz: inspect_binary_layout. Diese zielfreie Operation verwendet vom Aufrufer bereitgestelltes pwntools, ohne eine Disassembler-Datenbank zu öffnen. Bewahren Sie ihre rohen Speicherorte und Inferenz-/Abdeckungsgrenzen; siehe die Offline-Binär-Anleitung.

• Bereitgestellter Linux x86-64 ELF-Core: inspect_recorded_crash. Lesen Sie jeden aufgezeichneten Thread, rohe Notiz und quellgebundene Register, ohne ein Live-Ziel zu öffnen. Historische PIDs wählen keine Live-Prozesse aus. Fordern Sie include_debugger_context nur an, wenn Core-only-Mapping-Kandidaten helfen; siehe die Aufgezeichnete Absturz-Anleitung.

• PE-Ressourcentyp/Name/Sprachbäume und statische Icon-Gruppenreferenzen: inspect_pe_resources mit einem expliziten Pfad. Diese tragbare Operation erfordert kein aktives Ziel oder Engine; undurchsichtige Nutzlasten behalten Dateibereiche und SHA-256.

• Native ausführbare Datei, Bibliothek oder Analysedatenbank: open_binary, dann verwenden Sie fokussierte Analysetools direkt; rufen Sie binary_overview auf, wenn Metadaten oder Inventarkontext nützlich sind und vom ausgewählten Provider verfügbar sind.

Für eine vorhandene IDA MCP-Konfiguration verwenden Sie open_binary mit der ursprünglichen Eingabe-Binärdatei und provider_id: "ida"; übergeben Sie keine .idb- oder .i64-Datenbank. Das Legacy-Attached-Profil bindet die bereits geöffnete GUI-Eingabe per SHA-256 und lässt ihre Datenbank geöffnet.