Entry Point Analyzer

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

使用すべき場合

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

• スマートコントラクトのセキュリティ監査を開始して攻撃面をマッピングする
• エントリーポイント、外部関数、または監査フローを見つけるよう求められた場合
• コードベース全体のアクセス制御パターンを分析する
• 特権操作とロール制限関数を特定する
• どの関数がコントラクト状態を変更できるかを理解する

使用すべきでない場合

次の場合はこのスキルを使用しないでください:

• 脆弱性検出(audit-context-building または domain-specific-audits を使用)
• エクスプロイト POC の作成(solidity-poc-builder を使用)
• コード品質またはガス最適化分析
• スマートコントラクト以外のコードベース
• read-only関数の分析(このスキルでは除外します)

スコープ: 状態変更関数のみ

このスキルは状態を変更できる関数に限定して使用します。除外対象:

言語	除外パターン
Solidity	view、pure 関数
Vyper	@view、@pure 関数
Solana	mut アカウント参照のない関数
Move	エントリー以外の public fun(モジュール呼び出しのみ)
TON	get メソッド(FunC)、read-only レシーバー(Tact)
CosmWasm	query エントリーポイントとそのハンドラ

read-only関数を除外する理由は何か? これらは直接的に資金損失や状態破損を引き起こすことができません。情報漏洩の可能性はありますが、主な監査焦点は状態を変更できる関数です。

ワークフロー

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

Slither統合(Solidity)

Solidityコードベースの場合、Slitherはエントリーポイントを自動的に抽出できます。手動分析の前に:

1. Slitherが利用可能かチェック

which slither

2. Slitherが検出された場合、エントリーポイントプリンターを実行

slither . --print entry-points

以下を含むすべての状態変更エントリーポイントのテーブルを出力します:

• コントラクト名
• 関数名
• Visibility
• 適用されたモディファイア

3. Slither出力を基礎として使用

• Slither出力テーブルを解析して分析をサポート
• アクセス制御分類のために手動検査と相互参照
• Slitherがいくつかのパターン(コールバック、動的アクセス制御)を見逃す可能性があります—手動レビューで補完してください
• Slitherが失敗した場合(コンパイルエラー、サポートされていない機能)、手動分析にフォールバック

4. Slitherが利用できない場合

which slither が何も返さない場合は、言語固有の参照ファイルを使用した手動分析を進めます。

言語検出

拡張子	言語	参照
.sol	Solidity	{baseDir}/references/solidity.md
.vy	Vyper	{baseDir}/references/vyper.md
.rs + solana-program を含む Cargo.toml	Solana (Rust)	{baseDir}/references/solana.md
.move + edition を含む Move.toml	{baseDir}/references/move-sui.md
.move + Aptos を含む Move.toml	{baseDir}/references/move-aptos.md
.fc、.func、.tact	TON (FunC/Tact)	{baseDir}/references/ton.md
.rs + cosmwasm-std を含む Cargo.toml	CosmWasm	{baseDir}/references/cosmwasm.md

分析前に、検出された言語に基づいて適切な参照ファイルを読み込みます。

アクセス分類

各状態変更エントリーポイントを次のいずれかのカテゴリに分類します:

1. Public (無制限)

制限なく誰でも呼び出し可能な関数。

2. ロール制限

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

• 明示的なロール名: admin、owner、governance、guardian、operator、manager、minter、pauser、keeper、relayer、lender、borrower
• ロール確認パターン: onlyRole、hasRole、require(msg.sender == X)、assert_owner、#[access_control]
• ロールが不明確な場合は、"Restricted (review required)" として制限パターンを記載してフラグ

3. Contract-Only (内部統合ポイント)

他のコントラクトによってのみ呼び出し可能で、EOAからは呼び出せない関数。インジケーター:

• コールバック: onERC721Received、uniswapV3SwapCallback、flashLoanCallback
• contract-caller チェック付きのインターフェース実装
• tx.origin == msg.sender の場合にリバートする関数
• クロスコントラクトフック

出力形式

次の構造でMarkdownレポートを生成します:

# Entry Point Analysis: [Project Name]

**分析日時**: [timestamp]
**スコープ**: [分析したディレクトリまたは "full codebase"]
**言語**: [検出された言語]
**焦点**: 状態変更関数のみ(view/pure は除外)

