Der KI-Assistent zerlegt dies in Tool-Aufrufe:```
r2_decompile("sample.exe", "main")
  → extract_iocs("sample.exe")
    → add_mitre_technique(technique_id="T1071.001", ...)
      → create_analysis_report(template_type="quick_triage")

### Kerninfrastruktur (37 Module)

Das Verzeichnis `reversecore_mcp/core/` enthält die gemeinsame Infrastruktur, auf der alle Werkzeuge aufbauen:

| Modul | Zweck |
|---|---|
| `config.py` | Pydantic-BaseSettings mit 34+ Umgebungsvariablen |
| `security.py` | Eingabebereinigung, Validierung von Befehlsargumenten |
| `validators.py` | Validierung von Datei- und Binärpfaden mit TOCTOU-Minderung, Symlink-Auflösung |
| `r2_pool.py` | Thread-sicherer Radare2-Verbindungspool mit konfigurierbarer Größe |
| `r2_helpers.py` | Strukturiertes Parsen der Radare2-Ausgabe |
| `metrics.py` | Ausführungszeiten pro Werkzeug, Aufrufzahlen, Fehlerraten, Cache-Statistiken |
| `memory.py` | Asynchroner, auf SQLite basierender KI-Speicher zur persistenten Ablage von Analyseergebnissen über Sitzungen hinweg |
| `mitre_mapper.py` | Engine zur Zuordnung von MITRE-ATT&CK-Techniken-IDs |
| `evidence.py` | System zur Klassifizierung von Beweisen: `OBSERVED`, `INFERRED`, `POSSIBLE` |
| `resilience.py` | Dekorator-Muster für Wiederholungen, Circuit-Breaker und Timeouts |
| `task_queue.py` | Hintergrund-Warteschlange über Redis + arq |
| `extension_registry.py` | Plugin-Registrierung und Lebenszyklusverwaltung |
| `arch_registry.py` | Multi-Architektur-Zuordnung (x86, x86_64, ARM32, ARM64, MIPS, RISC-V, PPC → r2 arch/bits/registers) |
| `result_cache.py` | Auf SHA256 basierender Cache-Dekorator für Werkzeugergebnisse (`@cache_tool_result`) |
| `analysis_cache.py` | Mehrstufiger Dekompilierungs-Cache (L1: Redis, L2: SQLite) |
| `result.py` | Pydantic-Modelle `ToolSuccess` / `ToolError` |
| `exceptions.py` | 17 Ausnahmeklassen mit `RCMCP-E*`-Fehlercodes |
| `decorators.py` | `@log_execution`, `@track_metrics` |
| `error_handling.py` | Dekorator `@handle_tool_errors` |
| `error_formatting.py` | Strukturierte Formatierung von Fehlerantworten |
| `execution.py` | Sichere Subprozess-Ausführung mit Timeout und Ausgabelimits |
| `command_spec.py` | Befehlsspezifikation für Subprozessaufrufe |
| `loader.py` | Dynamischer Lader für Werkzeugmodule |
| `plugin.py` | Basisklasse für Plugins |
| `extension.py` | Basisklasse für Erweiterungen |
| `container.py` | Unterstützung für Container-/Sandbox-Ausführung |
| `audit.py` | Audit-Protokollierung |
| `binary_cache.py` | Zwischenspeicherung von Binärdateien |
| `json_utils.py` | JSON-Serialisierung über orjson (3-5x schneller als stdlib-json) |
| `logging_config.py` | Strukturierte Protokollierung auf Loguru-Basis |
| `report_generator.py` | Render-Engine für Berichte (Markdown, PDF über xhtml2pdf) |
| `resource_manager.py` | Lebenszyklusverwaltung für MCP-Ressourcen |
| `sast/python_ast_scanner.py` | Auf Python-AST basierender Schwachstellenscanner |
| `sast/regex_scanner.py` | Auf Regex basierender Schwachstellenscanner für C/C++ |
| `sast/rule_manager.py` | Laden und Verwaltung von SAST-Regeln |

---

## Werkzeugkatalog (120 Werkzeuge)

Jedes Werkzeug gibt ein strukturiertes `ToolResult` zurück — entweder ein `ToolSuccess` mit typisiertem `data`-Feld oder ein `ToolError` mit einem `RCMCP-E*`-Fehlercode. Die Werkzeuge sind in 8 Plugins organisiert.

---

### 🔍 Plugin für statische Analyse (24 Werkzeuge)

| # | Tool | Backend | Beschreibung |
|---|---|---|---|
| 1 | `run_strings` | `strings` CLI | Extraktion von ASCII/Unicode-Zeichenketten mit konfigurierbarer Mindestlänge |
| 2 | `run_binwalk` | Binwalk | Tiefenscan von Firmware auf eingebettete Signaturen und Dateisysteme |
| 3 | `run_binwalk_extract` | Binwalk | Extrahiert von binwalk entdeckte eingebettete Dateien |
| 4 | `parse_binary_with_lief` | LIEF | Vollständiges Parsen von PE-/ELF-/Mach-O-Headern, Sektionen, Imports/Exports, TLS |
| 5 | `detect_packer` | DIE | Schnelle Packer-/Compiler-Erkennung |
| 6 | `detect_packer_deep` | DIE (`diec`) | Tiefenanalyse von Packern/Protectoren über Detect It Easy |
| 7 | `run_capa` | CAPA (Mandiant FLARE) | Fähigkeitserkennung — "verschlüsselt Daten", "erzeugt Persistenz" usw. |
| 8 | `run_capa_quick` | CAPA | Schneller Fähigkeitenscan mit einer Teilmenge von Regeln |
| 9 | `generate_signature` | Radare2 | Erzeugt Binärsignaturen zur Identifizierung |
| 10 | `generate_yara_rule` | Radare2 + YARA | Erzeugt YARA-Erkennungsregeln aus Binärmustern |
| 11 | `generate_advanced_yara_rule` | Radare2 + YARA | Fortgeschrittene YARA-Regeln mit Verhaltensindikatoren |
| 12 | `scan_for_versions` | LIEF + strings | Durchsucht Binärdateien nach eingebetteten Versionszeichenketten |
| 13 | `extract_rtti_info` | Radare2 | Extrahiert C++-RTTI (Run-Time Type Information) |
| 14 | `diff_binaries` | Radare2 | Semantischer Binärdiff zwischen zwei Dateiversionen |
| 15 | `analyze_variant_changes` | Radare2 | Analysiert Änderungen zwischen Binärvarianten |
| 16 | `match_libraries` | Radare2 | Identifiziert statisch verknüpfte Bibliotheken anhand von Funktions-Fingerprints |
| 17 | `patch_diff_1day` | Radare2 + Heuristiken | Automatisierte Patch-Diff-Analyse für die 1-Day-Schwachstellenforschung |
| 18 | `analyze_patch_diff_auto` | Radare2 + Inferenz | Automatisierte Ableitung von Patch-Schwachstellen |
| 19 | `emulate_binary` | Radare2 ESIL | Code-Emulation mit Register-/Speicher-Tracing |
| 20 | `generate_fuzzing_harness` | Qiling + AFL++ | Erzeugt ein Fuzzing-Harness, das auf eine bestimmte Funktion abzielt |
| 21 | `run_fuzzing_campaign` | AFL++ | Führt eine vollständige Fuzzing-Kampagne mit Crash-Sammlung durch |
| 22 | `triage_crash` | GDB | Crash-Analyse und Bewertung der Ausnutzbarkeit |
| 23 | `verify_path_and_get_args` | angr | Symbolische Ausführung — Pfaderreichbarkeit beweisen und konkrete Eingaben berechnen |
| 24 | `taint_trace` | Radare2 + angr | Taint-Analyse des Datenflusses von Quellen zu Senken |

---

### 🔐 Quellcode-Audit-Plugin (1 Werkzeug)

| # | Tool | Backend | Beschreibung |
|---|---|---|---|
| 25 | `audit_source_code` | AST + Regex | Python-AST-Scan + C/C++-Regex-Scan auf gefährliche Muster |

---

### 🛠️ Plugin für allgemeine Hilfsfunktionen (20 Werkzeuge)

**Dateioperationen (5 Werkzeuge)**

| # | Tool | Beschreibung |
|---|---|---|
| 26 | `run_file` | Dateityp-, Architektur- und Compiler-Fingerprinting |
| 27 | `copy_to_workspace` | Kopiert eine Datei in den Analyse-Arbeitsbereich |
| 28 | `create_directory` | Erstellt ein Verzeichnis im Arbeitsbereich |
| 29 | `list_workspace` | Listet alle Dateien im Arbeitsbereich auf |
| 30 | `scan_workspace` | Vollständiger Scan des Arbeitsbereichs mit Dateimetadaten |

**Patch-Erklärung (1 Werkzeug)**

| # | Tool | Beschreibung |
|---|---|---|
| 31 | `explain_patch` | Erklärt einen Binär-Patch in natürlicher Sprache |

**Assembler (1 Werkzeug)**

| # | Tool | Backend | Beschreibung |
|---|---|---|---|
| 32 | `assemble_instructions` | Keystone | Assembliert Befehle zu Maschinencode (x86, ARM, MIPS usw.) |

**KI-Speicherverwaltung (11 Werkzeuge)**

Diese Werkzeuge ermöglichen der KI, Erkenntnisse über Analysesitzungen hinweg mithilfe einer asynchronen SQLite-Datenbank dauerhaft zu speichern und abzurufen:

| # | Tool | Beschreibung |
|---|---|---|
| 33 | `create_memory_session` | Startet eine neue Speichersitzung für eine Analyse |
| 34 | `store_analysis_finding` | Speichert ein Analyseergebnis dauerhaft mit Tags |
| 35 | `query_analysis_memories` | Durchsucht frühere Erkenntnisse per Abfrage |
| 36 | `get_binary_analysis_context` | Ruft den gesamten Kontext für eine bestimmte Binärdatei ab |
| 37 | `tag_analysis_session` | Fügt einer Sitzung Tags zur Organisation hinzu |
| 38 | `search_memories_by_tag` | Findet Sitzungen/Erkenntnisse nach Tag |
| 39 | `delete_analysis_session` | Entfernt eine Sitzung und deren Erkenntnisse |
| 40 | `cleanup_expired_sessions` | Entfernt Sitzungen, die älter als ein Schwellwert sind |
| 41 | `list_analysis_sessions` | Listet alle aktiven Sitzungen auf |
| 42 | `export_memory_store` | Exportiert alle Erkenntnisse in ein portables Format |
| 43 | `import_memory_store` | Importiert Erkenntnisse aus einer Exportdatei |

**Serverüberwachung (2 Werkzeuge)**

| # | Tool | Beschreibung |
|---|---|---|
| 44 | `get_server_health` | Uptime, Speichernutzung, geladene Werkzeuge, Python-Version |
| 45 | `get_tool_metrics` | Aufrufzahlen pro Werkzeug, mittlere Ausführungszeiten, Fehlerraten, Cache-Treffer/-Fehlschläge |

---

### ⚙️ Radare2- & r2ghidra-Plugin (30 Werkzeuge)

Alle Radare2-Werkzeuge verwenden einen thread-sicheren Verbindungspool (`r2_pool.py`), der r2pipe-Sitzungen automatisch verwaltet.

| # | Tool | Beschreibung |
|---|---|---|
| 46 | `Radare2_open_file` | Öffnet eine Binärdatei in Radare2 |
| 47 | `Radare2_close_file` | Schließt eine Radare2-Sitzung |
| 48 | `Radare2_list_open_files` | Listet aktuell geöffnete Dateien auf |
| 49 | `Radare2_analyze_binary` | Führt eine vollständige Auto-Analyse durch (`aaa`) |
| 50 | `Radare2_list_functions` | Listet alle erkannten Funktionen auf |
| 51 | `Radare2_disassemble_function` | Disassembliert eine bestimmte Funktion |
| 52 | `Radare2_disassemble_address` | Disassembliert an einer bestimmten Adresse |
| 53 | `Radare2_decompile_function` | Dekompiliert über r2ghidra (in r2 eingebettete Ghidra-Engine, kein JVM erforderlich) |
| 54 | `Radare2_list_exports` | Listet exportierte Symbole auf |
| 55 | `Radare2_list_imports` | Listet importierte Funktionen auf |
| 56 | `Radare2_list_sections` | Listet Binärsektionen mit Entropie auf |
| 57 | `Radare2_list_strings` | Listet in der Binärdatei gefundene Zeichenketten auf |
| 58 | `Radare2_find_cross_references` | Verfolgt Funktionsaufrufe und Datenreferenzen |
| 59 | `Radare2_search_bytes` | Sucht nach Byte-Mustern in der Binärdatei |
| 60 | `Radare2_get_binary_info` | Ruft Binärmetadaten ab (Architektur, Format, Byte-Reihenfolge) |
| 61 | `Radare2_execute_command` | Führt einen rohen Radare2-Befehl aus |
| 62 | `Radare2_esil_emulate` | ESIL-Emulation an einer bestimmten Adresse |
| 63 | `Radare2_get_hexdump` | Hex-Dump an einer virtuellen Adresse |
| 64 | `Radare2_get_cfg_data` | Extrahiert Daten des Kontrollflussgraphen |
| 65 | `Radare2_generate_cfg_png` | Erzeugt den Kontrollflussgraphen als PNG-Bild |
| 66 | `Radare2_generate_callgraph` | Erzeugt einen Funktionsaufruf-Graphen |
| 67 | `Radare2_recover_structures` | Stellt C-Strukturen automatisch wieder her und speichert sie in der Annotationsdatenbank |
| 68 | `Radare2_decompile_with_r2ghidra` | Hochwertige C-Dekompilierung mit Zwischenspeicherung |
| 69 | `Radare2_annotate_binary` | Fügt der Binärdatei Annotationen hinzu |
| 70 | `Radare2_get_annotations` | Ruft Annotationen ab |
| 71 | `Radare2_export_annotations` | Exportiert Annotationen in eine Datei |
| 72 | `Radare2_import_annotations` | Importiert Annotationen aus einer Datei |
| 73 | `Radare2_detect_crypto_constants` | Erkennt kryptografische Konstanten (AES-S-Box usw.) |
| 74 | `Radare2_find_gadgets` | Findet ROP-/JOP-Gadgets |
| 75 | `Radare2_calculate_entropy` | Berechnet die Entropie pro Sektion |

---

### 🦠 Malware-Analyse-Plugin (9 Werkzeuge)

| # | Tool | Backend | Beschreibung |
|---|---|---|---|
| 76 | `dormant_detector` | Radare2 + Heuristiken | Findet versteckte Hintertüren, verwaiste Funktionen, Zeitbomben, Logikbomben |
| 77 | `adaptive_vaccine` | YARA + Radare2 | Erzeugt YARA-Erkennungsregeln + Binär-Patches zur Neutralisierung von Bedrohungen |
| 78 | `vulnerability_hunter` | Radare2 + Analyse | Erkennt gefährliche API-Muster (strcpy, sprintf) und ROP-Gadget-Ketten |
| 79 | `extract_iocs` | Regex + LIEF | Extrahiert IPs, URLs, Domains, Hashes, Registrierungsschlüssel, Krypto-Adressen |
| 80 | `run_yara` | YARA | Scannt mit eigenen Regeldateien und integrierten Regelsätzen |
| 81 | `generate_poc_exploit` | pwntools | Erzeugt Proof-of-Concept-Exploit-Code |
| 82 | `build_rop_chain` | ROPgadget + pwntools | Automatisierte Konstruktion von ROP-Ketten |
| 83 | `autonomous_vuln_hunt` | Radare2 + angr | Autonome Pipeline zur Schwachstellensuche |
| 84 | `analyze_heap_exploit` | Radare2 + Heuristiken | Analyse der Heap-Ausnutzung (UAF, Double-Free, Overflow) |

---

### 🕵️ Plugin für digitale Forensik (22 Werkzeuge)

**Speicher-Forensik (6 Werkzeuge)**

| # | Tool | Backend | Beschreibung |
|---|---|---|---|
| 85 | `memory_analyze` | Volatility3 | Vollständige Speicher-Dump-Analyse |
| 86 | `memory_list_processes` | Volatility3 | Listet laufende Prozesse aus dem Speicher-Dump auf |
| 87 | `memory_detect_injections` | Volatility3 | Erkennt Code-Injektion im Prozessspeicher |
| 88 | `memory_extract_strings` | Volatility3 | Extrahiert Zeichenketten aus dem Prozessspeicher |
| 89 | `memory_dump_module` | Volatility3 | Erstellt einen Dump eines geladenen Moduls aus dem Speicher |
| 90 | `memory_list_symbols` | Volatility3 | Listet Symbole aus dem Speicher auf |

**Datenträger-Forensik (6 Werkzeuge)**

| # | Tool | Backend | Beschreibung |
|---|---|---|---|
| 91 | `disk_list_partition` | Sleuth Kit | Listet Datenträgerpartitionen auf |
| 92 | `disk_list_files` | Sleuth Kit | Listet Dateien in einem Datenträgerabbild auf |
| 93 | `disk_recover_deleted` | Sleuth Kit | Stellt gelöschte Dateien wieder her |
| 94 | `disk_analyze_mft` | Sleuth Kit | Analysiert die NTFS-Master File Table |
| 95 | `disk_extract_file` | Sleuth Kit | Extrahiert eine Datei aus einem Datenträgerabbild |
| 96 | `disk_hash_verify` | Sleuth Kit | Verifiziert die Dateiintegrität per Hash |

**Netzwerk-Forensik (5 Werkzeuge)**

| # | Tool | Backend | Beschreibung |
|---|---|---|---|
| 97 | `pcap_analyze` | Scapy | PCAP-Analyse: Protokollaufschlüsselung, Anomalien |
| 98 | `pcap_list_connections` | Scapy | Listet alle Netzwerkverbindungen auf |
| 99 | `pcap_extract_dns` | Scapy | Extrahiert DNS-Abfragen und -Antworten |
| 100 | `pcap_extract_c2` | Scapy | Identifiziert potenzielle C2-Kommunikation |
| 101 | `pcap_reconstruct_stream` | Scapy | Rekonstruiert TCP-Streams |

**Artefakt-Analyse (5 Werkzeuge)**

| # | Tool | Backend | Beschreibung |
|---|---|---|---|
| 102 | `artifact_collect` | Eigene Parser | Sammelt Browserverlauf, Registry-Hives, Ereignisprotokolle, Prefetch |
| 103 | `artifact_correlate_ioc` | Eigene Parser | Korreliert Artefakte mit bekannten IOCs |
| 104 | `artifact_generate_yara` | YARA | Erzeugt YARA-Regeln aus Artefaktmustern |
| 105 | `artifact_timeline` | Eigene Parser | Erstellt eine Zeitleiste aus mehreren Artefaktquellen |
| 106 | `artifact_report` | Eigene Parser | Erzeugt einen Artefakt-Analysebericht |

---

### 📝 Plugin zur Berichterstellung (14 Werkzeuge)

| # | Tool | Beschreibung |
|---|---|---|
| 107 | `get_system_time` | Ruft den Server-Zeitstempel ab (verhindert, dass die KI Datumsangaben erfindet) |
| 108 | `set_timezone` | Legt die Zeitzone für die Berichterstellung fest |
| 109 | `get_timezone_info` | Ruft Informationen zur aktuellen Zeitzone ab |
| 110 | `start_report_session` | Startet eine zeitgesteuerte Analysesitzung mit eindeutiger ID |
| 111 | `end_report_session` | Schließt die Sitzung ab: Dauer berechnen, IOC-/ATT&CK-Listen sperren |
| 112 | `get_report_session_status` | Prüft den Sitzungsstatus |
| 113 | `list_report_sessions` | Listet alle aktiven/abgeschlossenen Sitzungen auf |
| 114 | `add_ioc` | Sammelt und taggt IOCs während einer laufenden Sitzung |
| 115 | `add_analysis_note` | Fügt kategorisierte Notizen hinzu (Erkenntnis, Warnung, Verhalten) |
| 116 | `add_mitre_technique` | Dokumentiert MITRE-ATT&CK-Techniken-IDs |
| 117 | `set_severity` | Legt den Schweregrad der Sitzung fest (niedrig/mittel/hoch/kritisch) |
| 118 | `create_analysis_report` | Rendert den Bericht in 4 Modi: `full_analysis`, `quick_triage`, `ioc_summary`, `executive_brief` |
| 119 | `generate_vex_report` | Erzeugt einen VEX-Bericht (Vulnerability Exploitability eXchange) |
| 120 | `generate_sigma_rule` | Erzeugt SIGMA-Erkennungsregeln |

---

## Geführte Analyse-Prompts (22 Modi)

Prompts sind vorgefertigte Analyse-Workflows, die die KI mit einer strukturierten Persona, schrittweisen Werkzeugnutzungs-Sequenzen und Beweisklassifizierungsregeln vorbereiten. Sie aktivieren sie, indem Sie den Prompt-Namen in Ihrem KI-Client referenzieren.

### Malware-Analyse (9 Prompts)

| Prompt | Anwendungsfall |
|---|---|
| `full_analysis_mode` | Umfassende Analyse in 6 Phasen: Triage → Disassemblierung → Verhalten → Netzwerk → Persistenz → Bericht |
| `malware_analysis_mode` | Gezielte Malware-Analyse mit Bedrohungsklassifizierung |
| `basic_analysis_mode` | Schnelle Triage für erste Einschätzung und schnelle Bewertungen |
| `apt_hunting_mode` | APT-spezifische Suche: Lateral Movement, Persistenz, Datenexfiltration |
| `malware_defense_mode` | Verteidigungsorientiert: Erkennungsregeln und Gegenmaßnahmen erzeugen |
| `unpacking_mode` | Analysiert und umgeht Packen/Verschleierung (Themida, VMProtect, UPX) |
| `c2_extraction_mode` | Extrahiert und analysiert C2-Kommunikationsinfrastruktur |
| `ransomware_triage_mode` | Ransomware-spezifische Triage: Verschlüsselungsanalyse, Bewertung der Schlüsselwiederherstellung |
| `code_similarity_mode` | Vergleicht Binärdateien auf Code-Ähnlichkeit und gemeinsame Abstammung |

### Sicherheitsforschung (6 Prompts)

| Prompt | Anwendungsfall |
|---|---|
| `vulnerability_research_mode` | Bug-Jagd: Pufferüberläufe, UAF, Befehlsinjektion |
| `crypto_analysis_mode` | Analyse kryptografischer Implementierungen und Erkennung von Schwächen |
| `firmware_analysis_mode` | IoT-/eingebettete Firmware: binwalk-Extraktion, UART-Zeichenketten, hartcodierte Zugangsdaten |
| `patch_analysis_mode` | Analyse von Sicherheits-Patches und Regressionstests |
| `source_code_audit_mode` | Sicherheitsaudit des Quellcodes (Python, C, C++) |
| `autonomous_vuln_hunt_mode` | Autonome Pipeline zur Schwachstellensuche |

### CVE-Forschung & Exploit-Entwicklung (5 Prompts)

| Prompt | Anwendungsfall |
|---|---|
| `taint_analysis_mode` | Taint-Analyse des Datenflusses: automatische Entdeckung von Pfaden von der Quelle zur Senke |
| `heap_exploit_mode` | Analyse der Heap-Ausnutzung und PoC-Erzeugung |
| `fuzzing_mode` | Einrichtung von Fuzzing-Kampagnen und Crash-Triage |
| `patch_diff_auto_mode` | Automatisierter Patch-Diff für die 1-Day-Schwachstellenforschung |
| `cve_discovery_pipeline_mode` | Vollständige CVE-Entdeckungspipeline: vom Patch-Diff zum funktionierenden Exploit |

### Sonstiges (2 Prompts)

| Prompt | Anwendungsfall |
|---|---|
| `game_analysis_mode` | Analyse von Spiel-Clients: Anti-Cheat-Erkennung, Protokoll-RE, Speicherinspektion |
| `report_generation_mode` | Strukturierter Sitzungs-Workflow mit Zuordnung von MITRE-ATT&CK-Techniken |

> **So funktionieren Prompts:** Jeder Prompt bereitet die KI mit einer strukturierten Analyse-Persona vor. Er enthält Kontrollpunkte für das Chain-of-Thought-Denken (an denen die KI innehalten und bewerten muss, bevor sie fortfährt) und Beweisklassifizierungsregeln, die verhindern, dass die KI Spekulationen als Tatsachen darstellt. Jede Erkenntnis muss als `OBSERVED` (direkt verifiziert), `INFERRED` (logisch aus der statischen Analyse abgeleitet) oder `POSSIBLE` (erfordert weitere Verifizierung) gekennzeichnet werden.

---

## MCP-Ressourcen (11 URIs)

Ressourcen sind schreibgeschützte Datenendpunkte, auf die KI-Clients über URI-Vorlagen zugreifen können. Sie ergänzen die Werkzeuge, indem sie strukturierte Daten bereitstellen, ohne dass explizite Werkzeugaufrufe erforderlich sind.

### Statische Ressourcen

| URI | Beschreibung |
|---|---|
| `reversecore://guide` | Werkzeugnutzungs-Leitfaden mit Dateipfadregeln und Best Practices |
| `reversecore://guide/structures` | Technischer Leitfaden zur Strukturwiederherstellung und Querverweis-Analyse |
| `reversecore://tools` | Vollständige Dokumentation für alle 120 registrierten Werkzeuge |
| `reversecore://logs` | Anwendungsprotokolle (letzte 100 Zeilen) |

