1 ポイント 投稿者 GN⁺ 2026-02-06 | 1件のコメント | WhatsAppで共有
  • Ghidra MCP Server は、Ghidraのリバースエンジニアリング機能を AIおよび自動化フレームワーク に接続する Model Context Protocol(MCP) サーバー
  • 110個のMCPツールと 132個のエンドポイント を通じて、関数解析、データ構造探索、文字列抽出など 広範なバイナリ解析機能 を提供
  • バッチ処理、アトミックトランザクション、リアルタイム解析 をサポートし、Dockerデプロイおよびヘッドレスモード で運用可能
  • Cross-binaryドキュメント移行 機能により、異なるバイナリバージョン間で関数ドキュメントを自動マッチング
  • AIベースのリバースエンジニアリングワークフローを プロダクションレベルの安定性 で実装できるプラットフォーム

概要

  • Ghidra MCP Serverは、Ghidraの解析エンジン をAIツールおよび自動化システムに接続する プロダクション向けMCPサーバー
    • Model Context Protocolを完全実装し、AIモデルとの相互作用をサポート
    • Ghidraの機能をHTTP RESTおよびMCPプロトコル(stdio/SSE)で公開

主な機能

  • Core MCP統合
    • MCP完全互換、110個のMCPツールを提供、バッチ処理およびアトミックトランザクションをサポート
    • Ghidraの解析エンジンとリアルタイム統合
  • バイナリ解析
    • 関数デコンパイル、コールグラフ、クロスリファレンス、データ構造の自動生成
    • 文字列抽出、シンボルテーブル解析、メモリマッピング、Cross-binaryドキュメント移行 機能を含む
  • 開発と自動化
    • ビルド-テスト-デプロイ-検証の自動化パイプライン
    • Ghidraスクリプトの生成・実行・管理、複数プログラム比較、大量リネームおよびコメント付与

インストールと実行

  • 必須要件: Java 21 LTS、Apache Maven 3.9+、Ghidra 12.0.2、Python 3.8+
  • インストール手順
    • リポジトリをクローン後、Python依存関係をインストール
    • Ghidraライブラリ14個をコピーした後、Mavenでビルド
    • Ghidra拡張フォルダにプラグインをデプロイ
  • 実行方法
    • Stdio転送(デフォルト、AIツール向け) または SSE転送(Web/HTTPクライアント向け) を選択
    • Ghidra内で Tools > GhidraMCP > Start MCP Server を実行

パフォーマンスと安定性

  • 110個のMCPツールを完全実装し、ほとんどの処理で 1秒未満の応答速度
  • API呼び出しを93%削減 するバッチ処理構造を実現
  • すべての処理は アトミックトランザクション として扱われ、信頼性を確保
  • バージョン認識型の自動デプロイスクリプトを提供

API構成

  • 中核処理: 接続確認、メタデータ照会、バージョン情報、エントリポイント探索
  • 関数解析: 関数一覧、名前検索、デコンパイル、呼び出し関係グラフ、ドキュメント完成度評価
  • メモリおよびデータ: セグメント一覧、逆アセンブル、クロスリファレンス、メモリ内容の検査
  • Cross-binaryドキュメント化: 関数ハッシュ生成、ドキュメントのエクスポート/適用、ハッシュベースのマッチング
  • データ型管理: 構造体・列挙型の作成、フィールド修正、重複型のマージ
  • シンボルおよびラベル管理: インポート/エクスポート一覧、文字列解析、名前空間およびグローバル変数管理
  • リネームおよびコメント付与: 関数・データ・変数のリネーム、大量コメント設定
  • 型システム: 関数プロトタイプ指定、変数型設定、呼び出し規約照会
  • Ghidraスクリプト管理: スクリプト一覧、実行、保存、修正、削除
  • 複数プログラム対応: 開いているプログラムの切り替え、プロジェクトファイル一覧、ドキュメント比較
  • 解析ツール: 未定義関数の探索、文字列ベース検索、バイトパターン探索

