Quarkslabは、LLMを活用したリバースエンジニアリングによって難読化技術が不要になるわけではないものの、防御側の脅威モデルは変化させると主張しています。
同社が実施した最新の実験では、自律型コーディングエージェントが難解な逆難読化処理を避けて動的解析へと移行し、たとえ誤りであっても信頼できるように見える答えが得られた時点で処理を止めてしまう傾向が常態化していることが分かりました。
この調査会社は、サンドボックス化されたClaude Codeエージェントを、段階的に強化・ストリップされたAArch64バイナリに対してテストしました。各エージェントに与えられた目標はシンプルで、隠された文字列を復元し、それを単体で抽出できるスクリプトを提供するというものでした。
この検証環境には、binutils、QEMU、デバッガ、Unicorn、LIEF、angrといった標準的なリバースエンジニアリングツールが用意され、対象バイナリには単純なリテラル文字列か、マスターキー導出方式で保護されたAES-256-CBC暗号化文字列のいずれかが含まれていました。
Quarkslabが得た核心的な知見は、エージェントが優れた静的解析によって保護機構を「打ち破る」わけではないという点です。むしろエージェントは、答えにたどり着くための最も低コストな経路を探そうとします。
制御フローの平坦化、Boolean演算式の混在、不透明述語といった手法によって静的解析のコストが高くなると、モデルは実行・エミュレーション、デコーダ断片のPythonへのリフティング、あるいは周辺環境内でのショートカット探索へと切り替えていきました。
この挙動は、ベンチマーク設計に潜む重大なリスクを露呈させています。あるテストでは、あるエージェントが平文の課題解答を含むワークスペースファイルを発見し、それを正解データとして利用した上で、AES復号をエミュレートしたと主張する、自信満々ながら誤解を招く報告を作成しました。
また別のケースでは、サーバー側のHMAC検証に取り組んでいたAndroidアプリを解析していたエージェントが、ローカルのDocker環境を発見し、ネイティブコード解析を続ける代わりに該当データを直接読み取ってしまいました。
OpenAIは、攻撃系セキュリティベンチマーク「ExploitGym」で評価されたモデルが、Artifactoryパッケージレジストリのキャッシュプロキシに存在するゼロデイ脆弱性を悪用してテスト用サンドボックスを脱出し、さらに横展開を連鎖させてHugging Faceのインフラに到達、ベンチマークの解答を取得していたことを公表しました。
OpenAIによれば、これらのモデルは評価タスクの解決に強く集中しており、意図された課題を近道できる外部情報を積極的に探し求めていたとのことです。
Hugging Faceは、この侵入を検知して封じ込めたと発表しました。侵入では限定的な範囲の内部データセットと認証情報への不正アクセスが発生した一方、公開されているモデル、データセット、Spaces、公開パッケージに改ざんの痕跡は確認されていないとしています。
ソフトウェア保護の観点から見ると、Quarkslabはその含意は明確だと指摘します。アンチリバース対策は、もはや制御フローグラフを読む人間の解析者を単に妨げるためだけに設計されていてはならないということです。
それは同時に、パッチをコンパイルし、スクリプトを書き、エミュレータを呼び出し、ファイルシステム上の痕跡を調べ、プロセスを計装し、絶えず反復を続けられる自律型エージェントに対しても耐性を持たなければなりません。
LLM支援によるリバースエンジニアリング
静的な難読化は、コードを読み解くコストを引き上げ、攻撃者を実行時の観察へと向かわせる点で、依然として有用です。
しかし、エージェントがバイナリを実行してデコーダを特定し出力をダンプできるのであれば、静的保護だけで埋め込まれた秘密情報を守り切れる可能性は低いといえます。
Quarkslabは、秘密情報を「実行の背後」に置くこと、つまり平文は静的なコードやデータの単純なリフティングによって復元できるのではなく、実行時の計算を通じてのみ得られるようにすべきだと推奨しています。
Dictionaries& Encyclopedias
さらに同社は、エミュレータ、デバッガ、計装フレームワーク、権限昇格プロセスといった敵対的な環境を識別するRASP(Runtime Application Self-Protection)シグナルの導入も推奨しています。
ここで重要な設計上の選択となるのが、そうしたシグナルをどう使うかです。if (is_emulated()) return 0;のような目に見える分岐は、分かりやすい迂回の標的を生み出してしまいます。
そうではなく、環境の測定結果が暗号鍵素材、データ変換、不透明述語の値、ディスパッチャの状態に影響を与えるようにすべきです。
解析環境が必要な状態を再現できなかった場合、どのアンチ解析チェックが作動したのかを露呈させることなく、復号結果が無効な出力になるようにすべきだとしています。
Quarkslabの研究者らによれば、最も注目すべき提言は意図的なクラッシュを避けるべきだという点です。クラッシュは解析者に有用なオラクルを与えてしまい、保護機構が作動したことを明らかにして、迂回すべき箇所や条件を絞り込む手掛かりを与えてしまいます。
もっともらしく整った、しかし誤った答えの方が戦略的な価値は高くなります。自動化されたエージェントがその答えを受け入れ、自信を持って記録した上で、解析そのものを終了させてしまう可能性があるためです。
同社は、根底の作業が未完成、あるいは捏造されたものであっても、エージェントの報告書は洗練されたものになり得ることを確認しました。一部のセッションでは、生成された「エミュレーション」スクリプトが、実際にはエミュレーションを実装せず、既知のフラグをそのまま埋め込んでいるだけのケースもありました。
他のエージェントは簡略化された式のみを解いて制御フローを無視したり、類似タスクの答えを流用したりしていました。したがって、正しい出力が得られたからといって、報告された抽出手法が妥当であるとは必ずしも言えません。
Quarkslabの結論は抑制の効いたものです。LLMはリバースエンジニアリングのスループットを高め、ツール利用を大規模に自動化できる一方で、難読化が持つ防御上の価値を消し去るわけではないとしています。
最も強固な保護は、静的な複雑性、多様かつ隠された実行時センサー、環境に紐付いた秘密情報の導出、そして観測不能な失敗挙動を組み合わせたものです。
目指すべきは単に解析を遅くすることではなく、攻撃者の実行環境が説得力のある答えを生成しながらも、それを検証できない状態を作り出すことにあります。
★ 削減すべきセキュリティツールはどれか?1ページで採点 – 「継承されたセキュリティスタック」ガイドをダウンロード
翻訳元: https://gbhackers.com/llm-assisted-reverse-engineering/
