約40MBのバイナリにバックドアを隠し、AIとGhidraにそれを見つけさせました

92日前原文(quesma.com)

概要

AIエージェントによる バイナリ実行ファイルのマルウェア検出 ベンチマークの作成
Claude Opus 4.6 を含む最新AIモデルの性能評価
Dragon Sector の逆アセンブリ専門家との協力による検証
BinaryAudit プロジェクトで詳細結果とオープンソース課題を公開
AIの現状の限界と今後の展望について解説

AIエージェントによるバイナリマルウェア検出の最前線

Claude などのAIはコード生成だけでなく、 バイナリ実行ファイルの解析 能力も持ち始めている
Dragon Sector のMichał “Redford” Kowalczykと協力し、 ソースコード非公開のバイナリ からバックドアを発見するベンチマークを作成
BinaryAudit で全ベンチマーク結果（誤検知率、ツール習熟度、コスト効率のパレートフロンティア）を公開
- すべての課題は quesmaOrg/BinaryAudit でオープンソースとして入手可能
Claude Opus 4.6の成功率は 49% （小中規模バイナリの明白なバックドアのみ）、多くのモデルで 高い誤検知率 を確認
現状では 本番運用には不十分 だが、一部の隠れたバックドア検出に成功し、可能性を示唆

バイナリ解析と実社会の脅威

近年のサプライチェーン攻撃や Node Package Manager の侵害、Notepad++のバイナリ差し替え事件など、 実際のセキュリティ被害 が多発
IoT機器や ファームウェア は検査が難しく、国家・企業による改ざんリスクが現実化
逆アセンブリの実例として ポーランドの列車 や中国製インバータ等の研究事例を紹介
ネットワーク機器 の隠し管理者パスワード問題など、悪意なき設計ミスも脅威

バイナリ解析の技術的背景

ソースコードは 高レベル抽象化 だが、バイナリは CPU命令列 のみが残る
コンパイラ最適化 により構造情報や変数名が消失、解析難易度が急上昇
分析工程：
- 機械語 → アセンブリ（objdump等で可視化）
- アセンブリ → 疑似C（Ghidra、Radare2、IDA Pro等の逆コンパイラ活用）
逆コンパイル後も 意味不明な関数名や変数名 が並び、完全な理解は困難

ベンチマーク課題の設計

lighttpd、dnsmasq、Dropbear、Sozu等 オープンソースプロジェクト に 人工的にバックドアを挿入
- 例：HTTPヘッダによるコマンド実行機能の埋め込み
バイナリは シンボル・ソースなし で提供、AIはGhidraやRadare2等のツールを利用可
タスク： 悪意あるコードの特定 と バックドア関数の開始アドレス の指摘（例：0x4a1c30）
一部課題では 複数バイナリの比較 によるバックドア有無判定も実施

AIによる解析プロセス例

lighttpdのバックドア 検出ケース
- Claudeはまず 共有ライブラリ を特定し、popen等の危険関数の利用有無を確認
- nmやgrepで関数インポートを調査し、popen利用を検知
- Radare2の逆コンパイラで li_check_debug_header 関数を解析、隠しHTTPヘッダによるコマンド実行ロジックを特定
- クロスリファレンスで 死コードでないこと も確認
解析手順を段階的に自動化し、AIが人間のリバースエンジニアのように推論

AIの限界と課題

dnsmasq への単純なバックドア挿入でも、多くのAIモデルは 検出に失敗
バイナリ解析は依然として 人間の専門家による手作業 が不可欠
誤検知率の高さ や 複雑な最適化バイナリ への対応力不足が課題

今後の展望

AIによるバイナリ解析は 着実に進化 しているが、現時点では 補助的なツール に留まる
精度向上や 誤検知抑制、より難解なバックドア検出能力の向上が今後の課題
BinaryAudit のようなオープンベンチマークが、研究と実装の加速に寄与

参考リンク

BinaryAudit プロジェクト：quesmaOrg/BinaryAudit
詳細なベンチマーク結果、使用ツール、タスク設計、誤検知率などを公開
Dragon Sector、Michał “Redford” Kowalczykの活動や講演も参考

この分野は今後も AIとセキュリティ専門家の協働 が不可欠。AIの進化とともに、より高度なマルウェア検出やリバースエンジニアリング手法の発展が期待される。

Hackerたちの意見

直接のベンチマークリンクはこちら: https://quesma.com/benchmarks/binaryaudit/ オープンソースのGitHub: https://github.com/QuesmaOrg/BinaryAudit