アーキテクチャ

  • AI/Automationツール ↔ MCP Bridge ↔ Ghidra Plugin 構成
    • bridge_mcp_ghidra.py: MCPプロトコルをHTTP呼び出しに変換するPythonサーバー
    • GhidraMCP.jar: Ghidra機能をHTTPで公開するJavaプラグイン
    • ghidra_scripts/: 70個以上の自動化スクリプトを含む

開発とビルド

  • MavenベースのビルドおよびPowerShellデプロイスクリプトを提供
  • プロジェクト構成はPythonサーバー、Javaプラグイン、Ghidraライブラリ、ドキュメント、サンプル、ビルドスクリプトで構成
  • 必須ライブラリ14個(約37MB) をGhidraインストールパスからコピーする必要あり
  • 自動デプロイ、バッチ処理、アトミックトランザクション、詳細ロギング機能を含む

ドキュメントとAIワークフロー

  • docs/ フォルダに全体ドキュメント、プロジェクト構成、命名規則、ハンガリアン記法を収録
  • AIワークフロープロンプト: 関数ドキュメント化、バージョン間マッチング、クイックスタートプロンプトを提供
  • リリース履歴: CHANGELOG.md および docs/releases にバージョンごとの詳細を収録

ライセンスと状態

  • Apache License 2.0 を適用
  • バージョン2.0.0、110個のMCPツールを完全実装、70個以上のGhidraスクリプトを収録
  • プロダクション環境へのデプロイ準備完了、AIベースのリバースエンジニアリングに適合

関連プロジェクト

  • re-universe: PostgreSQLベースの大規模バイナリ類似性解析プラットフォーム
  • cheat-engine-server-python: 動的メモリ解析およびデバッグ向けMCPサーバー

謝辞

  • Ghidraチーム、Model Context Protocol開発陣、コミュニティ貢献者への謝意