### Dynamische Ressourcen (Virtuelles Dateisystem pro Binärdatei)

Diese URIs werden pro Binärdatei aufgelöst und rufen die entsprechenden Analysewerkzeuge bei Bedarf auf:

| URI-Vorlage | Beschreibung |
|---|---|
| `reversecore://{filename}/strings` | Extrahiert alle Zeichenketten aus einer Binärdatei |
| `reversecore://{filename}/iocs` | Extrahiert IOCs (IPs, URLs, E-Mails, Hashes) |
| `reversecore://{filename}/func/{address}/code` | Dekompilierter Pseudo-C-Code für eine Funktion |
| `reversecore://{filename}/func/{address}/asm` | Disassemblierung für eine Funktion |
| `reversecore://{filename}/func/{address}/cfg` | Kontrollflussgraph im Mermaid-Format |
| `reversecore://{filename}/functions` | Liste aller Funktionen in der Binärdatei |
| `reversecore://{filename}/dormant_detector` | Ergebnisse der Dormant-Detector-Analyse |

---

## Schnellstart

### Option 1 — PyPI (Am einfachsten)```bash
pip install reversecore-mcp
reversecore-mcp

### Option 3 — Aus dem Quellcode erstellen (Docker Compose)```bash
git clone https://github.com/sjkim1127/Reversecore_MCP.git
cd Reversecore_MCP
./scripts/run-docker.sh        # auto-detects Intel / Apple Silicon

