last-emo-boy/rikuneServeur 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.