Rikune

Rikune è un server MCP per il reverse engineering di eseguibili Windows e formati binari correlati. Combina acquisizione di campioni, triage statico, recupero funzioni assistito da Ghidra, strumenti specialistici guidati da plugin, gestione degli artefatti ed esecuzione opzionale in ambiente Windows isolato tramite un'interfaccia Model Context Protocol.

Il flusso di lavoro attuale del server rivolto all'IA è organizzato attorno a una superficie gateway minima:

1. Usa workflow.search per confrontare profili, flussi di lavoro e capacità specialistiche corrispondenti al tipo di file e all'obiettivo dell'utente.
2. Usa workflow.run action=request_upload per il caricamento di file dall'host, oppure lascia che workflow.search indirizzi i client legacy verso strumenti di compatibilità per l'acquisizione di campioni nascosti.
3. Usa workflow.run action=start con il sample_id restituito.
4. Usa workflow.run action=status e workflow.run action=promote per monitorare e approfondire l'esecuzione a fasi.
5. Usa artifact.read per ottenere artefatti completi persistiti quando l'output compatto del flusso di lavoro non è sufficiente.

sample.*, workflow.analyze.*, workflow.triage, tools.discover e task.status rimangono registrati per compatibilità o ispezione di basso livello, ma i nuovi client dovrebbero preferire workflow.search, workflow.run e artifact.read.

Quando ci si connette tramite il gateway remoto rikune-agent, i client MCP vedono nomi di trasporto stabili: workflow_search, workflow_run, artifact_read, rikune_tool_call e i controlli rikune_connection_*. rikune_connection_refresh aggiorna solo la cache interna delle capacità upstream; non espande l'elenco degli strumenti MCP. Usa rikune_tool_call solo dopo che workflow_search identifica uno specifico sottostrumento di analisi interna non coperto dal flusso di lavoro primario o dai gateway degli artefatti.

Cosa offre Rikune

• Server MCP stdio per client AI e runtime di agenti.
• API HTTP opzionale e dashboard per caricamenti, download, controlli di integrità, eventi SSE e accesso agli artefatti.
• Workspace per campioni basati su SHA-256 con file originali durevoli, directory cache, artefatti di analisi e sessioni di caricamento.
• Persistenza basata su SQLite per campioni, analisi, job, prove, artefatti, batch, sessioni di debug e telemetria dello scheduler.
• Architettura a plugin con 111 plugin integrati e scoperta di plugin esterni.
• Superficie strumentale progressiva: il gateway predefinito rivolto all'IA è volutamente piccolo; workflow.search utilizza il tipo di campione, i risultati e i metadati del profilo per instradare verso capacità specialistiche senza esporre tutti gli strumenti in anticipo.
• Analisi statica e arricchimento per PE, ELF, Mach-O, APK/DEX, Office, firmware, UEFI/SMM, CUDA PTX/CUBIN/fatbin, stringhe, YARA, SBOM, firme, packer, .NET, Go, Rust e altro.
• Integrazione con Ghidra, Rizin, RetDec, angr, Capstone, Graphviz, Qiling, PANDA, Speakeasy, Wine, Frida e runtime dinamico dove disponibile.
• Installazione backend Docker basata su plugin con livelli predefinito, opzionale, ricerca, runtime, GPU, BYO e sidecar per strumenti di reverse engineering supportati da worker.
• Separazione opzionale Analyzer/Runtime per esecuzione live di Windows tramite Windows Host Agent, Windows Sandbox o VM Hyper-V.
• Gate di policy per esecuzione live, accesso alla rete, caricamento esterno e decompilazione bulk.

Avvio rapido

Analyzer Docker statico

Il Docker statico è l'impostazione predefinita più sicura. Non esegue campioni.

.\rikune.ps1 install -Profile static -DataRoot "D:\Docker\rikune"

./rikune.sh install --profile static --data-root "$HOME/.rikune"

Equivalente manuale:

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

Docker ibrido + Runtime Windows