### Option 4 — Python (Lokale Entwicklung)```bash
git clone https://github.com/sjkim1127/Reversecore_MCP.git
cd Reversecore_MCP
python -m venv venv && source venv/bin/activate
pip install -r requirements.txt
python -m reversecore_mcp.server

> Ersetze `reversecore-mcp-arm64` durch `reversecore-mcp`, wenn du auf Intel/AMD bist.

---

### 🌐 Option 2: SSE-HTTP-Modus

Für netzwerkbasiertes Streaming (Server-Sent Events):```json
{
  "mcpServers": {
    "Reversecore_MCP": {
      "url": "http://localhost:8000/mcp/sse"
    }
  }
}

### Tests```bash
# Full test suite with coverage report
pytest tests/ -v

# Unit tests only (fast, no external dependencies)
pytest tests/unit/ -v

# Integration tests (requires Docker)
pytest tests/integration/ -v

# Run with coverage threshold enforcement
pytest tests/unit/ --cov=reversecore_mcp --cov-fail-under=80

# Run a specific test
pytest tests/unit/test_cli_tools.py::TestRunFile::test_success -v

# Security boundary tests
pytest tests/ -m security -v

# Benchmarks
pytest tests/ -m benchmark -v

### Pre-commit-Hooks

Die folgenden Hooks werden bei jedem Commit automatisch ausgeführt:

