論文「Prompt to Pwn: Automated Exploit Generation for Smart Contracts」の技術的サマリー

本論文は、スマートコントラクトの脆弱性検出だけでなく、大規模言語モデル（LLM）を用いた自動エクスプロイト生成（AEG: Automated Exploit Generation） の能力と限界を体系的に評価した初の研究です。著者らは、LLM が生成した攻撃コードが実際にコンパイルされ、実行環境で脆弱性を突けるかどうかを検証するフレームワーク「ReX」を提案し、その実証実験を通じて、現在の最先端 LLM の攻撃能力と防御策のあり方を明らかにしました。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細にまとめます。

1. 問題定義と背景

• スマートコントラクトの脆弱性: スマートコントラクトは一度デプロイされると修正が困難であり、小さな欠陥でも多額の被害（例：Bybit のウォレットハッキング事件など）につながる。
• 既存研究の限界: 従来の研究は LLM を用いた「脆弱性検出」に焦点が当てられていた。しかし、「検出」は弱点を特定するだけであり、「エクスプロイト生成」は実行可能な攻撃コードを合成し、その有効性を検証する必要があるため、全く異なるタスクである。
• 未解決の課題: 攻撃者が LLM を利用して、初心者でも実用的な攻撃（スクリプトキディ化）を容易に行えるようになる可能性について、体系的な評価が欠けていた。

2. 手法：ReX フレームワーク

著者らは、LLM によるエクスプロイト合成を Foundry（Solidity のテスト・デプロイツールチェーン）と連携させ、エンドツーエンドの生成・コンパイル・実行・検証を行うフレームワーク ReX を構築しました。

• ワークフロー:

  1. 前処理: 脆弱性を含むコントラクトのノイズ除去。
  2. スクリプト生成: LLM に脆弱性のあるコントラクトとプロンプトを与え、エクスプロイト用コントラクトと、その有効性を検証するテストスクリプト（Foundry 形式）を生成させる。
  3. 自動修正（オプション）: 生成されたコードの構文エラー（EIP-55 アドレスチェックサム、payable キャストの欠落など）を自動修正。
  4. コンパイルとテスト: Foundry を用いてローカル環境でコンパイル・実行し、脆弱性が突けるか（Safety Invariant の違反）を検証。
  5. 反復フィードバックループ: 失敗した場合、エラーメッセージを LLM に返却し、修正・再生成を最大 4 回まで繰り返す。

• 評価データセット:

  • SmartBugs-Curated: 制御されたベンチマーク用データセット。
  • Web3-AEG: 著者らが独自に構築した、2021〜2025 年の実際のハッキング事例（38 件以上）に基づくデータセット。専門家による PoC（Proof of Concept）が既に存在する実世界のコントラクトを含む。

• 評価対象モデル: GPT-4.1, Gemini 2.5 Pro, Claude Opus 4, DeepSeek-R1, Qwen3-Plus の 5 種類の最先端 LLM。

3. 主要な貢献

1. 初の体系的実証研究: 統一されたベンチマークと検証パイプライン下で、LLM によるスマートコントラクトの AEG 能力を評価した初の研究。
2. ReX フレームワークの公開: LLM と Foundry を連携させた自動エクスプロイト生成・検証パイプラインの実装と、実世界および合成データを含む公開データセットの提供。
3. 性能と限界の明確化: 現在の LLM が単一コントラクトの脆弱性に対しては有効な PoC を生成できるが、複雑なクロスコントラクト攻撃や経済的な攻撃連鎖には弱いことを実証。
4. 防御策の提言: LLM 特有の弱点（パターンマッチング依存、構文理解の限界）を利用した防御技術（ロジック分割、デコイ脆弱性の導入など）の提案と評価。

4. 実験結果と知見

4.1 LLM の AEG 性能

• 全体成功率: 5 モデル中、Gemini 2.5 Pro が最も高い成功率（67.3%）を記録。次いで GPT-4.1（58.1%）、Claude Opus 4（63.3%）。DeepSeek-R1 と Qwen3-Plus は低かった。
• 脆弱性タイプによる差:
  • 高い成功率: 算術オーバーフロー、アクセス制御、DoS などは比較的容易に生成可能。
  • 低い成功率: 再帰性（Reentrancy）やクロスコントラクトにまたがる攻撃は困難。
• 実世界データ（Web3-AEG）での結果:
  • Gemini 2.5 Pro は 4 つの実際のハッキング事例で有効な PoC を生成。
  • 単一コントラクト vs クロスコントラクト: LLM は単一コントラクト内の論理に基づく攻撃は得意だが、複数のコントラクト間の状態不整合を利用した複雑な攻撃チェーン（例：Flashloan を用いた多段階攻撃）の構築には苦戦し、専門家レベルの攻撃戦略には至らなかった。

4.2 成功に影響する要因（RQ2）

• モデル能力が最重要: 攻撃成功の主な決定要因は「LLM 自体のコード生成・推論能力」であり、コントラクトのサイズ（行数）や構造的複雑さとの相関は弱い。
• 脆弱性タイプ: 局所的でパターンが明確な脆弱性（算術エラー等）は生成されやすく、グローバルな状態やトランザクション順序に依存する脆弱性は難しい。
• プロンプトエンジニアリング: 構造化されたプロンプトや反復フィードバックループは成功率を向上させるが、モデルの根本的な推論能力を補うものではなく、限界がある。

4.3 防御策の有効性（RQ3）

• 個別防御の限界: 単一の防御策（複雑化、ロジック分割など）のみでは、LLM の攻撃成功率を大幅に低下させることは困難。
• 複合防御の効果: 複数の防御策（ロジック分割、構造的複雑化、デコイ脆弱性の導入、低レベル構文の使用）を組み合わせることで、LLM の攻撃成功率を大幅に低下させることが確認された（例：Gemini 2.5 Pro で 87.5% → 43.8% へ低下）。
• 例外: 「悪い乱数（Bad Randomness）」や「時間操作（Time Manipulation）」の脆弱性には、防御策が効きにくい傾向が見られた。

5. 意義と結論

• 脅威の現実化: 最先端 LLM は、実世界のスマートコントラクトに対して、専門家による PoC と同等の単一コントラクト攻撃を自動生成できる能力を持っている。これは「スクリプトキディ」による攻撃のハードル低下を意味する。
• 防御のパラダイムシフト: 従来の「コードの複雑化（難読化）」よりも、LLM の推論プロセスを混乱させる「構造的・意味的な複雑化（ロジックの分割、非標準構文の使用、デコイの導入）」が有効であることが示された。
• 限界と将来: 現在の LLM は経済的な文脈（MEV、オラクル操作、クロスチェーン連携）を考慮した高度な攻撃には至らない。しかし、防御策は「バグの修正」ではなく「LLM による分析コストの増大」を目指すものであり、根本的な脆弱性の修正と併せて実施する必要がある。

本論文は、LLM 時代におけるスマートコントラクトセキュリティの新たな脅威と、それに対する具体的な防御戦略の指針を提供する重要な研究です。