「私たちのベンチマークにある実行ファイルは、しばしば何百、何千もの関数を持っています。一方で、バックドアは小さく、深く埋もれた十数行のコードであることが多いです。それを見つけるには、ネットワークパーサーやユーザー入力ハンドラーのような重要なパスを特定し、ノイズを無視する戦略的思考が必要です。LLMに.mdファイルで書かれた戦略ガイドを提供するのも良いかもしれません。」

└

それは難しいね。時々そうすると、モデルが「戦略トーク」に入っちゃって、.mdファイルで使ってる言葉や枠組みを使うけど、実際には戦略を実行しないことがあるんだ。うまくいく場合でも、人間の戦略的思考をAIが理解できるように具体的に示すのは結構難しいよ。

└

それも思った！彼らのタスクの定義を考えると（基本的に「このバイナリをこのツールでチェックして」って言ってるだけ！）、その結果はすでにすごく印象的だよ。適切なガイダンスと専門家の監視があれば、ものすごい力の倍増になるね。

└

研究の質問によりますが、実験を台無しにするのはとても簡単です。例えば、小さなバックドアがあるかもしれないと言ったとしましょう。そうすると、LLMがその方向で探すように仕向けてしまいます（「かもしれない」を使っても）。テストの情報をテストを受ける側に渡してしまったわけです！新しい変数ができました！成功はそのヒントのおかげだけなのか？そのプロンプトはどれくらい堅牢ですか？微妙な言い回しが出力を大きく変えることはありますか？「かもしれない」、「する」、「できる」、「かもしれない」は機能しますが、「May」、「cann」、または他の何かは失敗しますか？プロモーターがテストについて重要なことを意図せずに伝えてしまったことはありませんか？成功するためにプロンプトエンジニアリングを駆使できると思いますが、そうすると実験の複雑さが大きくなり、その結果、結果がずっと堅牢でなくなります。実験デザインは非常に難しいです。微妙な点が多すぎて、ほとんどの人（科学者を含む）がしばしば失敗し、実験がもたらす以上の強い主張を信じ込んでしまうことが多いです。そして、誰かが「でも人間は」と言う前に、そういう複雑さは同じように適用されます。実際、人間の実験が他の多くのことよりも難しい理由です。システム内にはもっとノイズがあるからです。でも成功することはできるでしょう？もちろん。バックドアがどこにあるかを正確に教えることもできます。でも、それはあまり役に立ちません。だから、その境界線がどこにあるかを決める必要がありますが、他の人たちは同意しないでしょう。

宣伝失礼します: https://github.com/akiselev/ghidra-cli Ghidraを使ってAltiumのファイルフォーマット（少なくともDelphi部分）をリバースエンジニアリングしているんですが、効果がすごいです。モデルは完全にパーサーをゼロから作るにはまだ不十分ですが、LLMがなかった頃はリバースエンジニアリングを試みることすらなかったと思います。セキュリティ監査には依存しないでしょうが、最新のモデルはファイルフォーマットのリバースエンジニアリングには十分すぎるくらいです。

└

おお、いい発見だね…私たちはPyGhidraを使ってるけど、モデルが悪い ergonomics のせいで無駄にサイクルを消費しちゃう。あなたのCLIの方が使いやすいかも。とはいえ、Ghidraの一番の痛点はGo Langの遅さだった。あの例はベンチマークから除外しなきゃいけなかったよ。

└

このアプローチは、さまざまなGhidra MCPサーバーと比べてどうなの？

└

エージェントの使い方について、合理的な結果が出ていることをお伝えします。これは高レベルでお話ししますね。エージェントに完全に依存するわけではありません。あなたの能力を補強するエージェントを構築します。彼らは図を作成したり、攻撃面のマッピングを提供したり、あなたが手作業でやる間に掘り下げてくれたりします。監査を進める中で、バイナリやコードベースで興味深いものを見つけて、さらに調査したくなることがよくあります。LLMはコードベースやバイナリをサクサク進めて、似たようなものを見つけることができます。問題を解決するために展開するエージェントツールのスイスアーミーナイフのように考えています。彼らはすごく退屈な作業にも嫌がらず取り組んでくれるので、実際にスピードアップにつながります。ただ、LLMからあまりにも多くを引き出そうとすると、設定に時間をかけすぎて良い結果が得られない罠にハマることがあります。これがLLMの生産性の罠だと思います。でも、さまざまな監査タスクに展開できる「スキル」や「エージェント」の合理的なサブセットがあれば、確実にスピードアップできます。それに、スケールの問題があるときは、LLMを使ってみてください。質が低くても、良いスニッフテストになります。時々、出会ったコードベースのコードレビューにLLMを投げて、働かせることもあります。アーキテクチャ図を作ってもらうのも大好きです。

