elliottophellia/ryuumonbuchi

Возможно, вы ищете безголовую Ghidra MCP.

Обзор

Ryuumonbuchi превращает Ghidra в 217-инструментальный сервер Model Context Protocol. Агент LLM открывает двоичную систему и проводит анализ с помощью типизированных вызовов инструментов: декомпиляция, разборка, реконструкция типов, исправление, редактирование символов и памяти и экспорт проекта. Никакой автоматизации графического интерфейса, никаких рукописных скриптов.

Сервер построен на низкоуровневом MCP SDK ([T1]) с реестром, созданным из одного авторитетного каталога. Каталог объявляет 217 точечных названий инструментов; 212 карт один к одному на методы стойкого бэкэнда PyGhidra. health.ping и mcp.response_format являются нативными серверами, headless.run и headless.start являются нативными путями пусковой установки, а operation.batch является диспетчером пакетирования.

За транспортом один постоянный рабочий ребенок проводит живую сессию PyGhidra / JVM в течение всего срока службы MCP. Повторные звонки повторно используют теплый бэкэнд вместо оплаты запуска JVM за запрос.

Архитектура

Три пути отправки:

1. Рабочие инструменты (212): проверенные по схеме каталога, отправленные настойчивому ребенку по протоколу-v2 IPC, работают против сеанса живой программы.

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.