x64dbg-MCP Server は、Windowsデバッガ x64dbg の全機能をMCP経由でAIアシスタントに操作させるネイティブプラグインです。duty1g/x64dbg-mcp-server として2026-08-22に公開され、2日で★891を集めました。「calc.exe をロードしてエントリポイントで止めて」と書けば、AIが LoadBinary → SetBreakpoint → run → WaitForPause を順に呼ぶ——そういう作りになっています。
- ・正体：x64dbg のネイティブプラグイン。デバッガ機能をMCPツール71種としてHTTPで公開する
- ・何ができる：AIにブレークポイント設定・ステップ実行・メモリ読み書き・逆アセンブル・パターンスキャン・OEP検出まで行わせる
- ・何を代替できる：GUIを人手で操作しながらの探索的デバッグ。定型の調査手順をAIに投げられる
- ・実装：Zig製・依存ゼロ・単一バイナリ。.NETもPythonも要らない。x32/x64を1コマンドで両方ビルド
- ・実測：ソースのツール定義を数えて71個ちょうどを確認。イベントコールバック22種
- ・注意：既定のバインドが 0.0.0.0（全インターフェース）。ローカル利用なら 127.0.0.1 へ変更する
MCPサーバーそのものの作り方は MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアル にまとめてあります。本記事は「デバッガをMCP化するとどうなるか」に絞ります。
x64dbg-MCP Serverで何ができるのか——71ツールの中身
READMEは「71 MCP Tools」と書いていますが、この種の数字は実装と食い違うことがあるので、ソースを直接数えました。
git clone https://github.com/duty1g/x64dbg-mcp-server.git
cd x64dbg-mcp-server
# ツール定義の実数を数える
grep -o '\.name = "[A-Za-z_]*"' src/mcp/tools.zig | wc -l
# → 71
READMEの記載と一致しました。71個は大きく2群に分かれています。
常時利用可能（デバッグセッション不要）——GetDebugState（デバッガの状態・PID・命令ポインタ）、LoadBinary（実行ファイルのロード）、AttachProcess（PIDで実行中プロセスにアタッチ）、ExecuteDebuggerCommand（任意のx64dbgコマンド実行）、SearchForStrings（プロセスメモリ内の文字列検索）、EvalExpression（x64dbg式の評価）、GetEventLog（直近の例外・ブレークポイント・DLLロード）など。
デバッグセッション中のみ——残りの大半がここです。カテゴリで整理すると次のようになります。
| カテゴリ | 代表的なツール |
|---|---|
| 実行制御 | run / StepInto / StepOver / StepOut / PauseDebug / RunToAddress / TraceInto |
| ブレークポイント | SetBreakpoint / SetHardwareBreakpoint（DR0-DR3）/ SetConditionalBreakpoint / ToggleBreakpoint / ResetHitCount |
| メモリ | ReadMemory / WriteMemToAddress / DumpMemory / AllocateMemory / FreeMemory / GetMemoryMap / FollowPointer |
| コード解析 | Disassemble / DisassembleFunction / Assemble / GetFunctions / GetReferences / FindPattern / GetStrings |
| モジュール・シンボル | ListModules / GetImports / GetExports / SearchSymbols / ListSymbols / AnalyzeModule |
| スレッド・スタック | GetThreads / SwitchThread / SuspendThread / ResumeThread / GetCallStack / GetArguments |
| Windows内部構造 | GetPEB / GetSEHChain |
| アンパッキング寄り | DetectOEP / DumpModule / GetDumpableRegions / GetPatches / RestorePatches |
| 注釈 | CommentOrLabelAtAddress / SetBookmark / ListBookmarks |
① 何ができる：AIアシスタントがx64dbgを直接操作し、ブレークポイント設定からメモリダンプ、OEP検出までを自然言語の指示で実行する。② 何を解決する：GUIを手で操作しながらの反復的な探索作業。定型の調査手順をAIへ委譲できる。③ 何を代替できる：Pythonスクリプトでx64dbgを自動化していた部分。ランタイム不要の単一バイナリで置き換わる。
22のイベントコールバック——AIが「今なにが起きたか」を知る仕組み
ツール71種と並んでREADMEが挙げているのが「22 Event Callbacks」です。これもソースで数えられます。src/main.zig の登録配列を見ると、ちょうど22件でした。
# 登録されているコールバックを数える
sed -n '/const cbs = /,/^ };/p' src/main.zig | grep -c "CB_"
# → 22
登録されているのは次の22種です。
| 分類 | コールバック |
|---|---|
| セッション | CB_INITDEBUG / CB_STOPDEBUG / CB_STOPPINGDEBUG / CB_ATTACH / CB_DETACH |
| プロセス | CB_CREATEPROCESS / CB_EXITPROCESS |
| スレッド | CB_CREATETHREAD / CB_EXITTHREAD |
| DLL | CB_LOADDLL / CB_UNLOADDLL |
| 停止契機 | CB_BREAKPOINT / CB_EXCEPTION / CB_SYSTEMBREAKPOINT / CB_STEPPED / CB_PAUSEDEBUG / CB_RESUMEDEBUG |
| その他 | CB_DEBUGEVENT / CB_TRACEEXECUTE / CB_OUTPUTDEBUGSTRING / CB_SELCHANGED / CB_ANALYZE |
これが効いてくるのは GetEventLog ツールです。デバッガ側で起きたイベントがログに蓄積され、AIはあとから「直近で何が起きたか」をまとめて取得できます。MCPはクライアントからの問い合わせが基本で、サーバー側から自発的にプッシュするのが得意ではないため、イベントを溜めておいて聞かれたら返す、という設計になっています。
例外が飛んだ瞬間やDLLがロードされたタイミングは、リバースエンジニアリングでは重要な手がかりです。ステップ実行のたびにAIが状況を推測し直すのではなく、GetEventLog で事実を取りにいける構造になっているのは実用上の差になります。
Zigで書かれていることの実務的な意味
デバッガプラグインの実装言語は、普段なら気にしなくていい話です。ただこのプロジェクトではそれが導入体験に直結しています。
build.zig.zon を見ると、依存は空です。
cat build.zig.zon
# .{
# .name = .x64dbg_mcp_server,
# .version = "1.0.0",
# .minimum_zig_version = "0.14.0",
# ...
# }
外部パッケージの記載がなく、依存ゼロでビルドが通ります。結果として配布物は単一バイナリのプラグインDLLだけになり、導入は「dist/ の中身を x64dbg のルートフォルダにコピーして起動」で完了します。Pythonの仮想環境も.NETランタイムも要りません。
| 比較軸 | 一般的なスクリプト型プラグイン | x64dbg-MCP Server（Zig） |
|---|---|---|
| ランタイム | Python / .NET 等が別途必要 | 不要（単一バイナリ） |
| 配布物 | スクリプト＋依存パッケージ群 | プラグインDLLのみ |
| x32/x64対応 | それぞれ環境を用意 | 1コマンドで両方ビルド |
| クロスコンパイル | 基本的に不可 | Linux/macOS/WSLからWindows向けに可能 |
| 導入手順 | 環境構築が前提 | フォルダにコピーして起動 |
解析用のWindows VMは、なるべく余計なものを入れたくない環境です。解析対象と一緒にPythonランタイムを同居させずに済むのは、この用途では実利があります。
クロスコンパイルの話も実務では効きます。Zigはツールチェーンにクロスコンパイル機能を内蔵しているため、LinuxやmacOSの開発機でWindows向けプラグインをビルドできます。解析用のWindows VMには成果物のDLLだけを持ち込めばよく、VM側にビルド環境を作る必要がありません。マルウェアを扱うVMはスナップショットから頻繁に巻き戻すので、「環境構築をやり直さなくていい」のは地味に効く利点です。
プロトコル面は MCP 2024-11-05 仕様に準拠し、Streamable HTTP と SSE の両方をサポート、JSON-RPC 2.0 で通信します。新しめのクライアントは Streamable HTTP、古いクライアントは SSE、という使い分けです。
導入手順と設定——x64dbg-MCP ServerをClaude Codeに繋ぐ
導入自体は3ステップです。
# 1. リリースをダウンロードし、dist/ の中身を x64dbg のルートへコピー
# （x32版・x64版が同時に配置される）
# 2. x64dbg を起動 → MCPサーバーが自動起動する
# 既定ポート: x64 = 9094 / x32 = 9095
# 3. ソースからビルドする場合（Zig 0.14.0 以上）
zig build -Doptimize=ReleaseFast
MCPクライアント側の設定は .mcp.json などに次のように書きます。トークンは初回起動時に自動生成され、プラグインメニューの設定ダイアログで確認できます。
{
"mcpServers": {
"x64dbg": {
"type": "http",
"url": "http://localhost:9094/",
"headers": { "Authorization": "Bearer YOUR_TOKEN_HERE" }
}
}
}
設定はプラグインメニューのダイアログから変更でき、保存するとMCPサーバーが自動で再起動します。x64dbgを立ち上げ直す必要はありません。バインドアドレス・ポート・トークンの3つがここで変えられます。サーバー自体もx64dbgの起動と同時に自動で立ち上がるため、使うたびに何か操作する必要はない作りです。
接続後の使い方は、READMEの例がそのまま実像を示しています。「calc.exe をロードしてエントリポイントで止めて」と書くと、AIが LoadBinary → SetBreakpoint → run → WaitForPause を順に呼び、「レジスタを見せて」で GetAllRegisters、「現在の命令ポインタから64バイト読んで」で ReadMemory が走ります。個々のツールを人間が指名する必要はなく、意図を書けばAIが手順に分解するという設計です。
MCPサーバーを自動起動"] B --> C["初回起動時に
Bearerトークンを自動生成"] C --> D{"バインドアドレス"} D -- "既定 0.0.0.0" --> E["全インターフェースで待受
WSL・リモートから到達可"] D -- "127.0.0.1 へ変更" --> F["ローカルのみ"] E --> G["MCPクライアントが
Authorization ヘッダで接続"] F --> G G --> H{"トークン一致？"} H -- いいえ --> I["401 Unauthorized"] H -- はい --> J["71ツールが利用可能に"]
実際の解析セッションはどう進むか
抽象的な説明より、指示とツール呼び出しの対応を見るほうが早いでしょう。READMEの例と71ツールの構成から、典型的なリバースエンジニアリングの流れを整理します。
| 人間が書く指示 | AIが呼ぶツール列 |
|---|---|
| 「対象をロードしてエントリポイントで止めて」 | LoadBinary → SetBreakpoint → run → WaitForPause |
| 「いまのレジスタを全部見せて」 | GetAllRegisters |
| 「RIPから64バイト読んで」 | GetCurrentAddress → ReadMemory |
| 「3命令ステップオーバーしてスタックを見せて」 | StepOver ×3 → GetCallStack |
| 「この関数の逆アセンブルを全部出して」 | DisassembleFunction |
| 「読み込まれているDLLとインポートを一覧して」 | ListModules → GetImports |
| 「メモリからこのバイト列を探して」 | FindPattern |
| 「パックされてそうなので本来のOEPを探して」 | DetectOEP → GetDumpableRegions → DumpModule |
ポイントは、人間がツール名を指定していないことです。MCPはツールの説明文をモデルに渡すので、意図さえ書けばモデル側が手順に分解します。逆に言うと、71個のツール説明がコンテキストを占有するため、このMCPサーバーを繋いだセッションはそれなりに重くなる点は意識しておく価値があります。
なお WaitForPause の存在が地味に効いています。デバッガ操作は「実行 → 止まるまで待つ → 状態を見る」の繰り返しですが、待機を明示的なツールにしておかないとAIが「実行した直後にレジスタを読む」ような順序ミスをします。ブロックする専用ツールを用意してあるのは、実際にAIに操作させた経験が反映された設計に見えます。
類似アプローチとの位置づけ
デバッガや逆アセンブラをAIから操作する試みは、この1年でいくつか現れています。用途が近いものと比べると立ち位置がはっきりします。
| 軸 | x64dbg-MCP Server | 一般的なIDA/Ghidra連携MCP | 従来のスクリプト自動化 |
|---|---|---|---|
| 対象 | x64dbg（動的解析） | IDA / Ghidra（静的解析中心） | ツール個別のAPI |
| 実行中プロセスの操作 | できる（ステップ・メモリ書換） | 基本的にできない | ツール次第 |
| 実装 | Zig・依存ゼロ | Python実装が多い | Python等 |
| AIからの利用 | MCPで標準化 | MCPで標準化 | 都度スクリプトを書く |
動的解析（実行しながら追う）をAIに任せられるのがこのプロジェクトの差分です。静的解析側のMCPは逆アセンブル結果の読解を助けますが、「実際に走らせて分岐がどちらに倒れるか見る」はできません。マルウェア解析やアンパッキングでは動的側が必要になる場面が多く、そこを埋めにきています。
静的解析側の代表例は IDA Pro MCPとは｜IDA ProをAIから操作する使い方・導入手順とheadless実行【★11,000超】 で扱ったものです。両者は競合というより役割分担で、逆アセンブル結果の読解をIDA側に任せ、実際の挙動確認をx64dbg側に投げる、という使い分けが素直でしょう。攻撃側のツール群をMCP化する流れ全般については MCP for Security完全ガイド：Nmap・SQLmap・Nucleiなど22ツールをClaudeから自然言語で操作する にまとめてあります。
一方、AIに実行中プロセスの操作権限を渡すというのは静的解析より踏み込んだ行為でもあります。WriteMemToAddress や AllocateMemory まで公開されているので、隔離環境の重要度は静的解析ツールの比ではありません。
使う前に確認すべきこと——既定バインドとネットワーク露出
ここは実際に使う前に必ず押さえてください。既定のバインドアドレスが 0.0.0.0、つまり全ネットワークインターフェースで待ち受けます。ソースで確認できます。
# 既定値の定義箇所を確認する
grep -n '0\.0\.0\.0\|default_port' src/core/config.zig
# 204: const default_port: u16 = if (@sizeOf(usize) == 8) 9094 else 9095;
# 206: const default_ip = "0.0.0.0";
これは意図的な設計で、設定ダイアログにも「WSLやリモートアクセス用に 0.0.0.0、ローカルのみなら 127.0.0.1 を使え」と説明が出ます。WSL上のClaude CodeからWindows側のx64dbgに繋ぐ、という現実的なユースケースがあるためです。
認証は実装されています。ソースを見ると未認証リクエストには 401 Unauthorized を返しており、トークンは64バイトのバッファで管理され、初回起動時に自動生成されます。飾りではありません。
ただし通信は暗号化されていないHTTPです。README自身がこの点を明記しています。
信頼できないネットワークにMCPサーバーを公開しないこと。Bearerトークン認証は強制されるが、サーバーは暗号化されていないHTTPで通信する。
このツールが公開しているのは「デバッガの全機能」——任意プロセスのメモリ読み書き・コード実行・プロセス操作です。同一ネットワーク上の第三者がトークンを入手すれば、解析用マシン上でそれらを実行できます。作者の注意書きに沿って、次の運用を推奨します。
・WSLやリモートから繋ぐ必要がないなら、設定ダイアログで
127.0.0.1 に変更する（既定のままにしない）・解析用VMはNATまたはホストオンリーのネットワークに置き、9094/9095 を外部へ転送しない
・トークンを設定ファイルごとリポジトリにコミットしない
・マルウェアを扱う環境なので、そもそも隔離されたVM以外で使わない
自分の環境で待ち受け状態を確認するコマンドも挙げておきます。
# Windows: 9094/9095 が何にバインドされているか確認する
netstat -ano | findstr "9094 9095"
# 0.0.0.0:9094 と表示されたら全インターフェースで待受中
# 127.0.0.1:9094 ならローカルのみ
ライセンスと開発状況——新しさをどう見るか
ライセンスは MIT です。商用利用・改変・再配布に制限はなく、リバースエンジニアリング業務のツールチェーンに組み込むうえで障害になりません。
一方で、新しさは正直に見積もったほうがいいプロジェクトです。
| 項目 | 実測値（2026-08-24時点） |
|---|---|
| リポジトリ作成 | 2026-08-22 |
| ★ | 891 |
| フォーク | 89 |
| オープンIssue | 0 |
| タグ | 1.0 |
| 主言語 | Zig |
| ライセンス | MIT |
公開から2日で★891という伸び方で、注目度は高いものの、実運用での検証期間はまだほとんどありません。オープンIssueが0なのも「問題がない」というより「まだ十分に使われていない」と読むほうが安全でしょう。x64dbgのバージョン差やWindows環境差でどう転ぶかは、これから明らかになる段階です。
用途については作者がREADMEで明示しています——「正当なリバースエンジニアリング、マルウェア解析、セキュリティ研究、教育目的のみ」。デバッガを外部から操作できるツールである以上、この線引きは利用者側でも守る必要があります。
触る前に決めておくとよいこと
導入自体は数分で終わりますが、先に決めておくと後が楽な項目があります。
| 決めること | 推奨 |
|---|---|
| バインドアドレス | WSL経由が不要なら 127.0.0.1。必要なら 0.0.0.0 のままVM側のネットワークを絞る |
| 動かす環境 | スナップショットを取った隔離VM。ホストOSでは動かさない |
| 接続するAIクライアント | セッションが重くなるので、RE作業専用のプロファイルを分ける |
| 解析対象 | 最初は calc.exe など無害なもので一巡し、ツールの挙動を把握してから本番へ |
とくに3つ目は実務的です。71ツール分の説明がコンテキストに載るため、普段のコーディング用セッションにこのMCPサーバーを常時繋いでおく理由はありません。必要なときだけ繋ぐ運用が素直でしょう。
まとめ
・x64dbg の機能をMCPツール71種としてHTTPで公開するネイティブプラグイン。ソースで実数を確認済み
・Zig製・依存ゼロ・単一バイナリ。解析用VMにランタイムを持ち込まずに済む
・実行制御・メモリ・逆アセンブル・シンボルに加え、OEP検出やモジュールダンプなどアンパッキング寄りのツールも揃う
・MCP 2024-11-05 準拠。Streamable HTTP と SSE の両対応で、新旧クライアントを選ばない
・既定バインドは 0.0.0.0。ローカル利用なら設定ダイアログで
127.0.0.1 へ変更する・Bearer認証は実装済み（未認証は401）だが通信は平文HTTP。信頼できないネットワークに出さない
・MIT。ただし作成から2日・★891の段階で、実運用での検証はこれから
MCPの応用として面白いのは、このプラグインが新しいことを何もしていない点です。x64dbgが元から持っていた機能を、MCPという共通インターフェースに載せ替えただけ。それだけで「AIに逆アセンブルの手順を任せる」という使い方が成立してしまいます。既存のツールにMCPの口を付けると何が起きるか、という意味で分かりやすい実例です。
導入のハードルは低い一方、公開しているのがデバッガの全権限であることは忘れないほうがいいでしょう。まず 127.0.0.1 に変えてから使い始める——これだけは最初にやっておくことをおすすめします。
参照ソース
・duty1g/x64dbg-mcp-server（公式リポジトリ・README） — 71ツール・22コールバック・導入手順・セキュリティ注意書きの出典。src/mcp/tools.zig と src/core/config.zig は実数・既定値の確認に使用
・x64dbg 公式サイト — 本体デバッガ。本プラグインの前提
・Model Context Protocol 公式 — 準拠仕様（2024-11-05）と Streamable HTTP / SSE の定義
