ハクソク

世界を動かす技術を、日本語で。

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

2026年2月22日原文(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%もある。これらのモデルがエクスプロイトをテストできる実験があったら面白いけど、彼らのアラインメントがそれを許さないかもしれない。モデルを組み合わせることで、その種のテストができるかも。より優れたモデルが「検証方法」を記述し、「アラインメントがずれた」モデルが実際にテストを行って、結果を優れたモデルに報告する感じかな。

Hacker Newsで議論の続きを見る