└

これめっちゃクールだね！シェアしてくれてありがとう。俺がGhidraとLLMsでやったことよりもずっと洗練されてるよ。

└

共有ありがとう！最近のMCPサーバーを見ると、活発な分野のようですね（https://news.ycombinator.com/item?id=46882389）。まだ試していなければ、Show HNとして投稿することをお勧めします。いくつかのアプローチを試しました - https://github.com/jtang613/GhidrAssistMCP（設定が一番難しかった） Ghidra analyzeHeadless（GPT-5.2-Codexがうまく動作しました！）そしてPyGhidra（私のお気に入り）。どれが一番良いか試してみましたか？特にAI用の明示的なREADMEがあるので、 https://github.com/akiselev/ghidra-cli/blob/master/.claude/s... あなたのアプローチはAIエージェントと使うのにもっと便利かもしれませんね。

GPTはモデル全体で一貫して0%の誤検知率を誇るけど、検出能力は最大18%なんだ。一方、Claude Opus 4.6はバックドアを最大46%検出できるけど、誤検知率は22%もある。これらのモデルがエクスプロイトをテストできる実験があったら面白いけど、彼らのアラインメントがそれを許さないかもしれない。モデルを組み合わせることで、その種のテストができるかも。より優れたモデルが「検証方法」を記述し、「アラインメントがずれた」モデルが実際にテストを行って、結果を優れたモデルに報告する感じかな。

└

誰かがバイナリ分類タスクの成功を測るための標準的な言語と方法論を開発したら、めっちゃクールだと思うんだけど…あ、待って、実はそれはもう100年前からあったんだよね。生成モデルが関わると、なぜか完全に忘れ去られちゃうけど。

彼らが何も難読化していないと言ったのは知ってるけど、インポートやシンボルを隠したり、文字列を難読化したりするのは、どんな有能な攻撃者にとっても最低限のことだから、成功率はすぐにゼロに落ちるよ。これは、悪意のある活動に関連する言語の異常パターンを検出することで、LLMにとっては特に印象的ではないね。

└

LLM用のghidra-cliツールを開発してたとき、テストとしてcrackmesを使ってたんだけど、プロンプトを与えれば難読化を問題なく突破できたよ。実際にリアルなソフトウェアをリバースエンジニアリングする時は、難読化されたコードに気づくまでぐるぐる回っちゃうこともあるけど、CLAUDE.mdや他のファイルにその結果を更新しておけば、その後はだいたいスムーズに進むよ。

└

LLMって、難読化されたコードをヒューリスティックよりも分析するのが得意じゃなかったっけ？パターンマッチングの能力で、難読化されたコードが何をしているかを推測できるからかな？

└

ここにいる著者の一人です。ここでのタスクは初心者向けなんで、いくつかのAIモデルがバイナリコードだけを見てパターンを検出できることに驚いています。これを当然だとは思っていません。例えば、GhidraやRadare2のツールを理解しているモデルはほんの数個（Opus 4.5と4.6、Gemini 3 Pro、GLM 5）だけです。 https://quesma.com/benchmarks/binaryaudit/#models-tooling これを、AIエージェントがバイナリと一緒に作業できるための出発点と考えています。他の人たちも同じことを発見しています - 例えば、 https://x.com/ccccjjjjeeee/status/2021160492039811300 と https://news.ycombinator.com/item?id=46846101。「おお、AIがそんなことできる！」から、エンドツーエンドのソリューションまで、まだまだ長い道のりがあります。

└

記事の中で、彼らは明示的にシンボルを削除したと言っていました。実際のバックドアを見ると、多くはすでに最小限でかなり難読化されています。詳しくはここを見てください：

https://github.com/QuesmaOrg/BinaryAudit/blob/main/tasks/dns...
https://github.com/QuesmaOrg/BinaryAudit/blob/main/tasks/dro...

└

シンボルを削除するのは普通のことだけど、インポートを隠すのはそれ自体が怪しいと思う。

└

Opus 4.5と4.6を使って、自分のGhidraプラグインで難読化された悪意のあるコードをリバースエンジニアリングしましたが、完全に逆アセンブルできました。もちろん、ソフトウェアのクラッキングについて話しているので、国家レベルのバックドアではありません。

└

LLMがそういう奇妙なことを理解するのに驚くほど効果的だって見たことがあるよ。結局、さまざまなデータフォーマットや暗号化方式、難読化手法の知識を取り込んでいるからね。むしろ、複雑な論理がLLMを打ち負かす要因になると思う。でも、良いモデルはそういう論理が扱えないことも強調するはずだよ。

エンドツーエンドのマルウェア検出はまだ信頼性がないけれど、AIは開発者が初期のセキュリティ監査を行うのを楽にしてくれる。リバースエンジニアリングの経験がない開発者でも、疑わしいバイナリの初期分析ができるようになった。[...] バイナリを扱う分野全体が、より広い範囲のソフトウェアエンジニアにアクセス可能になる。これにより、セキュリティだけでなく、低レベルの最適化やデバッグ、ハードウェアのリバースエンジニアリング、アーキテクチャ間のコード移植の機会も広がる。これが重要なポイントだよ。これらのツールが隣接性を強力な指標にしてくれる。リバースエンジニアになる必要はなくて、自分のソフトウェアがどう動いているかを理解して、ロボットを不完全な仮説生成器として導くことができるんだ。

Geminiが最も高い偽陽性率を返すっていうのは、私のGeminiモデルの使用経験と一致してる。ChatGPT、Claude、Geminiを定期的に使ってるけど、Geminiがその中で一番お世辞が多いのが明らかだよ。あの3つのモデルに何かを評価させたり成功の確率を推定させたりすると、Geminiはいつも一番楽観的な見通しを返してくる。お世辞の証拠を提供する良いベンチマークを探してたけど、あまり見つからなかった。モデルに検出関連のタスクを完了させるように頼んだときの偽陽性を測るのが、その方法としていいかもしれないね。

だから、見つかったのは約50%だったんだ。悪くないと思うし、多分ほとんどの人間よりはマシだよね。でも残りの50%はどうなったの？なんで見つかったものと見つからなかったものがあるの？

Claude Opus 4.6がそれを見つけて…心配する必要はないって自分を納得させたみたい。ベンチマークの中で一番のモデルでも、このタスクには騙されちゃったんだ。ちょっと変だよね。人間がいないとAIツールがこれを理解するのは難しいみたい。

Opus 4.6が「見つけて自分を納得させた」パターンは、私自身の作業でも常に見かけるものです。最良のモデルは信号を特定するのに十分賢いですが、それを合理化するのにも十分賢いです。だからこそ、フロンティアモデルを使っているときでも、人間の監視が重要なんです。モデルは仮説生成器であって、意思決定者ではありません。コンテンツパイプラインを構築しているときも同じことがわかりました。高価なモデル（Opus 4.6など）は、確かに最初の出力が良いですが、最終的には信頼できないです。人間のレビューを取り除いた瞬間、品質が微妙に崩れて、後で気づくことになります。誰かが言っていたマルチエージェントアプローチ（1つのモデルがフラグを立て、別のモデルが検証する）は興味深いですが、複雑さが増します。人間が検証層になる方がシンプルです。

このスレッドの方法論に関する議論が一番重要だと思う。「難読化を追加すると成功率がゼロになる」と言ってるコメント者は正しいけど、個人的にはそれが正しいアプローチとは思えない。実験はAIが有能な攻撃者に勝てると主張しているわけじゃなくて、AIエージェントがスキルのある（リバースエンジニアリングの）専門家が難読化されていないバイナリでやることを再現できるかどうかを問うているんだ。それは、対抗的なマルウェアをカバーしていなくても、内部監査やコードレビュー、レガシーバイナリ分析などの実用的なユースケースだよ。もっと役立つ視点は、正しい脅威モデルは何かってこと。スクリプトキディや自動ツールに対抗しているなら、AI支援のリバースエンジニアリングはもう十分かもしれない。でも、AI検出を使っていることを知っている人からの標的攻撃に対抗するなら、ハードルはかなり高くなるし、このテストはそれには関係ない。実際に「生産準備が整っているか」を決めるには、実際の展開で重要な最も弱い難読化（インポート隠蔽や文字列エンコーディング）を使って同じテストを実施することが必要だよ。これが境界条件だね。

└

それが何で重要なの？難読化されたバイナリに無頓着なのは、キャプチャテストに失敗するようなもんだよ。逆にするのではなく、リンゴを摘む仕事だと考えてみて。AIが普通の天候条件で果樹園のリンゴを全部摘めるとする。でも、曇り空を加えると成功率がゼロになる。これって、あなたの意見ではまだ熟練したリンゴ摘みの専門家なの？

ハクソク