last-emo-boy/rikuneServidor MCP para ingeniería inversa de ejecutables de Windows y formatos binarios. Combina triaje estático, recuperación de funciones asistida por Ghidra, herramientas basadas en plugins, gestión de artefactos y ejecución opcional en tiempo de ejecución de Windows aislado.
Rikune es un servidor MCP para ingeniería inversa de ejecutables de Windows y formatos binarios relacionados. Combina la ingesta de muestras, el triaje estático, la recuperación de funciones asistida por Ghidra, herramientas especializadas impulsadas por complementos, gestión de artefactos y ejecución opcional en tiempo de ejecución aislado de Windows detrás de una interfaz de Protocolo de Contexto de Modelo.
El flujo de trabajo actual del servidor orientado a IA se organiza alrededor de una superficie de puerta de enlace mínima:
workflow.search para clasificar perfiles, flujos de trabajo y capacidades especializadas que coinciden con el tipo de archivo y el objetivo del usuario.workflow.run action=request_upload para la carga de archivos del host, o dejar que workflow.search dirija a clientes heredados a herramientas de compatibilidad de ingesta de muestras ocultas.workflow.run action=start con el sample_id devuelto.workflow.run action=status y workflow.run action=promote para monitorear y profundizar en la ejecución por etapas.artifact.read para artefactos completos persistidos cuando la salida compacta del flujo de trabajo no es suficiente.sample.*, workflow.analyze.*, workflow.triage, tools.discover y task.status permanecen registrados para compatibilidad o inspección de bajo nivel, pero los nuevos clientes deberían preferir workflow.search, workflow.run y artifact.read.
Al conectarse a través de la puerta de enlace remota rikune-agent, los clientes MCP ven nombres de transporte estables:
workflow_search, workflow_run, artifact_read, rikune_tool_call y los controles
rikune_connection_*. rikune_connection_refresh actualiza solo la caché interna de capacidades ascendentes; no expande la lista de herramientas MCP. Use rikune_tool_call solo después de que
workflow_search identifique una subherramienta de analizador interna específica que no esté cubierta por las puertas de enlace principales de flujo de trabajo o artefactos.
workflow.search utiliza el tipo de muestra, hallazgos y metadatos de perfil para enrutar hacia capacidades especializadas sin exponer todas las herramientas por adelantado.Docker estático es el valor predeterminado más seguro. No ejecuta muestras.
.\rikune.ps1 install -Profile static -DataRoot "D:\Docker\rikune"
./rikune.sh install --profile static --data-root "$HOME/.rikune"
Equivalente manual:
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
El modo híbrido ejecuta el Analizador en Docker y delega el trabajo en vivo de Windows a un Agente Host de Windows. El Agente Host puede iniciar Windows Sandbox bajo demanda o controlar una VM Hyper-V configurada.
.\rikune.ps1 install -Profile hybrid -InstallRuntime
Desde Linux/macOS con un host de tiempo de ejecución de Windows remoto:
./rikune.sh install --profile hybrid --windows-host <windows-host> --windows-user <windows-user>
Conectar un cliente MCP no inicia Windows Sandbox ni ejecuta una muestra. El trabajo de tiempo de ejecución en vivo solo comienza cuando una herramienta lo solicita explícitamente, como runtime.debug.session.start, runtime.debug.command, sandbox.execute o una etapa de ejecución dinámica promovida.
npm install
npm run build
npm test
node dist/index.js
El paquete raíz requiere Node.js 22 o superior. Algunos subpaquetes de tiempo de ejecución pueden ejecutarse en versiones anteriores de Node, pero el desarrollo del repositorio y la CLI raíz publicada deben usar Node 22+.
Comience con workflow.search siempre que el flujo de trabajo, tipo de archivo o backend solicitado no esté claro. Clasifica perfiles coincidentes y devuelve indicaciones compactas de preparación/enrutamiento sin activar herramientas especializadas ocultas.
Para archivos del host, llame a workflow.run action=request_upload, publique los bytes sin procesar en la URL de carga devuelta, luego lea sample_id de la respuesta HTTP. sample.request_upload y sample.ingest son ayudantes de compatibilidad, no la ruta normal orientada a IA.
Para implementaciones de analizador remoto o rikune-agent, establezca API_PUBLIC_BASE_URL, RIKUNE_API_PUBLIC_BASE_URL o RIKUNE_ANALYZER_PUBLIC_URL en la base de la API HTTP accesible por el cliente, por ejemplo http://159.195.136.226:18080. Las sesiones de carga luego devuelven valores upload_url / status_url públicos en lugar de URLs localhost locales del contenedor. La puerta de enlace remota también normaliza las URLs de carga localhost de analizadores antiguos a su punto final de analizador configurado.
Si la API HTTP está habilitada, POST /api/v1/samples sigue disponible para integraciones que no sean MCP. La ingesta exitosa devuelve un sample_id; el análisis debe usar sample_id, no una ruta local, después de la importación.
Llame a workflow.run action=start con el sample_id. La primera etapa realiza un perfil rápido y crea o reutiliza una ejecución de análisis. El plan_id devuelto se asigna a la ejecución de análisis persistida.
Use workflow.run action=promote para solicitar etapas más profundas. El pipeline actualmente modela estas etapas:
fast_profileenrich_staticfunction_mapreconstructsemantic_reviewsdynamic_plandynamic_executesummarizeEl trabajo de larga duración se pone en cola a través del sistema de trabajos. Consulte el estado compacto de las etapas con workflow.run action=status.
workflow.run action=status es la vista principal de la ejecución por etapas. Las cargas útiles grandes de etapas históricas pueden podarse con una advertencia de nivel superior; use artifact.read para artefactos completos. task.status es una vista de compatibilidad de cola/proceso sin procesar e incluye telemetría de memoria external_active_* para subprocesos del analizador.
Superficies de seguimiento útiles: