elliottophellia/ryuumonbuchi

希望するヘッドレスのGhidra MCPかもしれません。

概要

ユムンブチは、Ghidraを217ツールモデルコンテキストプロトコルサーバーに変換します。 LLMエージェントは、型付けされたツールコールを介してバイナリーとドライブ解析を開きます。分解、分解、分解、タイプ再構築、パッチ、シンボル、およびメモリ編集、およびプロジェクトエクスポート。 GUI の自動化、手書きなし analyzeHeadless] スクリプト。

サーバは、低レベルの MCP SDK ([mcp.server.lowlevel]) 上に 1 つの認証カタログから生成されたレジストリをビルドします。 カタログは、217点のツール名を宣言します。 212は、永続性PyGhidraバックエンドのメソッドに1対1マップします。 [[health.ping]とmcp.response_format]は、サーバーネイティブランチャーパスで、headless.runと[[[headless.start]は、バッチ処理ディスパッチャです。

輸送の背後にある1つの持続的なワーカーの子供は、MCP寿命全体にわたってライブPyGhidra/JVMセッションを保持しています。 繰り返しコールは、リクエストごとにJVMのスタートアップを支払う代わりに、温かみのあるバックエンドを再利用します。

アーキテクチャ

3つのディスパッチパス:

1。 ワーカーツール(212):カタログスキーマに対して検証され、プロトコルv2 IPC上の持続的な子供に送信され、ライブプログラムセッションに対して実行します。 2.

Overview

Ryuumonbuchi turns Ghidra into a 217-tool Model Context Protocol server. An LLM agent opens a binary and drives analysis through typed tool calls: decompilation, disassembly, type reconstruction, patching, symbol and memory edits, and project export. No GUI automation, no hand-written analyzeHeadless scripts.

The server builds on the low-level MCP SDK (mcp.server.lowlevel) with a registry generated from one authoritative catalog. The catalog declares 217 dotted tool names; 212 map one-to-one onto methods of a persistent PyGhidra backend. health.ping and mcp.response_format are server-native, headless.run and headless.start are the native launcher paths, and operation.batch is the batching dispatcher.

Behind the transport, one persistent worker child holds a live PyGhidra/JVM session for the whole MCP lifespan. Repeated calls reuse the warmed backend instead of paying JVM startup per request.

Architecture

 MCP client ── stdio or streamable HTTP ──► Ryuumonbuchi server
                                          (low-level SDK, schema/policy dispatch)
                                                     │
                                                     │ protocol-v2, 8-byte length-prefixed socket IPC
                                                     ▼
                                          persistent worker child
                                          (lazy PyGhidra/JVM, multiple program sessions)
                                                     │
                                  ┌──────────────────┴───────────────────┐
                                  ▼                                      ▼
                          backend (PyGhidra)              headless.run ── analyzeHeadless
                          program sessions,                (separate process group)
                          decompiler, analysis

Three dispatch paths:

1. Worker tools (212): validated against the catalog schema, sent to the persistent child over protocol-v2 IPC, run against a live program session.
2. headless.run: spawns support/analyzeHeadless directly with the caller’s argv in its own process group. No shell, no rewriting of arguments.