pierandrearizzo01/REA

Was macht REA?

Verwende REA, wenn eine Behauptung auf einer ausgelieferten Binärdatei oder einem Paket, Dekompilierung, passiver Laufzeitevidenz der Anwendung oder einem Vergleich mit einem Verhalten beruht, das nicht durch verfügbaren Quellcode etabliert ist. Für die gewöhnliche Analyse eines vollständigen Quellcode-Repositorys verwende normale Repository-Werkzeuge und führe keine REA-Bereitschafts- oder Provider-Befehle aus.

Nur bei Bedarf verbinden

Die Installation dieser Fähigkeit liefert Anweisungen; sie registriert nicht den REA MCP-Server, installiert keine Analyse-Engines oder fügt Werkzeuge zu einem bereits laufenden Agenten hinzu.

Wenn REA-Werkzeuge verfügbar sind und ihre Registrierung nicht als veraltet bekannt ist, fahre direkt mit dem Ziel fort. Führe keine Diagnosen oder Einrichtung vor jeder Untersuchung durch. Verwende die tatsächliche Werkzeugliste und Eingabeschemata des verbundenen Servers; eine aus dem Repository-Hauptzweig installierte Fähigkeit kann Funktionen beschreiben, die in einer älteren npm-Version fehlen. Bewahre vollständige Inline-Evidenz auf, wenn dieser Server keine beibehaltenen Referenzen anzeigt.

Wenn Werkzeuge fehlen, ein Aufruf durch den Client blockiert wird oder ein erforderlicher Provider nicht verfügbar ist, lies Verbindung und Wiederherstellung. Diagnostiziere den beobachteten Blocker, fahre mit nützlicher unterstützter Arbeit fort und nimm die ursprüngliche Aufgabe nach der Reparatur wieder auf. Client-Genehmigung, Shell-PATH, Registrierung und Engine-Verfügbarkeit haben unterschiedliche Abhilfen; vermeide es, die Einrichtung für alle zu wiederholen.

1. Diagnostiziere, ohne die REA- oder Client-Konfiguration zu ändern. npx kann das Paket herunterladen und in den npm-Cache schreiben. Führe für Codex npx -y [email protected] doctor --client codex --json aus. Ersetze 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, verwende doctor --json und überprüfe seine Registrierungsergebnisse, bevor du einen Einrichtungsbereich wählst.
2. Unterscheide den Grund. Fehlende, fehlerhafte oder veraltete Registrierung benötigt eine gezielte Konfigurationsreparatur. Eine ausgerichtete Registrierung ohne Werkzeuge in der aktiven Sitzung benötigt einen Neustart/Neuverbindung; doctor kann nicht beweisen, dass der aktuelle Agent verbunden ist. Ein fehlender Provider betrifft nur Aufgaben, die diesen Provider erfordern: statische JavaScript-Inspektion benötigt weder Hopper noch Ghidra, und Android-Inspektion hat separate Bring-Your-Own-JADX/Java-Voraussetzungen.
3. Bereite für eine Konfigurationsreparatur den schreibgeschützten Plan vor: npx -y [email protected] setup --client codex --dry-run --json. Verwende die ID des aktuellen Clients, zeige seine genauen vorgeschlagenen Pfade, Backups und Änderungen und hole die Genehmigung ein, bevor setup Konfiguration schreibt oder Hopper installiert. Setup installiert normalerweise auch die passende gebündelte Fähigkeit; schließe diesen Ersatz in den überprüften Plan ein. Nach Genehmigung wende denselben Bereich mit npx -y [email protected] setup --client codex --yes an. Füge --install-hopper nur hinzu, wenn diese separate Installation erforderlich und ausdrücklich genehmigt wurde.
4. Starte den betroffenen Agenten neu/verbinde ihn neu. Überprüfe, ob REA-Werkzeuge tatsächlich in der Sitzung erscheinen, nimm dann die ursprüngliche Untersuchung wieder auf. Bleiben sie abwesend, überprüfe den MCP-Startfehler des Clients, anstatt die Einrichtung zu wiederholen.

REA-Setup installiert oder aktualisiert niemals Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk oder Unblob. Verwende vorhandene Voraussetzungen; installiere keine nicht verwandte Software, um die MCP-Registrierung zu reparieren. Verwende für einen nicht unterstützten Client manuelle stdio-Registrierung mit einem version-pinned rea-agents-Paket oder fahre über die CLI fort.

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

npx -y [email protected] analyze-javascript-application /absoluter/pfad/zu/app --json

Es ist keine MCP-Registrierung oder native Engine erforderlich. Lies die zurückgegebenen Evidenz, den Graphen, die Einschränkungen und Unbekannten mit der gleichen Sorgfalt wie ein MCP-Ergebnis; die CLI gibt den Evidenzdatensatz direkt zurück. Dieser Fallback stellt nicht sicher, dass MCP konfiguriert ist. Native CLI-Aufgaben erfordern weiterhin ihre ausgewählte Engine. Bevorzuge eine vorhandene rea-CLI. Wenn keine installiert ist und die Beschaffung des REA-Pakets im autorisierten Bereich liegt, verwende npx -y [email protected] an seiner Stelle. Die Konfigurationsreparatur beginnt mit einem schreibgeschützten Einrichtungsplan; zeige Pfade, Backups und den Fähigkeitsersatz, bevor autorisierte Änderungen angewendet werden. Bewahre vorhandene Genehmigungs- und Zielausführungsgrenzen. REA-Setup installiert oder aktualisiert niemals nicht verwandte Software, einschließlich Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk oder Unblob.

Ziel zuerst routen

Wähle das erste Werkzeug aus dem Ziel, das der Benutzer bereitgestellt hat. Verwende open_binary für aktive native oder Archiv-Workflows; ziellose Werkzeuge akzeptieren ihren eigenen expliziten Pfad oder Endpunkt und benötigen ihn nicht.