La modalità ibrida esegue l'Analyzer in Docker e delega il lavoro live di Windows a un Windows Host Agent. L'Host Agent può avviare Windows Sandbox su richiesta o controllare una VM Hyper-V configurata.

.\rikune.ps1 install -Profile hybrid -InstallRuntime

Da Linux/macOS con un host runtime Windows remoto:

./rikune.sh install --profile hybrid --windows-host <windows-host> --windows-user <windows-user>

La connessione di un client MCP non avvia Windows Sandbox né esegue un campione. Il lavoro live del runtime inizia solo quando uno strumento lo richiede esplicitamente, ad esempio runtime.debug.session.start, runtime.debug.command, sandbox.execute o una fase di esecuzione dinamica promossa.

Sviluppo nativo

npm install
npm run build
npm test
node dist/index.js

Il pacchetto root richiede Node.js 22 o superiore. Alcuni sottopacchetti runtime possono funzionare su versioni Node precedenti, ma lo sviluppo del repository e la CLI root pubblicata dovrebbero usare Node 22+.

Flusso gateway primario

Ricerca e caricamento

Inizia con workflow.search ogni volta che il flusso di lavoro, il tipo di file o il backend richiesto non sono chiari. Confronta i profili corrispondenti e restituisce suggerimenti compatti di prontezza/instradamento senza attivare strumenti specialistici nascosti.

Per i file host, chiama workflow.run action=request_upload, invia i byte grezzi tramite POST all'URL di upload restituito, quindi leggi sample_id dalla risposta HTTP. sample.request_upload e sample.ingest sono helper di compatibilità, non il normale percorso rivolto all'IA.

Per deploy di analyzer remoti o rikune-agent, imposta API_PUBLIC_BASE_URL, RIKUNE_API_PUBLIC_BASE_URL o RIKUNE_ANALYZER_PUBLIC_URL sulla base URL HTTP raggiungibile dal client, ad esempio http://159.195.136.226:18080. Le sessioni di upload restituiranno quindi valori upload_url / status_url pubblici invece di URL localhost locali al container. Il gateway remoto normalizza anche gli URL di upload localhost provenienti da analyzer più vecchi al proprio endpoint analyzer configurato.

Se l'API HTTP è abilitata, POST /api/v1/samples è ancora disponibile per integrazioni non MCP. L'acquisizione riuscita restituisce un sample_id; l'analisi dovrebbe usare sample_id, non un percorso locale, dopo l'importazione.

Avvia analisi

Chiama workflow.run action=start con sample_id. La prima fase esegue un profilo veloce e crea o riutilizza un'esecuzione di analisi. Il plan_id restituito mappa all'esecuzione di analisi persistita.

Promuovi fasi

Usa workflow.run action=promote per richiedere fasi più approfondite. La pipeline attualmente modella queste fasi:

• fast_profile
• enrich_static
• function_map
• reconstruct
• semantic_reviews
• dynamic_plan
• dynamic_execute
• summarize

Il lavoro a lunga esecuzione viene accodato tramite il sistema di job. Controlla lo stato compatto delle fasi con workflow.run action=status.

workflow.run action=status è la vista principale dell'esecuzione a fasi. I payload delle fasi storiche di grandi dimensioni possono essere potati con un avviso principale; usa artifact.read per artefatti completi. task.status è una vista raw di coda/processo per compatibilità e include la telemetria di memoria external_active_* per i sottoprocessi dell'analyzer.

Rivedi risultati

Superfici di follow-up utili:

• workflow.search
• workflow.run
• analysis.context.get
• artifact.read, più helper di compatibilità per artefatti come artifact.list, artifact.diff e artifact.download
• report.summarize, report.generate, workflow.summarize
• workflow.semantic_name_review
• workflow.function_explanation_review
• workflow.module_reconstruction_review
• tool.help, tool.readiness e tools.discover per ispezione di compatibilità/debug

Architettura

Il percorso del codice attuale è: