Serveur MCP pour le rétro-ingénierie des exécutables Windows et des formats binaires. Combine le triage statique, la récupération de fonctions assistée par Ghidra, des outils pilotés par plugins, la gestion des artefacts, et une exécution isolée d'un runtime Windows en option.
Rikune est un serveur MCP pour le rétro-ingénierie d'exécutables Windows et de formats binaires connexes. Il combine la réception d'échantillons, le tri statique, la récupération de fonctions assistée par Ghidra, des outils spécialisés basés sur des plugins, la gestion des artefacts, et l'exécution facultative dans un environnement Windows isolé derrière une interface Model Context Protocol.
Le flux de travail actuel du serveur orienté IA est organisé autour d'une surface de passerelle minimale :
workflow.search pour classer les profils, les flux de travail et les capacités spécialisées correspondant au type de fichier et à l'objectif utilisateur.workflow.run action=request_upload pour le téléchargement de fichier hôte, ou laissez workflow.search orienter les clients hérités vers des outils de compatibilité de réception d'échantillons cachés.workflow.run action=start avec le sample_id renvoyé.workflow.run action=status et workflow.run action=promote pour surveiller et approfondir l'exécution en cours.artifact.read pour les artefacts persistants complets lorsque la sortie compacte du workflow ne suffit pas.sample.*, workflow.analyze.*, workflow.triage, tools.discover, et task.status restent enregistrés pour la compatibilité ou l'inspection de bas niveau, mais les nouveaux clients devraient préférer workflow.search, workflow.run, et artifact.read.
Lors de la connexion via la passerelle distante rikune-agent, les clients MCP voient des noms de transport stables :
workflow_search, workflow_run, artifact_read, rikune_tool_call, et les contrôles
rikune_connection_*. rikune_connection_refresh met à jour uniquement le cache interne des capacités en amont ;
il n'étend pas la liste des outils MCP. Utilisez rikune_tool_call uniquement après
que workflow_search a identifié un sous-outil d'analyseur interne spécifique qui n'est pas couvert par la
passerelle principale du workflow ou des artefacts.
workflow.search utilise le type d'échantillon, les résultats et les métadonnées de profil pour orienter vers des capacités spécialisées sans exposer tous les outils dès le départ.Docker statique est la valeur par défaut la plus sûre. Il n'exécute pas d'échantillons.
.\rikune.ps1 install -Profile static -DataRoot "D:\Docker\rikune"
./rikune.sh install --profile static --data-root "$HOME/.rikune"
Équivalent manuel :
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
Le mode hybride exécute l'analyseur dans Docker et délègue le travail Windows en direct à un Agent hôte Windows. L'Agent hôte peut démarrer Windows Sandbox à la demande ou contrôler une machine virtuelle Hyper-V configurée.
.\rikune.ps1 install -Profile hybrid -InstallRuntime
Depuis Linux/macOS avec un hôte d'exécution Windows distant :
./rikune.sh install --profile hybrid --windows-host <windows-host> --windows-user <windows-user>
La connexion d'un client MCP ne démarre pas Windows Sandbox ni n'exécute un échantillon. Le travail d'exécution en direct ne commence que lorsqu'un outil le demande explicitement, par exemple runtime.debug.session.start, runtime.debug.command, sandbox.execute, ou une étape d'exécution dynamique promue.
npm install
npm run build
npm test
node dist/index.js
Le package racine nécessite Node.js 22 ou plus récent. Certains sous-packages d'exécution peuvent fonctionner sur des versions plus anciennes de Node, mais le développement du dépôt et l'interface CLI racine publiée doivent utiliser Node 22+.
Commencez par workflow.search chaque fois que le flux de travail demandé, le type de fichier ou le backend n'est pas clair. Il classe les profils correspondants et renvoie des indications compactes de disponibilité/orientation sans activer les outils spécialisés cachés.
Pour les fichiers hôtes, appelez workflow.run action=request_upload, envoyez les octets bruts en POST vers l'URL de téléchargement renvoyée, puis lisez le sample_id dans la réponse HTTP. sample.request_upload et sample.ingest sont des aides de compatibilité plutôt que le chemin normal orienté IA.
Pour les déploiements d'analyseur distant ou rikune-agent, définissez API_PUBLIC_BASE_URL, RIKUNE_API_PUBLIC_BASE_URL, ou RIKUNE_ANALYZER_PUBLIC_URL sur la base de l'API HTTP accessible par le client, par exemple http://159.195.136.226:18080. Les sessions de téléchargement renvoient alors des upload_url / status_url publiques au lieu des URL localhost locales au conteneur. La passerelle distante normalise également les URL de téléchargement localhost provenant d'analyseurs plus anciens vers son point de terminaison d'analyseur configuré.
Si l'API HTTP est activée, POST /api/v1/samples est toujours disponible pour les intégrations non-MCP. Une réception réussie renvoie un sample_id ; l'analyse doit utiliser sample_id, pas un chemin local, après importation.
Appelez workflow.run action=start avec le sample_id. La première étape effectue un profil rapide et crée ou réutilise une exécution d'analyse. Le plan_id renvoyé correspond à l'exécution d'analyse persistée.
Utilisez workflow.run action=promote pour demander des étapes plus approfondies. Le pipeline modélise actuellement ces étapes :
fast_profileenrich_staticfunction_mapreconstructsemantic_reviewsdynamic_plandynamic_executesummarizeLes travaux de longue durée sont mis en file d'attente via le système de travaux. Interrogez l'état compact des étapes avec workflow.run action=status.
workflow.run action=status est la vue principale des exécutions en cours. Les charges utiles historiques des grandes étapes peuvent être tronquées avec un avertissement de premier niveau ; utilisez artifact.read pour les artefacts complets. task.status est une vue de compatibilité brute de file d'attente/processus et inclut les mesures de mémoire external_active_* pour les sous-processus de l'analyseur.
Surfaces de suivi utiles :
workflow.searchworkflow.runanalysis.context.getartifact.read, ainsi que les aides de compatibilité d'artefacts telles que artifact.list, artifact.diff, et artifact.downloadreport.summarize, report.generate, workflow.summarizeworkflow.semantic_name_reviewworkflow.function_explanation_reviewworkflow.module_reconstruction_reviewtool.help, tool.readiness, et tools.discover pour l'inspection de compatibilité/débogageLe chemin de code actuel est :
src/index.ts
-> loadConfig()
-> WorkspaceManager / DatabaseManager / PolicyGuard / CacheManager / StorageManager / JobQueue
-> optional RuntimeClient or Windows sandbox bootstrap
-> registerAllTools()
-> MCP stdio server
Les modules principaux du serveur se trouvent sous src/core/ :
| Zone | Fichier actuel |
|---|---|
| Wrapper serveur MCP | src/core/server.ts |
| Registre d'outils/prompts/ressources MCP | src/core/mcp-registry.ts |
| Exécution d'outils, validation, hooks | src/core/tool-executor.ts |
| Orchestration du registre | src/core/tool-registry.ts |
| Tranches de registre intégrées | src/core/tool-registry/*.ts |
| Façade du gestionnaire de plugins | src/core/plugins.ts |
| Découverte/chargement de plugins | src/core/plugin-orchestrator.ts |
| Exposition progressive des outils | src/core/tool-surface-manager.ts |
Certains fichiers racine tels que src/server.ts, src/tool-registry.ts, et src/plugins.ts restent des relais de compatibilité. Le nouveau code doit cibler src/core/*.
| Plan | Objectif | Code clé |
|---|---|---|
| Analyseur | Serveur MCP stdio, API HTTP, stockage, travaux, outils statiques, orchestration de plugins | src/index.ts, src/core/* |
| Nœud d'exécution | Exécuteur de tâches isolé dans un bac à sable ou une machine virtuelle | packages/runtime-node/* |
| Agent hôte Windows | Démarre/arrête Windows Sandbox ou l'exécution Hyper-V et expose les points de terminaison de contrôle de l'exécution | packages/windows-host-agent/* |
| Passerelle d'agent | Passerelle/proxy MCP pour la gestion des connexions analyseur/exécution | src/rikune-agent-gateway.ts |
Les modes d'exécution sont configurés via runtime.mode ou des variables d'environnement :
disabled : aucune délégation d'exécution.manual : connexion à un point de terminaison d'exécution fourni.remote-sandbox : délégation à un Agent hôte Windows.auto-sandbox : analyseur natif Windows lance Windows Sandbox localement.Les analyseurs Docker/WSL doivent utiliser remote-sandbox, pas auto-sandbox.
Rikune inclut actuellement 111 plugins intégrés sous src/plugins/<id>/. Les plugins peuvent enregistrer des outils, déclarer des dépendances, exposer un schéma de configuration, participer à des hooks de cycle de vie, fournir des métadonnées Docker et déclarer des outils Worker liés et limités via les métadonnées workerBackend.
La suite Worker de frontière conserve les outils de plan uniquement comme surfaces de tri et de transfert, puis ajoute des outils d'exécution explicites à côté d'eux. restringer.deobfuscation.run, jsimplifier.pipeline.run, jsir.cascade.normalize, gtirb.ir.generate, remill.lift.run, manifold.fact.extract, qbdi.trace.run, et culifter.gpu.artifact.inventory exposent des contrats Worker via workflow.search, plugin.list, tool.help, et tool.readiness ; tools.discover reste un portail de compatibilité de bas niveau. La découverte et la disponibilité restent passives : elles rapportent les métadonnées du backend et les conseils de configuration sans lancer REstringer, JSIMPLIFIER, JSIR/CASCADE, GTIRB, Remill, Manifold, QBDI, les pilotes GPU, Node/V8, les navigateurs ou l'instrumentation d'exécution.
La génération Docker lit les métadonnées systemDeps et de packaging Worker directement. Les images par défaut installent des wrappers statiques à faible risque tels que REstringer, JSIMPLIFIER, Manifold, WABT, et la validation LIEF ; les profils optionnels peuvent activer les routes statiques JSIR/CASCADE, JSVMP, GTIRB, radare2, et Triton ; les backends lourds/d'exécution/GPU/sensibles aux licences restent profilés, BYO, ou 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
Le chargement des plugins est contrôlé par PLUGINS :
PLUGINS=* # tous les plugins intégrés
PLUGINS=pe-analysis,yara # plugins sélectionnés
PLUGINS=-dynamic # tous sauf dynamique
Utilisez ces outils MCP à l'exécution :
workflow.searchworkflow.runplugin.listplugin.enableplugin.disabletools.discover et tool.readiness pour l'inspection de compatibilité/débogage de bas niveauLorsque api.enabled est vrai, le serveur de fichiers intégré expose :
| Point de terminaison | Objectif |
|---|---|
/dashboard et / | Interface tableau de bord |
/api/v1/health | Disponibilité |
/api/v1/ready | Préparation de la base de données, de la file d'attente, de l'exécution et des backends de plugins |
/api/v1/events | Événements SSE |
/api/v1/samples | Téléchargement direct d'échantillons |
/api/v1/samples/:id | Métadonnées de l'échantillon |
/api/v1/samples/:id/download | Téléchargement de l'échantillon original |
/api/v1/artifacts | Liste des artefacts |
/api/v1/artifacts/:id | Lecture/suppression d'artefact |
/api/v1/uploads/:token | POST/statut de session de téléchargement durable |
L'authentification par clé API, la limitation de débit, les en-têtes de sécurité et le CORS limité sont gérés par la couche HTTP.
Ligne de base minimale de développement :
Les outils optionnels sont spécifiques aux plugins. Exécutez system.health, system.setup.guide, tool.readiness, et plugin.list pour voir ce qui manque dans un environnement donné.
src/
index.ts point d'entrée principal du serveur
core/ serveur MCP, registre, exécuteur, orchestration de plugins
core/tool-registry/ tranches d'enregistrement d'outils/prompts/ressources intégrés
tools/ implémentations des outils principaux
workflows/ flux de travail d'analyse, tri, reconstruction, révision
analysis/ état d'exécution et exécuteur de tâches en arrière-plan
plugins/ 111 plugins intégrés
persistence/ persistance SQLite et espace de travail
sample/ finalisation des échantillons et inspection de l'espace de travail
storage/ artefacts, téléchargements, rétention
runtime-client/ client de délégation d'exécution côté analyseur
worker/ orchestration des travailleurs Ghidra et Python
packages/
plugin-sdk/ SDK public de plugins
shared/ types de contrat d'exécution et d'outils
runtime-node/ exécuteur d'exécution isolé
windows-host-agent/ Agent hôte Windows Sandbox / Hyper-V
workers/ scripts Python de travailleurs et règles YARA
docker/ modèles Dockerfile générés et fichiers de profil
docs/ documentation sur l'architecture, les plugins, l'exécution, le déploiement
tests/ tests unitaires, d'intégration et de bout en bout
npm install
npm run build
npm test
npm run typecheck
npm run validate
npm run docker:generate:all
Vérifications ciblées utiles :
npm run test:unit
npm run test:integration
npm run test:e2e
npm run build:runtime
Construction locale :
{
"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"]
}
}
}
Package publié :
npm install -g rikune
rikune
rikune docker-stdio
rikune agent
Par défaut, Rikune stocke les données persistantes sous la racine Rikune de l'utilisateur. Les programmes d'installation Docker mappent généralement cette racine vers un répertoire hôte tel que D:\Docker\rikune.
Sous-répertoires courants :
samples/artifacts/uploads/cache/logs/Les espaces de travail d'échantillons sont regroupés par SHA-256 pour éviter les collisions de chemins et préserver les originaux immuables.
Rikune est conçu pour l'analyse de malwares et de binaires non fiables, mais il ne constitue pas en soi une limite de sécurité magique.
PolicyGuard.Voir SECURITY.md et TROUBLESHOOTING.md.
MIT