• ASAR oder extrahierter JavaScript/Electron-Baum: analyze_javascript_application.
• Archiv-/Paket-Mitgliedsinventar (ZIP/APK/IPA/MSIX/AppX oder DMG): open_binary mit dem bereitgestellten lokalen Pfad; verwende inspect_artifact, wenn sein Graph und seine Erkenntnisse bei der Beantwortung der Frage helfen.
• Android APK-Code, Klassen, Methoden oder eingehende Referenzen: inspect_android_package, dann fokussierte Android-Werkzeuge, wenn angekündigt. Das Archiv-Mitgliedsinventar verwendet weiterhin die Archivroute oben.
• Verwaltete PE/CLI-Assembly: inspect_managed_artifact.
• Firmware-Image: inspect_firmware_regions, wenn angekündigt. Verwende extract_firmware, wenn Extraktion angefordert wird, mit einem vom Aufrufer gewählten neuen absoluten Ausgabeverzeichnis. Diese Werkzeuge verwenden vom Aufrufer bereitgestellte Binwalk/Unblob unter Linux; siehe die Firmware-Anleitung.
• .NET NativeAOT PE/ELF: native Ghidra-Analyse. Nativer Code kann Pseudocode liefern; konsultiere den NativeAOT-Workflow in references/native-and-artifacts.md für optionale Metadatenwiederherstellung und seine unterstützte Host-/Layout-Grenze.
• Benutzereigene Browser-Seite bereits geöffnet: list_browser_targets.
• Browser-Aktion, 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-Werkzeuge.
• Fiddler Everywhere-Datenverkehr oder eine native .saz-Aufzeichnung: lies den Fiddler-Workflow. Untersuche gespeicherte SAZ mit inspect_web_network_capture und format: "saz"; verbinde den separaten MCP-Server von Everywhere für Live-Datenverkehr.
• Beibehaltene HAR/SAZ/native mitmproxy/aioquic qlog-Aufzeichnung: inspect_web_network_capture. Wähle ursprüngliche Datensatz-Ordnungszahlen, wenn nützlich; überprüfe Producer-Felder und Byte/Number Sidecars, ohne aufgezeichnete URLs abzurufen oder Live-Zuschreibung zu beanspruchen. Siehe historische Aufzeichnungen für das genaue Upstream- Profil und Ausschlüsse von Anmeldeinformationen. Qlog-Unterstützung beginnt mit aioquic 1.5.0 JSON 0.3; Stream-Abdeckung und Endpunkt-Verlustdeklarationen stellen keine Body wieder her oder stellen keinen Netzwerkverlust fest. Bevorzuge Detailsumme, dann Art qlog trace/stream Seiten; wähle eine Ablaufverfolgung, Stream-ID und Richtung für Beitrags-/Bereichsseiten. Fakten behalten den Umfang 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. Vor einem electron-main Inspector-Versuch überprüfe verpackte Sicherungen mit inspect_electron_fuses; 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. Abfrage/Seite die relevanten Datensätze; Registrierungen stellen keinen beobachteten Datenverkehr her.
• Aufgezeichnete Paketerfassungen: inspect_packet_capture mit ausgewählten TShark-Feldern, Anzeigefiltern und Decode-als-Regeln. Erfordert Linux, util-linux prlimit und REA_TSHARK_COMMAND; siehe Erfassungsanleitung. Paketgrenzen zählen Eingabepakete vor dem Filtern. Die Ausgabe standardmäßig 50 übereinstimmende Frames; verwende match_offset / match_limit für spätere Seiten oder explizit null Grenze für vollständige übereinstimmende Ausgabe. Bewahre den Quell-Digest über Seiten hinweg. Dies führt keine Live-Erfassung durch. Verwende für Adress-/DNS-/SNI-/Protokollzusammenfassungen inspect_pcap_capture mit MCP Detailsumme, dann beibehaltene Art pcap-Seiten. Erfordert Wireshark 4.x tshark und capinfos, mit Linux prlimit oder Windows-Jobobjekten; siehe Paketzusammenfassungen. Wähle eine genaue DNS-Frage für Adressseiten; Seitenerschöpfung beweist keine Netzwerkvollständigkeit. Dies liest Aufzeichnungen und erfasst keinen Datenverkehr.
• Decoder-Erkennung: inspect_signal_decoders durchsucht installierte Decoder-IDs oder ausgewählte Decoder-Hilfe, einschließlich Kanäle und Optionen. Abfrage und Seite die relevanten Details vor der Auswahl von Einstellungen; dies scannt keine Hardware.
• Aufgezeichnete Logik-/Signalspuren: decode_signal_recording mit explizitem Decoder, Kanal- und Protokolleinstellungen. Stelle auf Linux mit util-linux prlimit sigrok-cli 0.7.2 über REA_SIGROK_COMMAND bereit; siehe Aufzeichnungsanleitung. Die Ausgabe standardmäßig 50 wörtliche Zeilen; wähle Annotationsklassen und blättere mit line_offset / line_limit oder explizit null für alle verbleibenden Ausgaben. Fensterzählungen sind Anzeigezeilen, keine Annotationen oder Samples. Bewahre Quell-Digests über Seiten hinweg. Dies liest vorhandene Dateien; es erfasst keine Hardwaresignale.
• Explizites lokales WebAssembly-Artefakt: inspect_wasm_artifact. Stelle WABT 1.0.42 über REA_WABT_BIN_DIRECTORY bereit; behalte genaue Byte-/Tool-Identität und dekodiertes WAT bei. Wähle JavaScript-Kleber und Kandidatenpfade explizit aus und bewahre URL-/Pfad- Mehrdeutigkeit. Kein impliziter Abruf 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 gewählter raw oder hex-Kodierung. Bewahre Träger-/dekodierte Digests und behandele Selektoren, Argumentstrings und Veränderbarkeit als abgeleitete Kandidaten; dies führt keine Chain- Suche oder Zielausführung durch. Für die vollständige abgeleitete Schnittstelle ohne Hex oder doppeltes stdout, entdecke Unterstützung und wähle detail: "summary"; vollständige Evidenz bleibt unter ihrer ursprünglichen Identität erhalten. Verwende die zurückgegebene parent_evidence_id für genaue Funktion oder bytecode_hex/stdout/stderr-Seiten. Kandidatenabdeckung stellt keine Schnittstellenvollständigkeit her. Siehe die EVM-Bytecode-Anleitung.
• Eingebettete Go-Compiler-, Modul- oder Build-Einstellungsmetadaten: inspect_go_binary mit der expliziten lokalen Datei. Diese integrierte ziellose Inspektion erfordert keine Go-Installation oder Disassembler. Bewahre 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ärdatei-Anleitung.
• Eingebettete cargo-auditable Rust-Abhängigkeitsmetadaten: inspect_rust_binary mit der expliziten lokalen ELF-, PE- oder dünnen Mach-O-Datei. Diese integrierte ziellose Inspektion erfordert keine Rust-Installation oder Disassembler. Bewahre Paketreihenfolge, Abhängigkeitsindizes und den Abschnittsdateibereich. Ein fehlender .dep-v0-Abschnitt sind null Metadaten, kein Beweis, dass die Binärdatei keine Abhängigkeiten hat. Ein rustc-Commit-Hash ist eine Inferenz aus einem schreibgeschützten /rustc/<40-hex>/-Pfad. Siehe die Rust-Binärdatei-Anleitung. ...

CLI-Fallback mit REA

Wenn REA-Werkzeuge über MCP nicht verfügbar sind oder du eine einfache Analyse ohne Serverkonfiguration benötigst, verwende den CLI-Befehl:

npx -y [email protected] analyze-javascript-application /absoluter/pfad/zu/app --json

Dies funktioniert ohne MCP-Registrierung oder native Engine. Die CLI gibt einen Evidenzdatensatz direkt zurück. Lies die zurückgegebenen Evidenz, den Graphen, die Einschränkungen und Unbekannten mit der gleichen Sorgfalt wie ein MCP-Ergebnis.

Evidenzformat und Behandlung

REA-Werkzeuge geben einen Evidenzdatensatz zurück. Behandle jeden Evidenzdatensatz als vollständige Inline-Evidenz; speichere ihn nicht implizit in Dateien und beziehe dich beim Antworten darauf. Verwende die Felder parent_evidence_id und source_digest, um Ergebnisse zu verknüpfen. Melde Einschränkungen, Unbekannte und nächste Schritte für jede Analyse.

Wichtige Einschränkung: Erfülle keine Netzwerkaufzeichnungen ohne ausdrückliche Genehmigung des Benutzers. Stelle sicher, dass du keine Live-Datenverkehrserfassung durchführst, es sei denn, der Benutzer hat dies ausdrücklich autorisiert.

Umgang mit persönlichen Daten und Sicherheit

• Filtere niemals Anmeldeinformationen aus Netzwerkerfassungen heraus – REA entfernt vertrauliche Felder nicht automatisch. Du musst den Benutzer warnen und die Daten nur mit Erlaubnis teilen.
• Behandle alle vom Benutzer bereitgestellten Pfade als potenziell vertraulich.
• Verändere niemals die Konfiguration des Zielsystems ohne Erlaubnis.
• Verwende schreibgeschützte Operationen, wann immer möglich.

Beispiel-Workflows

1. JavaScript-Anwendung analysieren

1. Der Benutzer gibt einen Pfad zur Anwendung an.
2. Verwende analyze_javascript_application mit diesem Pfad.
3. Lies die zurückgegebenen Evidenz, den Graphen, die Einschränkungen und nächsten Schritte.

2. Netzwerkverkehr debuggen

1. Der Benutzer gibt eine HAR/SAZ/pcap-Datei an.
2. Verwende inspect_web_network_capture (nicht Live-Erfassung).
3. Zeige die Zusammenfassung mit Bytes, Hosts und erkannten Protokollen.
4. Wähle bestimmte Datensätze zur detaillierten Überprüfung aus.
5. Erinnere den Benutzer daran, dass dies eine historische Aufzeichnung ist; kein Live-Datenverkehr.

3. Binärdatei auf Sicherheitsmaßnahmen überprüfen

1. Der Benutzer gibt eine PE- oder ELF-Datei an.
2. Verwende open_binary für eine native ausführbare Datei.
3. Verwende inspect_managed_artifact für .NET-Assemblys.
4. Verwende inspect_binary_layout für ASLR/NX/PIE-Puffer usw.
5. Melde Ergebnisse.

4. Android APK analysieren

1. Der Benutzer gibt einen APK-Pfad an.
2. Verwende inspect_android_package.
3. Siehe Klassen und Methoden.
4. Verwende open_binary für das APK, um das Archivinventar zu erhalten.
5. Wähle bestimmte Artefakte für die detaillierte Android-Überprüfung aus.

Fehlerbehebung und erweiterte Nutzung

• Verbindungs-/Registrierungsprobleme: Siehe Verbindung und Wiederherstellung.
• Firmware-Analyse: Siehe die Firmware-Anleitung.
• Netzwerkpaketerfassung: Siehe die Aufzeichnungsanleitung und die Paketzusammenfassungen.
• Firmware-Analyse: Verwende extract_firmware mit einem neuen Ausgabeverzeichnis und vom Aufrufer bereitgestellten Binwalk/Unblob unter Linux.
• Go-Binärdateien: Siehe die Go-Binärdatei-Anleitung.
• Rust-Binärdateien: Siehe die Rust-Binärdatei-Anleitung.
• EVM-Bytecode: Siehe die EVM-Bytecode-Anleitung.
• SQLite-Datenbanken: Siehe die SQLite-Anleitung.
• WebAssembly-Artefakt: Siehe die WASM-Anleitung.

Hinweis: Für eine vollständige Liste der Werkzeuge, der CLI-Fallbacks und der detaillierten Konfigurationsanweisungen lies die offizielle REA-Dokumentation.

Relevante Referenzdokumente

• Verbindung und Wiederherstellung
• Laufzeitbeobachtung
• Direkte Binärdatei- und Artefaktanalyse
• Netzwerkaufzeichnungen
• Paketerfassungen
• Paketzusammenfassungen
• Signalspuren
• Go-Binärdatei-Inspektion
• Rust-Binärdatei-Inspektion
• EVM-Bytecode
• SQLite-Datenbanken
• WebAssembly-Artefakt
• Firmware-Analyse
• Aufgezeichnete Abstürze
• Offline-Binärdatei-Diagnose
• Signalspuren