1. **Ruff** — Linting mit automatischer Korrektur + Formatprüfung
2. **trailing-whitespace** — entfernt Leerzeichen am Zeilenende
3. **end-of-file-fixer** — stellt sicher, dass Dateien mit einer neuen Zeile enden
4. **check-yaml / check-json** — validiert YAML/JSON-Syntax
5. **check-added-large-files** — blockt Dateien > 1 MB
6. **check-merge-conflict** — erkennt ungelöste Merge-Marker
7. **detect-private-key** — verhindert versehentliche Key-Commits
8. **Bandit** — Python-Sicherheitsscan

---

## CI/CD-Pipeline

Jeder Push zu `main` löst 11 Pipeline-Jobs aus. Alle müssen vor der Bereitstellung erfolgreich sein.```
 Lint & Security Gate              Unit Tests (Python Matrix)
   ├─ Gitleaks (secret scan)         ├─ pytest 3.10 --cov-fail-under=80
   ├─ Hadolint (Dockerfile lint)     ├─ pytest 3.11 --cov-fail-under=80
   ├─ Ruff check + format            └─ pytest 3.12 --cov-fail-under=80
   ├─ Mypy type check (108 files)
   ├─ Bandit (all severities)      Wheel Smoke Test
   ├─ pip-audit (no CVEs)            └─ Build wheel → install in /tmp
   └─ Security boundary tests            → verify plugin discovery
                                          → assert __file__ under sys.prefix
 CodeQL Analysis
   └─ Python SAST                  Docker Verification
                                     ├─ Build reversecore-mcp:ci
 Exploit Safety Gate                 ├─ Trivy container scan
   ├─ Bandit on POC templates        ├─ Image size check (< 5 GB)
   ├─ Hypothesis DAST fuzzing        ├─ CLI tool verification
   ├─ Performance benchmarks         ├─ Integration tests in container
   └─ Container isolation test       └─ E2E tool invocation

 In-Container Smoke Test           Build Base Image (amd64 + arm64)
   ├─ Copy test ELF into container   ├─ Compile YARA 4.3.1
   └─ Run scripts/smoke_test.py     ├─ Compile Radare2 6.0.4
                                     ├─ Compile r2ghidra
 Deploy (amd64 + arm64)             └─ Push to GHCR
   ├─ Build app image
   ├─ Push to GHCR                 Merge Manifests
   └─ Trivy rescan on published     └─ Multi-arch manifest → :latest

Dieses Image wird nur neu erstellt, wenn sich die Tool-Versionen ändern. Build-Zeit: ~12 Minuten.

### Layer 2: Anwendungs-Image (`Dockerfile`)

Erbt vom Basis-Image und kopiert den Anwendungscode:```
FROM base image
    ├── COPY reversecore_mcp/ (application code)
    ├── COPY scripts/ (smoke test, benchmarks)
    ├── pip install any new requirements
    ├── Security package upgrades
    └── CMD ["python", "-m", "reversecore_mcp.server"]