1件のコメント

 
GN⁺ 2026-02-06
Hacker Newsのコメント
  • 複数バージョンのソフトウェアをリバースエンジニアリングする作業があまりにもつらかったので、このプロジェクトを作ったとのこと
    中核は正規化された関数ハッシュ化システムで、関数の論理構造(命令、オペランド、制御フロー)を基準にハッシュを生成する
    そのおかげで、バイナリがリビルドまたはリベースされても同一の関数は同じハッシュを持ち、すべてのコメント、型、名前が自動で引き継がれる
    Ghidra向けのMCPブリッジとして110個のツールを含み、Claude、Claude Code、または他のMCPクライアントと統合可能
    Diablo IIの複数パッチ版で検証し、1,300件以上の関数コメントを自動移行できたという
    DockerベースのheadlessモードによりCI統合も可能
    v2.0.0ではローカルホスト専用バインド、タイムアウト設定、ラベル削除、.env設定などを追加した
    ハッシュ化アプローチやMCP設計についての議論は歓迎とのこと

    • Ghidra標準のFunctionIDやBinDiffプラグインと比べて何が違うのか気になる
    • ReVaと比べるとどうなのか気になる
      インストールガイドが不完全なように見える。Ghidraにインストールして再起動したが、ToolsメニューにGhidraMCPが表示されない
    • 実際に試してみようとしたが、Ghidraがプラグインを認識しない
      GH Discussionsが適切な連絡チャネルなのか気になる
    • 他のGhidra MCPサーバー(pyghidra-mcp、ReVa、GhidrAssistMCPなど)との違いが気になる
    • Androidバイナリのデコンパイル対応があるのか気になる
  • LaurieWiredのGhidra MCPサーバーを使ってみたが、バイナリ解析とキーゲン作成がとても楽しくて簡単だった
    このMCPサーバーもぜひ使ってみるつもり

    • 以前作ったソフトウェアが、もう存在しないサーバーに認証を要求するせいでインストールできず、自分でGhidra MCPを作ろうとして失敗したことがある
      このタイミングでこのプロジェクトが出てきて不思議な感じがする
    • このブランチはLaurieWired/GhidraMCPのmainより110コミット先行している
  • 同僚がClaudeと一緒にGhidraを使ってRiver Rideというゲームをハックしているのを見て、自分も試してみた
    PowerPC向けの古いゲームをApple Siliconへ移植したが、いくつかのMCPを試した中でClaude Codeはコードを頻繁に捏造した
    最終的にはCursor + GPT 5.2 Codexのheadlessモードで最も良い結果が得られた

    • 自分もリバースエンジニアリングを実験中だが、GPT-5.2 CodexはClaudeよりはるかに優れている
      たとえば1,300行のC64-SIDファイルを30分で完全復元した
      現在、C64ゲーム全体を逆解析するマルチエージェントシステムを作っている
      サンプルコードを参照
  • AIを使ったリバースエンジニアリングは過小評価されている
    自分はAndroidアプリから暗号鍵の抽出に成功したが、その鍵はシェーダ内に隠されており、実際にシェーダを実行しないと取得できなかった

    • 友人と一緒に古いUnityゲームをClaudeに与えたところ、完全なTypeScript移植版を作ってくれた
      今はブラウザでマルチプレイ機能を追加している
    • シェーダから鍵を抽出したという話が興味深い。具体的な方法をもう少し聞いてみたい
    • 自分もMCPと複数のツールをつないで、バイナリからのソースコード復元と脆弱性検出を試したが、実際のソースとほぼ一致していた
  • LaurieWiredの15ツール版を数か月使っているが、アプリの内部構造が完全に透けて見える感覚
    バグ追跡、プラグイン作成、アプリ改変までできる
    Objective-CコードにはHopper Disassemblerも併用している
    関連論文: Full recompilation with LLMs and Ghidra

    • アプリのリバースエンジニアリングをOSSと同一視するのは、GitHub社員としてあまり良い印象ではない
  • LLMを使ったリバースエンジニアリングは本当に過小評価されている
    30年前のゲームを復元中だが、Ghidraのデコンパイル結果とシンボル情報をRAG方式でモデルに与えると驚くほど良い結果が出る
    Gemini 3 Flashのような低価格モデルでも十分実用になる

    • ただしGeminiはしばしば不完全な疑似コードを生成する
      関数の一部を省略したり、switchブロック内部をコメントだけで残したりする
      一方でClaude OpusやQwen3-30B-A3Bははるかに完成度の高いコードを出す
      Geminiの大きなコンテキストウィンドウは利点だが、PCodeの冗長さのせいで実際には制約も多い
  • MCPにあまり多くのツールをつなぐと性能が落ちると思っていたので、これは良い設計には見えない

    • 最近はlazy loadingでMCPツールの問題をある程度解決している
      ただ、それでもAPI変換中心のツールはLLMとの相性があまり良くない
    • vibecodedベースのスキル型ツールのほうがずっと効率的だと思う
  • 自分はリバースエンジニアではないが、Claude CodeとGhidra MCPを使ってランサムウェア復号ツールを改善した
    数テラバイトのデータを復旧できたとき、本当に超能力を手に入れた気分だった

    • 「その超能力で暗号化ツールのほうももっと信頼性高く作れたんじゃない?」という冗談を言われた
  • AIはバイナリ解析で超人的な能力を発揮できると思う
    今は生産性が低く退屈な作業だが、AIのおかげでセキュリティ監査やサプライチェーン攻撃の防御にも活用できる

    • その通り。しかもAIが自分自身を解析することも可能だ
      MOOLLMの「skill-snitch」は他のスキルの動作を監視し、「cursor-mirror」はCursor内部状態を完全に見通す
      こうしたスキルは相互に組み合わせや再帰呼び出しが可能で、MCPよりはるかに速い「speed of light」方式で動作する
      関連資料: Leela MOOLLM Demo Transcript, speed-of-light skill, skill-snitch report
  • なぜCLIベースで作らなかったのか気になる。最近のLLMやエージェントはCLIのほうが扱いやすい気がする

    • それはCLIが学習データに含まれている場合に限ると思う。新しいツールならどうせドキュメント全体をコンテキストに入れなければならない
    • このプロジェクトは、MCPがコンテキストを過剰に消費する前に始まったものだ(LaurieWired/GhidraMCP
    • 最近のClaude Codeのようなツールはツール検索ベースの読み込みをサポートしており、MCPのコンテキスト負荷はかなり減った
    • 自分も同感だ。110個のツール説明が常にコンテキストに入るなら、ノイズが増えるだけだ