## Summary

| カテゴリ | 件数 |
|---------|------|
| Public (無制限) | X |
| ロール制限 | X |
| 制限(レビュー必須) | X |
| Contract-Only | X |
| **合計** | **X** |

---

## Public Entry Points (無制限)

誰でも呼び出し可能な状態変更関数—攻撃面分析を優先します。

| 関数 | ファイル | 備考 |
|-----|---------|------|
| `functionName(params)` | `path/to/file.sol:L42` | 関連する場合は簡潔なメモ |

---

## Role-Restricted Entry Points

### Admin / Owner
| 関数 | ファイル | 制限 |
|-----|---------|------|
| `setFee(uint256)` | `Config.sol:L15` | `onlyOwner` |

### Governance
| 関数 | ファイル | 制限 |
|-----|---------|------|

### Guardian / Pauser
| 関数 | ファイル | 制限 |
|-----|---------|------|

### その他のロール
| 関数 | ファイル | 制限 | ロール |
|-----|---------|------|--------|

---

## 制限(レビュー必須)

手動検証が必要なアクセス制御パターンを持つ関数。

| 関数 | ファイル | パターン | レビューが必要な理由 |
|-----|---------|---------|-------------------|
| `execute(bytes)` | `Executor.sol:L88` | `require(trusted[msg.sender])` | 動的信頼リスト |

---

## Contract-Only (内部統合ポイント)

他のコントラクトによってのみ呼び出し可能な関数—信頼境界を理解するために有用。

| 関数 | ファイル | 予想される呼び出し元 |
|-----|---------|-------------------|
| `onFlashLoan(...)` | `Vault.sol:L200` | Flash loan プロバイダー |

---

## 分析したファイル

- `path/to/file1.sol` (X 個の状態変更エントリーポイント)
- `path/to/file2.sol` (X 個の状態変更エントリーポイント)

フィルタリング

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

• そのパス内のファイルのみを分析
• レポートヘッダーでフィルターを記載
• 例: "分析対象は src/core/ のみ" → scope = src/core/

分析ガイドライン

1. 徹底的に実施: ファイルをスキップしない。すべての状態変更外部呼び出し可能関数が重要です。
2. 保守的に: アクセスレベルについて不確かな場合は、誤分類するのではなくレビューのためにフラグを立てます。
3. read-onlyをスキップ: view、pure、および同等のread-only関数を除外します。
4. 継承を記載: 関数のアクセス制御が親コントラクトから来ている場合はこれを記載します。
5. モディファイアを追跡: 各関数に適用されるすべてのアクセス関連モディファイア/デコレーターをリストします。
6. パターンを特定: 以下のような一般的なパターンを探します:
   • Initializer関数(初回呼び出しで無制限の場合が多い)
   • Upgrade関数(高い特権)
   • 緊急/一時停止関数(guardian レベル)
   • 手数料/パラメーター設定関数(admin レベル)
   • トークン転送と承認(多くの場合 public)

プロトコルタイプ別の一般的なロールパターン

プロトコルタイプ	一般的なロール
DEX	owner、feeManager、pairCreator
Lending	admin、guardian、liquidator、oracle
Governance	proposer、executor、canceller、timelock
NFT	minter、admin、royaltyReceiver
Bridge	relayer、guardian、validator、operator
Vault/Yield	strategist、keeper、harvester、manager

拒否すべき正当化

エントリーポイントを分析する際、これらのショートカットを拒否します:

• "この関数は標準的に見える" → それでも分類する;標準的な関数は非標準的なアクセス制御を持つことができます
• "モディファイア名は明確である" → モディファイアの実装を検証する
• "これは明らかに admin-only である" → 実装の制限を追跡する;「明らかな」仮定は微妙なバイパスを見逃します
• "コールバックはスキップしよう" → コールバックは信頼境界を定義します;常にそれらを含めます
• "それほど状態を変更しない" → どの状態変更も悪用される可能性があります;すべての非-view関数を含めます

エラーハンドリング

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

1. "Analysis Warnings" 下のレポートに記載
2. 残りのファイルを続行
3. 解析不可能なファイルの手動レビューを提案