mcpField
E
entry-point-analyzer

entry-point-analyzer

github.com/trailofbitsセキュリティ7.9k5.8k 回インストール今日更新
リポジトリ

entry-point-analyzer について

entry-point-analyzerは、スマートコントラクト監査向けのスキルです。外部から呼び出せる状態変更関数を洗い出し、アクセス制御を分類します。複数言語に対応し、SolidityではSlitherを利用でき、手動分析にも切り替えられます。

主な機能

  1. 01状態変更エントリーポイントの特定
  2. 02アクセス制限の分類
  3. 03複数のコントラクト言語に対応
  4. 04Slitherまたは手動での確認
  5. 05構造化Markdownレポートの生成

活用シーン

  1. 01監査開始時の攻撃面の把握
  2. 02コントラクトの特権操作の確認
  3. 03関数間のアクセス制御の追跡

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/trailofbits/skills --skill entry-point-analyzer

インストール後、Claude Code で/entry-point-analyzerを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
assets/
trail-of-bits-mark.svg
references/
cosmwasm.md
move-aptos.md
move-sui.md
solana.md
solidity.md
ton.md
vyper.md

詳細

エントリーポイント分析

スマートコントラクトのコードベースで、セキュリティ監査の指針となる、すべての状態を変更するエントリーポイントを体系的に特定します。

Codex での実行

利用可能なファイル読み取り、検索、シェルのツールを使用してください。同梱されているリファレンスへのリンクは、監査対象のリポジトリではなく、この SKILL.md を基準に解決してください。Slither は任意です。利用できない場合や失敗した場合は、手動で調査してください。読み取れないソースファイルやリファレンスファイルは、カバレッジのギャップとして報告してください。実行時の権限はワークスペースに基づきます。

使用するタイミング

次の場合にこのスキルを使用します。

  • スマートコントラクトのセキュリティ監査を開始し、攻撃対象領域を把握するとき
  • エントリーポイント、外部関数、監査フローの特定を依頼されたとき
  • コードベース全体のアクセス制御パターンを分析するとき
  • 特権操作やロール制限付き関数を特定するとき
  • どの関数がコントラクトの状態を変更できるか把握するとき

使用しないタイミング

次の用途には、このスキルを使用しないでください。

  • 脆弱性の検出(audit-context-building または domain-specific-audits を使用してください)
  • エクスプロイトの POC の作成(solidity-poc-builder を使用してください)
  • コード品質やガス最適化の分析
  • スマートコントラクト以外のコードベース
  • 読み取り専用関数の分析(このスキルでは対象外です)

対象範囲:状態を変更する関数のみ

このスキルでは、状態を変更できる関数のみを対象とします。以下は対象外です。

言語対象外のパターン
Solidityview、pure 関数
Vyper@view、@pure 関数
Solanamut アカウント参照を含まない関数
Move読み取り専用の関数本体。可視性だけでは変更可能かどうかを判断できません
TONget メソッド(FunC)、読み取り専用レシーバー(Tact)
CosmWasmquery エントリーポイントとそのハンドラー

entry がなくても、状態を変更する Move の public fun は含めてください。Aptos のトランザクションスクリプトや Sui のプログラマブルトランザクションブロックから呼び出せるためです。必要に応じて呼び出し先をたどって状態への影響を判断し、署名者、ケイパビリティ、オブジェクト所有権の要件は、可視性とは別に記録してください。

読み取り専用関数を対象外とする理由: これらの関数は、資金の損失や状態の破損を直接引き起こすことはできません。情報を漏えいさせる可能性はありますが、監査では状態を変更できる関数を主に対象とします。

ワークフロー

  1. 言語を検出する - ファイル拡張子と構文から、コントラクトの言語を特定します
  2. ツールを使用する(利用可能な場合) - Solidity の場合、Slither が利用可能か確認し、利用します
  3. コントラクトを特定する - すべてのコントラクト/モジュールファイルを検索します(指定がある場合はディレクトリフィルターを適用します)
  4. エントリーポイントを抽出する - 各ファイルを解析し、外部から呼び出せる、状態を変更する関数を抽出します
  5. アクセスを分類する - 各関数をアクセスレベル別に分類します
  6. レポートを作成する - 構造化された Markdown レポートを出力します

Slither の統合(Solidity)

Solidity のコードベースでは、Slither を使ってエントリーポイントを自動的に抽出できます。手動で分析する前に、次の手順を実行してください。

1. Slither が利用可能か確認する
which slither
2. Slither が検出されたら、エントリーポイントのプリンターを実行する
slither . --print entry-points

次の情報を含む、状態を変更するすべてのエントリーポイントの表が出力されます。

  • コントラクト名
  • 関数名
  • 可視性
  • 適用されている修飾子
3. Slither の出力を分析の基礎として使用する
  • Slither の出力表を解析し、分析結果に反映します
  • アクセス制御の分類は、手動調査と照合します
  • Slither では一部のパターン(コールバック、動的なアクセス制御など)を見落とすことがあるため、手動レビューで補完します
  • Slither が失敗した場合(コンパイルエラー、未対応機能など)は、手動分析に切り替えます
4. Slither が利用できない場合

which slither が何も返さない場合は、言語別のリファレンスファイルを使用して手動で分析してください。

言語の検出

拡張子言語リファレンス
.solSolidityreferences/solidity.md
.vyVyperreferences/vyper.md
.rs + solana-program を含む Cargo.tomlSolana(Rust)references/solana.md
.move + edition を含む Move.tomlMove(Sui)references/move-sui.md
.move + Aptos を含む Move.tomlMove(Aptos)references/move-aptos.md
.fc、.func、.tactTON(FunC/Tact)references/ton.md
.rs + cosmwasm-std を含む Cargo.tomlCosmWasmreferences/cosmwasm.md

検出した言語に応じて、分析の前に適切なリファレンスファイルを読み込んでください。

アクセス分類

状態を変更する各エントリポイントを、次のいずれかに分類してください。

1. パブリック(制限なし)

呼び出し元の識別情報やロールによる制限がない関数です。ポーズフラグなどの状態条件は別途記録してください。これらは関数を特権関数にするものではありません。

2. ロール制限あり

特定のロールに制限された関数です。検出する一般的なパターン:

  • 明示的なロール名:admin、owner、governance、guardian、operator、manager、minter、pauser、keeper、relayer、lender、borrower
  • ロール確認パターン:onlyRole、hasRole、require(msg.sender == X)、assert_owner、#[access_control]
  • ロールが曖昧な場合は、制限パターンを記載して "制限あり(要確認)" としてください。
3. コントラクト限定(内部統合ポイント)

強制される呼び出し元制限により、他のコントラクトからの呼び出しに限定される関数です。実際の確認処理と、許可される呼び出し元の識別情報または由来を示してください。 コールバック名、実装インターフェース、または想定される統合先は、アクセス制御ではありません。

  • 呼び出し元の確認がないコールバックは パブリック(制限なし) です。
  • 設定済みアドレスとの照合がある場合、その識別情報が未解決であれば 制限あり(要確認) としてください。そのアドレスが統合コントラクトであると確認できる場合は コントラクト限定 としてください。
  • msg.sender != tx.origin は呼び出し経路の条件を示すものであり、信頼できるプロトコルによる認証ではありません。信頼できる呼び出し元を推測せず、その条件を記録してください。

出力形式

次の構成で Markdown レポートを生成してください。

# Entry Point Analysis: [Project Name]

**Analyzed**: [timestamp]
**Scope**: [directories analyzed or "full codebase"]
**Languages**: [detected languages]
**Focus**: State-changing functions only (view/pure excluded)

## Summary

| Category | Count |
|----------|-------|
| Public (Unrestricted) | X |
| Role-Restricted | X |
| Restricted (Review Required) | X |
| Contract-Only | X |
| **Total** | **X** |

---

## Public Entry Points (Unrestricted)

State-changing functions callable by anyone—prioritize for attack surface analysis.

| Function | File | Notes |
|----------|------|-------|
| `functionName(params)` | `path/to/file.sol:L42` | Brief note if relevant |

---

## Role-Restricted Entry Points

### Admin / Owner
| Function | File | Restriction |
|----------|------|-------------|
| `setFee(uint256)` | `Config.sol:L15` | `onlyOwner` |

### Governance
| Function | File | Restriction |
|----------|------|-------------|

### Guardian / Pauser
| Function | File | Restriction |
|----------|------|-------------|

### Other Roles
| Function | File | Restriction | Role |
|----------|------|-------------|------|

---

## Restricted (Review Required)

Functions with access control patterns that need manual verification.

| Function | File | Pattern | Why Review |
|----------|------|---------|------------|
| `execute(bytes)` | `Executor.sol:L88` | `require(trusted[msg.sender])` | Dynamic trust list |

---

## Contract-Only (Internal Integration Points)

Functions only callable by other contracts—useful for understanding trust boundaries.

| Function | File | Expected Caller |
|----------|------|-----------------|
| `onFlashLoan(...)` | `Vault.sol:L200` | Flash loan provider |

---

## Files Analyzed

- `path/to/file1.sol` (X state-changing entry points)
- `path/to/file2.sol` (X state-changing entry points)

フィルタリング

ユーザーがディレクトリフィルターを指定した場合:

  • そのパス内のファイルのみを分析する
  • レポートのヘッダーにフィルターを記載する
  • 例:「src/core/ のみを分析する」→ スコープ = src/core/

分析ガイドライン

  1. 徹底する:ファイルを飛ばさないでください。状態を変更する、外部から呼び出し可能な関数はすべて対象です。
  2. 慎重に判断する:アクセスレベルが不明な場合は、誤分類せず要確認としてフラグを付けてください。
  3. 読み取り専用は除外する:view、pure および同等の読み取り専用関数は除外してください。
  4. 継承を記載する:関数のアクセス制御が親コントラクトに由来する場合は、その旨を記載してください。
  5. 修飾子を追跡する:各関数に適用される、アクセス関連の修飾子/デコレーターをすべて列挙してください。
  6. パターンを特定する:次のような一般的なパターンを探してください。
    • 初期化関数(最初の呼び出し時に制限がないことが多い)
    • アップグレード関数(高い権限が必要)
    • 緊急停止/ポーズ関数(ガーディアンレベル)
    • 手数料/パラメーター設定関数(管理者レベル)
    • トークンの転送と承認(パブリックであることが多い)

プロトコルの種類別、一般的なロールパターン

プロトコルの種類一般的なロール
DEXowner、feeManager、pairCreator
レンディングadmin、guardian、liquidator、oracle
ガバナンスproposer、executor、canceller、timelock
NFTminter、admin、royaltyReceiver
ブリッジrelayer、guardian、validator、operator
Vault/イールドstrategist、keeper、harvester、manager

却下すべき安易な判断

エントリーポイントを分析するときは、次のような近道を避けてください。

  • 「この関数は標準的に見える」→ それでも分類してください。標準的な関数でも、アクセス制御が標準的とは限りません
  • 「修飾子の名前は明確だ」→ 修飾子の実際の実装を確認してください
  • 「これは明らかに管理者専用だ」→ 実際の制限をたどってください。「明らか」という思い込みでは、微妙な回避策を見落とします
  • 「コールバックは省略する」→ コールバックは信頼境界を定義します。必ず含めてください
  • 「状態の変更はわずかだ」→ 状態の変更はどれも悪用される可能性があります。ビュー関数以外のすべての関数を含めてください

エラー処理

ファイルを解析できない場合:

  1. レポートの「分析に関する警告」に記載します
  2. 残りのファイルの分析を続けます
  3. 解析できないファイルは手動で確認するよう提案します

コメント