**Andere Verzeichnisse:**```
tests/
├── unit/                          # 1,957 unit tests
├── integration/                   # Docker-based integration tests
├── fixtures/                      # Test binaries, YARA rules, sample data
└── conftest.py                    # Shared pytest fixtures

scripts/
├── smoke_test.py                  # Multi-layer in-container smoke test
├── check_release_metadata.py      # Version consistency validation
├── fetch_test_binaries.py         # Download test fixtures
├── run-docker.sh                  # Auto-detect architecture and start
└── ...                            # Benchmarks, analysis scripts

docs/
├── getting-started/               # Installation guide
├── development/                   # Architecture, contributing, testing guides
├── api/                           # Tool and module reference
└── user-guide/                    # Analysis workflows

Args:
    file_path: Path to the binary file (relative to workspace).
    option: Optional analysis option.

Returns:
    ToolResult with status='success' and structured content.
"""
try:
    safe_path = validate_file_path(file_path)
    result = await perform_analysis(safe_path)
    return success({"result": result})
except Exception as e:
    return failure(
        error_code="RCMCP-E100",
        message=str(e),
        hint="Check that the file exists and is a valid binary.",
    )

Registriere es dann in der `__init__.py` des entsprechenden Plugins und füge Tests in `tests/unit/` hinzu.

---

## Mitwirken

1. Forke das Repository
2. Erstelle einen Feature-Branch: `git checkout -b feat/my-feature`
3. Schreibe Tests zusammen mit deinem Code — die Abdeckung darf nicht unter 80 % fallen
4. Stelle sicher, dass alle Prüfungen bestehen: `pytest`, `ruff check`, `mypy`, `bandit`
5. Eröffne einen Pull Request mit einer klaren Beschreibung

Bitte lies den [Mitwirkungsleitfaden](https://github.com/sjkim1127/reversecore_mcp/blob/main/docs/development/contributing.md) für Code-Standards, Docstring-Konventionen (Google-Stil) und die Pull-Request-Checkliste.

---

## Dokumentation

| Dokument | Beschreibung |
|---|---|
| [Installationsanleitung](https://github.com/sjkim1127/reversecore_mcp/blob/main/docs/getting-started/installation.md) | Detaillierte Einrichtung für alle Umgebungen |
| [Architekturhandbuch](https://github.com/sjkim1127/reversecore_mcp/blob/main/docs/development/architecture.md) | Systemdesign & Komponentendetails |
| [Mitwirkungsleitfaden](https://github.com/sjkim1127/reversecore_mcp/blob/main/docs/development/contributing.md) | Code-Standards, Docstrings, PR-Workflow |
| [Testleitfaden](https://github.com/sjkim1127/reversecore_mcp/blob/main/docs/development/testing.md) | Testmuster, Fixtures und Abdeckung |
| [API-Referenz](https://github.com/sjkim1127/reversecore_mcp/blob/main/docs/api) | Referenz für Tools und Module |
| [Benutzerhandbuch](https://github.com/sjkim1127/reversecore_mcp/blob/main/docs/user-guide) | Analyse-Workflows |

---

## Anwendungsbeispiele

### Beispiel 1: Einfache Malware-Triage```
User: "Analyze this suspicious file sample.exe"

AI calls:
  1. run_file("sample.exe")           → PE32 executable, x86, MSVC
  2. detect_packer("sample.exe")      → Not packed
  3. extract_iocs("sample.exe")       → 3 IPs, 2 URLs, 1 mutex
  4. run_capa("sample.exe")           → "creates persistence", "encrypts data"
  5. dormant_detector("sample.exe")   → 2 orphan functions with network calls
  6. generate_yara_rule("sample.exe") → Detection rule generated

AI response: "This PE32 binary shows ransomware-like behavior. CAPA detected
encryption and persistence capabilities. I found 2 hidden network functions
that may serve as a backup C2 channel. Here's a YARA rule for detection..."

### Beispiel 3: Digitalforensische Untersuchung```
User: "Analyze this memory dump from a compromised server"

AI calls:
  1. memory_list_processes("memdump.raw")
     → 47 processes, 2 with suspicious names

  2. memory_detect_injections("memdump.raw")
     → Code injection detected in PID 1842 (svchost.exe)

  3. memory_extract_strings("memdump.raw", pid=1842)
     → C2 domain strings extracted

  4. artifact_correlate_ioc(artifacts={"domains": ["evil-c2.com"]})
     → Matches known APT group IOCs

  5. create_analysis_report(template_type="full_analysis")
     → PDF report with timeline and MITRE ATT&CK mapping

---

## Unterstützung für mehrere Architekturen

Das Modul `arch_registry.py` ordnet Architekturnamen Radare2-Konfigurationsparametern zu und ermöglicht es Tools, ohne manuelle Konfiguration über verschiedene CPU-Architekturen hinweg zu arbeiten:

| Architektur | Schlüssel | r2 Arch | Bitbreiten | PC-Register | SP-Register |
|---|---|---|---|---|---|
| Intel 32-bit | `x86` | `x86` | 32 | `eip` | `esp` |
| Intel/AMD 64-bit | `x86_64` | `x86` | 64 | `rip` | `rsp` |
| ARM 32-bit / Thumb | `arm32` | `arm` | 16, 32 | `r15` | `r13` |
| ARM 64-bit (AArch64) | `arm64` | `arm` | 64 | `pc` | `sp` |
| MIPS | `mips` | `mips` | 32, 64 | `pc` | `sp` |
| RISC-V | `riscv` | `riscv` | 32, 64 | `pc` | `sp` |
| PowerPC | `ppc` | `ppc` | 32, 64 | `pc` | `r1` |

**Alias-Auflösung** erfolgt automatisch:
- `amd64` → `x86_64`
- `aarch64` → `arm64`
- `arm` mit `bits=64` → `arm64`
- `arm` mit `bits=16` oder `bits=32` → `arm32`

Tools wie `Radare2_esil_emulate`, `assemble_instructions` und `r2_simulate_patch` verwenden diese Registrierung, um die Analyseumgebung für jede Ziel-Binärdatei korrekt zu konfigurieren.

---

## Ergebnis-Cache-System

Zwei Cache-Ebenen minimieren redundante Berechnungen:

### Tool-Ergebniscache (`result_cache.py`)

Der `@cache_tool_result`-Dekorator speichert die Ausgabe jedes Tools basierend auf einem SHA256-Hash der Binärdatei und den Schlüsselwortargumenten des Tools im Cache:```
Cache key = SHA256( "<tool_name>::{sorted_json_kwargs}" )

**Speicher:** Asynchrone SQLite-Datenbank unter dem Pfad, der durch `MEMORY_DB_PATH` konfiguriert wird (Standard: `~/.reversecore_mcp/memory.db`).

**Portabilität:** Verwenden Sie `export_memory_store` und `import_memory_store`, um die gesamte Speicherdatenbank zwischen Umgebungen zu übertragen.

---

## Web-Dashboard

Bei Ausführung im HTTP-Modus (`MCP_TRANSPORT=http`) ist ein Web-Dashboard unter `http://localhost:8000/dashboard` verfügbar. Es bietet:

- Binärdatei-Upload per Drag-and-drop
- Echtzeit-Analysestatus
- Interaktive Funktionsliste und Disassembly-Ansicht
- Ergebnisse der IOC-Extraktion
- Server-Health-Überwachung

**Technologie-Stack:** FastAPI + Jinja2-Templates + HTMX (lokal aus `dashboard/static/` geladen, keine CDN-Abhängigkeit für CSP-Konformität).

**Sicherheitsfunktionen:**
- CSRF-Token bei allen zustandsändernden Formularen
- Jinja2-Auto-Escaping aktiviert
- Alle Benutzereingaben werden vor der Anzeige über `html.escape()` bereinigt
- Path-Traversal-Schutz über `validate_file_path()`

---

## Deployment

### Produktions-Checkliste

Vor der Bereitstellung in der Produktion:

| Punkt | Vorgehen |
|---|---|
| API-Schlüssel festlegen | `MCP_API_KEY=<strong-random-key>` |
| Nicht-Root-Benutzer verwenden | Integriert: Container läuft als `appuser` (UID 1000) |
| Ressourcenlimits festlegen | Standard: 2 CPU / 4 GB RAM in `docker-compose.yml` |
| Strukturierte Protokollierung aktivieren | `LOG_FORMAT=json` für Log-Aggregation |
| Redis konfigurieren | `REDIS_URL=redis://<host>:6379/0` für Task-Warteschlange und Caching |
| Arbeitsbereichspfad festlegen | `REVERSECORE_WORKSPACE=/path/to/isolated/directory` |
| Ratenlimits überprüfen | `REVERSECORE_RATE_LIMIT=60` (Anfragen/min, nach Bedarf anpassen) |
| Sandbox aktivieren | `REVERSECORE_SANDBOX_ENABLED=true` für die Isolierung der dynamischen Analyse |

### Health-Checks

Der Server stellt HTTP-Health-Check-Endpunkte für die Orchestrierung bereit:```bash
# Liveness (always 200 if process is running)
curl http://localhost:8000/health/live

# Readiness (checks tool availability)
curl http://localhost:8000/health/ready

# Full health (requires API key if configured)
curl -H "X-API-Key: <key>" http://localhost:8000/health