MCP-Server für Reverse Engineering von Windows-Executables und Binärformaten. Kombiniert statische Triage, Ghidra-gestützte Funktionsanalyse, plugin-gesteuerte Werkzeuge, Artefaktverwaltung und optionale isolierte Windows-Laufzeitausführung.
Rikune ist ein MCP-Server für das Reverse Engineering von Windows-Ausführungsdateien und verwandten Binärformaten. Er kombiniert Sample-Aufnahme, statische Triage, Ghidra-gestützte Funktionswiederherstellung, plugin-gesteuerte Spezialwerkzeuge, Artefaktverwaltung und optionale isolierte Windows-Laufzeitausführung hinter einer Model Context Protocol-Schnittstelle.
Der aktuelle KI-orientierte Server-Workflow ist um eine minimale Gateway-Oberfläche organisiert:
workflow.search, um passende Profile, Workflows und spezialisierte Fähigkeiten für den Dateityp und das Benutzerziel zu bewerten.workflow.run action=request_upload für das Hochladen von Host-Dateien, oder lasse workflow.search Legacy-Clients auf versteckte Sample-Aufnahme-Kompatibilitätswerkzeuge verweisen.workflow.run action=start mit der zurückgegebenen sample_id.workflow.run action=status und workflow.run action=promote, um den gestuften Durchlauf zu überwachen und zu vertiefen.artifact.read für vollständige persistierte Artefakte, wenn die kompakte Workflow-Ausgabe nicht ausreicht.sample.*, workflow.analyze.*, workflow.triage, tools.discover und task.status bleiben für Kompatibilität oder Low-Level-Inspektion registriert, aber neue Clients sollten workflow.search, workflow.run und artifact.read bevorzugen.
Bei Verbindung über das Remote-rikune-agent-Gateway sehen MCP-Clients stabile Transportnamen:
workflow_search, workflow_run, artifact_read, rikune_tool_call und die
rikune_connection_*-Steuerungen. rikune_connection_refresh aktualisiert nur den internen Upstream-Fähigkeits-Cache; es erweitert nicht die MCP-Werkzeugliste. Verwende rikune_tool_call nur, nachdem workflow_search ein bestimmtes internes Analysator-Subwerkzeug identifiziert hat, das nicht durch die primären Workflow- oder Artefakt-Gateways abgedeckt wird.
stdio-Server für KI-Clients und Agenten-Laufzeiten.workflow.search verwendet Sample-Typ, Ergebnisse und Profilmetadaten, um zu spezialisierten Fähigkeiten weiterzuleiten, ohne alle Werkzeuge vorab zu exponieren.Statisches Docker ist die sicherste Standardeinstellung. Es führt keine Samples aus.
.\rikune.ps1 install -Profile static -DataRoot "D:\Docker\rikune"
./rikune.sh install --profile static --data-root "$HOME/.rikune"
Manuelles Äquivalent:
npm install
npm run build
npm run docker:generate:all
docker compose --env-file .docker-runtime.env -f docker-compose.analyzer.yml up -d --build analyzer
Der Hybrid-Modus führt den Analyzer in Docker aus und delegiert Live-Windows-Arbeiten an einen Windows Host Agent. Der Host Agent kann Windows Sandbox bei Bedarf starten oder eine konfigurierte Hyper-V-VM steuern.
.\rikune.ps1 install -Profile hybrid -InstallRuntime
Von Linux/macOS mit einem entfernten Windows-Runtime-Host:
./rikune.sh install --profile hybrid --windows-host <windows-host> --windows-user <windows-user>
Das Verbinden eines MCP-Clients startet weder Windows Sandbox noch führt es ein Sample aus. Live-Runtime-Arbeiten beginnen nur, wenn ein Werkzeug dies explizit anfordert, z.B. runtime.debug.session.start, runtime.debug.command, sandbox.execute oder eine hochgestufte dynamische Ausführungsstufe.
npm install
npm run build
npm test
node dist/index.js
Das Root-Paket benötigt Node.js 22 oder neuer. Einige Runtime-Subpakete können auf älteren Node-Versionen laufen, aber die Repository-Entwicklung und die veröffentlichte Root-CLI sollten Node 22+ verwenden.
Beginne mit workflow.search, wann immer der angeforderte Workflow, Dateityp oder das Backend unklar ist. Es bewertet passende Profile und gibt kompakte Bereitschafts-/Routing-Hinweise zurück, ohne versteckte Spezialwerkzeuge zu aktivieren.
Für Host-Dateien rufe workflow.run action=request_upload auf, POSTe die rohen Bytes an die zurückgegebene Upload-URL und lies dann sample_id aus der HTTP-Antwort. sample.request_upload und sample.ingest sind Kompatibilitätshilfen und nicht der normale KI-orientierte Pfad.
Für Remote-Analyzer- oder rikune-agent-Bereitstellungen setze API_PUBLIC_BASE_URL, RIKUNE_API_PUBLIC_BASE_URL oder RIKUNE_ANALYZER_PUBLIC_URL auf die für den Client erreichbare HTTP-API-Basis, z.B. http://159.195.136.226:18080. Upload-Sitzungen geben dann öffentliche upload_url-/status_url-Werte anstelle von containerlokalen localhost-URLs zurück. Das Remote-Gateway normalisiert auch Localhost-Upload-URLs von älteren Analyzern auf seinen konfigurierten Analyzer-Endpunkt.
Wenn die HTTP-API aktiviert ist, ist POST /api/v1/samples weiterhin für Nicht-MCP-Integrationen verfügbar. Erfolgreiche Aufnahme gibt eine sample_id zurück; die Analyse sollte nach dem Import die sample_id und nicht einen lokalen Pfad verwenden.
Rufe workflow.run action=start mit der sample_id auf. Die erste Stufe führt ein schnelles Profil durch und erstellt oder verwendet eine Analyseausführung wieder. Die zurückgegebene plan_id ist der persistierten Analyseausführung zugeordnet.
Verwende workflow.run action=promote, um tiefere Stufen anzufordern. Die Pipeline modelliert derzeit diese Stufen:
fast_profileenrich_staticfunction_mapreconstructsemantic_reviewsdynamic_plandynamic_executesummarizeLanglaufende Arbeiten werden über das Job-System in die Warteschlange gestellt. Frage den kompakten Stufenstatus mit workflow.run action=status ab.
workflow.run action=status ist die primäre Ansicht für gestufte Ausführungen. Große Payloads historischer Stufen können mit einer Top-Level-Warnung gekürzt werden; verwende artifact.read für vollständige Artefakte. task.status ist eine rohe Queue/Prozess-Kompatibilitätsansicht und enthält external_active_*-Speichertelemetrie für Analyzer-Subprozesse.
Nützliche Folgemaßnahmen:
workflow.searchworkflow.runanalysis.context.getartifact.read, sowie Kompatibilitäts-Artefakt-Hilfen wie artifact.list, artifact.diff und artifact.downloadreport.summarize, report.generate, workflow.summarizeworkflow.semantic_name_reviewworkflow.function_explanation_reviewworkflow.module_reconstruction_reviewtool.help, tool.readiness und tools.discover für Kompatibilitäts-/Debug-InspektionDer aktuelle Codepfad ist:
src/index.ts
-> loadConfig()
-> WorkspaceManager / DatabaseManager / PolicyGuard / CacheManager / StorageManager / JobQueue
-> optional RuntimeClient oder Windows-Sandbox-Bootstrap
-> registerAllTools()
-> MCP stdio server
Core-Server-Module befinden sich unter src/core/:
| Bereich | Aktuelle Datei |
|---|---|
| MCP-Server-Wrapper | src/core/server.ts |
| MCP-Werkzeug-/Prompt-/Ressourcen-Registry | src/core/mcp-registry.ts |
| Werkzeugausführung, -validierung, -haken | src/core/tool-executor.ts |
| Registry-Orchestrierung | src/core/tool-registry.ts |
| Integrierte Registry-Ausschnitte | src/core/tool-registry/*.ts |
| Plugin-Manager-Fassade | src/core/plugins.ts |
| Plugin-Erkennung/-Laden | src/core/plugin-orchestrator.ts |
| Progressive Werkzeugexposition | src/core/tool-surface-manager.ts |
Einige Root-Level-Dateien wie src/server.ts, src/tool-registry.ts und src/plugins.ts bleiben Kompatibilitäts-Weiterleitungen. Neuer Code sollte auf src/core/* abzielen.
| Ebene | Zweck | Schlüsselcode |
|---|---|---|
| Analyzer | MCP-stdio-Server, HTTP-API, Speicher, Jobs, statische Werkzeuge, Plugin-Orchestrierung | src/index.ts, src/core/* |
| Runtime Node | Isolierter Aufgabenausführer innerhalb von Sandbox oder VM | packages/runtime-node/* |
| Windows Host Agent | Startet/stoppt Windows Sandbox oder Hyper-V Runtime und stellt Runtime-Steuerungsendpunkte bereit | packages/windows-host-agent/* |
| Agent Gateway | MCP-Gateway/Proxy für Analyzer/Runtime-Verbindungsverwaltung | src/rikune-agent-gateway.ts |
Runtime-Modi werden über runtime.mode oder Umgebungsvariablen konfiguriert:
disabled: keine Runtime-Delegation.manual: Verbindung zu einem bereitgestellten Runtime-Endpunkt.remote-sandbox: Delegiert an einen Windows Host Agent.auto-sandbox: Windows-nativer Analyzer startet Windows Sandbox lokal.Docker/WSL-Analyzer sollten remote-sandbox verwenden, nicht auto-sandbox.
Rikune enthält derzeit 111 integrierte Plugins unter src/plugins/<id>/. Plugins können Werkzeuge registrieren, Abhängigkeiten deklarieren, Konfigurationsschemata bereitstellen, an Lebenszyklus-Hooks teilnehmen, Docker-Metadaten bereitstellen und Worker-gestützte Werkzeuge über workerBackend-Metadaten deklarieren.
Die Worker-Suite der Grenzfläche behält Plan-nur-Werkzeuge als Triage- und Übergabeoberflächen bei und fügt explizite Ausführungswerkzeuge daneben hinzu. restringer.deobfuscation.run, jsimplifier.pipeline.run, jsir.cascade.normalize, gtirb.ir.generate, remill.lift.run, manifold.fact.extract, qbdi.trace.run und culifter.gpu.artifact.inventory setzen Worker-Verträge über workflow.search, plugin.list, tool.help und tool.readiness aus; tools.discover bleibt ein Low-Level-Kompatibilitätsportal. Erkennung und Bereitschaft bleiben passiv: sie melden Backend-Metadaten und Setup-Anleitungen, ohne REstringer, JSIMPLIFIER, JSIR/CASCADE, GTIRB, Remill, Manifold, QBDI, GPU-Treiber, Node/V8, Browser oder Runtime-Instrumentierung zu starten.
Die Docker-Generierung liest Plugin-systemDeps und Worker-Packaging-Metadaten direkt. Standard-Images installieren risikoarme statische Wrapper wie REstringer, JSIMPLIFIER, Manifold, WABT und LIEF-Validierung; optionale Profile können JSIR/CASCADE, JSVMP, GTIRB, radare2 und Triton-artige statische Routen aktivieren; schwere/Runtime/GPU/lizenzsensitive Backends bleiben profilgesteuert, BYO oder Sidecar.
node scripts/generate-docker.mjs --dry-run
node scripts/generate-docker.mjs --profile=full --backend-profile=optional
node scripts/generate-docker.mjs --all-profiles --dry-run
Das Laden von Plugins wird durch PLUGINS gesteuert:
PLUGINS=* # alle integrierten
PLUGINS=pe-analysis,yara # ausgewählte Plugins
PLUGINS=-dynamic # alle außer dynamische
Verwende diese MCP-Werkzeuge zur Laufzeit:
workflow.searchworkflow.runplugin.listplugin.enableplugin.disabletools.discover und tool.readiness für Low-Level-Kompatibilitäts-/Debug-InspektionSiehe docs/PLUGINS.md und packages/plugin-sdk/README.md.
Wenn api.enabled wahr ist, stellt der eingebettete Dateiserver Folgendes bereit:
| Endpunkt | Zweck |
|---|---|
/dashboard und / | Dashboard-Benutzeroberfläche |
/api/v1/health | Lebendigkeit |
/api/v1/ready | Bereitschaft über Datenbank, Warteschlange, Runtime und Plugin-Backends hinweg |
/api/v1/events | SSE-Ereignisse |
/api/v1/samples | Direkter Sample-Upload |
/api/v1/samples/:id | Sample-Metadaten |
/api/v1/samples/:id/download | Original-Sample-Download |
/api/v1/artifacts | Artefakt-Auflistung |
/api/v1/artifacts/:id | Artefakt lesen/löschen |
/api/v1/uploads/:token | Dauerhafte Upload-Sitzung POST/Status |
API-Key-Authentifizierung, Ratenbegrenzung, Sicherheitsheader und eingeschränktes CORS werden von der HTTP-Ebene behandelt.
Minimale Entwicklungsbasis:
Optionale Werkzeuge sind plugin-spezifisch. Führe system.health, system.setup.guide, tool.readiness und plugin.list aus, um zu sehen, was in einer bestimmten Umgebung fehlt.
src/
index.ts Haupt-Server-Einstieg
core/ MCP-Server, Registry, Ausführer, Plugin-Orchestrierung
core/tool-registry/ Integrierte Werkzeug-/Prompt-/Ressourcen-Registrierungsausschnitte
tools/ Kern-Werkzeugimplementierungen
workflows/ Gestufte Analyse, Triage, Rekonstruktion, Überprüfungs-Workflows
analysis/ Laufzustand und Hintergrund-Task-Runner
plugins/ 111 integrierte Plugins
persistence/ SQLite und Arbeitsbereich-Persistenz
sample/ Sample-Finalisierung und Arbeitsbereichsinspektion
storage/ Artefakte, Uploads, Aufbewahrung
runtime-client/ Analyzer-seitiger Runtime-Delegationsclient
worker/ Ghidra- und Python-Worker-Orchestrierung
packages/
plugin-sdk/ Öffentliches Plugin-SDK
shared/ Runtime- und Werkzeugvertragstypen
runtime-node/ Isolierter Runtime-Ausführer
windows-host-agent/ Windows Sandbox / Hyper-V Host Agent
workers/ Python-Worker-Scripts und YARA-Regeln
docker/ Generierte Dockerfile-Vorlagen und Profildateien
docs/ Architektur-, Plugin-, Runtime-, Bereitstellungsdokumente
tests/ Unit-, Integrations- und E2E-Tests
npm install
npm run build
npm test
npm run typecheck
npm run validate
npm run docker:generate:all
Nützliche gezielte Prüfungen:
npm run test:unit
npm run test:integration
npm run test:e2e
npm run build:runtime
Lokaler Build:
{
"mcpServers": {
"rikune": {
"command": "node",
"args": ["D:/Playground/windows-exe-decompiler-mcp-server/dist/index.js"],
"env": {
"API_ENABLED": "true",
"API_PORT": "18080",
"API_PUBLIC_BASE_URL": "http://127.0.0.1:18080",
"PLUGINS": "*"
}
}
}
}
Docker stdio:
{
"mcpServers": {
"rikune": {
"command": "docker",
"args": ["exec", "-i", "rikune-analyzer", "node", "dist/index.js"]
}
}
}
Veröffentlichtes Paket:
npm install -g rikune
rikune
rikune docker-stdio
rikune agent
Standardmäßig speichert Rikune persistente Daten unter dem Benutzer-Rikune-Root. Docker-Installer mappen diesen Root normalerweise auf ein Host-Verzeichnis wie D:\Docker\rikune.
Häufige Unterverzeichnisse:
samples/artifacts/uploads/cache/logs/Sample-Arbeitsbereiche werden nach SHA-256 aufgeteilt, um Pfadkollisionen zu vermeiden und unveränderliche Originale zu erhalten.
Rikune ist für Malware- und unvertraute Binäranalyse ausgelegt, aber es ist selbst keine magische Sicherheitsgrenze.
PolicyGuard geschützt.Siehe SECURITY.md und TROUBLESHOOTING.md.
MIT