entry-point-analyzer

仓库: trailofbits/skills
安装量: 946
排名: #1391

安装

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

Entry Point Analyzer

Systematically identify all state-changing entry points in a smart contract codebase to guide security audits.

When to Use

Use this skill when:

Starting a smart contract security audit to map the attack surface Asked to find entry points, external functions, or audit flows Analyzing access control patterns across a codebase Identifying privileged operations and role-restricted functions Building an understanding of which functions can modify contract state When NOT to Use

Do NOT use this skill for:

Vulnerability detection (use audit-context-building or domain-specific-audits) Writing exploit POCs (use solidity-poc-builder) Code quality or gas optimization analysis Non-smart-contract codebases Analyzing read-only functions (this skill excludes them) Scope: State-Changing Functions Only

This skill focuses exclusively on functions that can modify state. Excluded:

Language Excluded Patterns Solidity view, pure functions Vyper @view, @pure functions Solana Functions without mut account references Move Non-entry public fun (module-callable only) TON get methods (FunC), read-only receivers (Tact) CosmWasm query entry point and its handlers

Why exclude read-only functions? They cannot directly cause loss of funds or state corruption. While they may leak information, the primary audit focus is on functions that can change state.

Workflow Detect Language - Identify contract language(s) from file extensions and syntax Use Tooling (if available) - For Solidity, check if Slither is available and use it Locate Contracts - Find all contract/module files (apply directory filter if specified) Extract Entry Points - Parse each file for externally callable, state-changing functions Classify Access - Categorize each function by access level Generate Report - Output structured markdown report Slither Integration (Solidity)

For Solidity codebases, Slither can automatically extract entry points. Before manual analysis:

  1. Check if Slither is Available which slither

  2. If Slither is Detected, Run Entry Points Printer slither . --print entry-points

This outputs a table of all state-changing entry points with:

Contract name Function name Visibility Modifiers applied 3. Use Slither Output as Foundation Parse the Slither output table to populate your analysis Cross-reference with manual inspection for access control classification Slither may miss some patterns (callbacks, dynamic access control)—supplement with manual review If Slither fails (compilation errors, unsupported features), fall back to manual analysis 4. When Slither is NOT Available

If which slither returns nothing, proceed with manual analysis using the language-specific reference files.

Language Detection Extension Language Reference .sol Solidity {baseDir}/references/solidity.md .vy Vyper {baseDir}/references/vyper.md .rs + Cargo.toml with solana-program Solana (Rust) {baseDir}/references/solana.md .move + Move.toml with edition {baseDir}/references/move-sui.md
.move + Move.toml with Aptos {baseDir}/references/move-aptos.md
.fc, .func, .tact TON (FunC/Tact) {baseDir}/references/ton.md .rs + Cargo.toml with cosmwasm-std CosmWasm {baseDir}/references/cosmwasm.md

Load the appropriate reference file(s) based on detected language before analysis.

Access Classification

Classify each state-changing entry point into one of these categories:

  1. Public (Unrestricted)

Functions callable by anyone without restrictions.

  1. Role-Restricted

Functions limited to specific roles. Common patterns to detect:

Explicit role names: admin, owner, governance, guardian, operator, manager, minter, pauser, keeper, relayer, lender, borrower Role-checking patterns: onlyRole, hasRole, require(msg.sender == X), assert_owner, #[access_control] When role is ambiguous, flag as "Restricted (review required)" with the restriction pattern noted 3. Contract-Only (Internal Integration Points)

Functions callable only by other contracts, not by EOAs. Indicators:

Callbacks: onERC721Received, uniswapV3SwapCallback, flashLoanCallback Interface implementations with contract-caller checks Functions that revert if tx.origin == msg.sender Cross-contract hooks Output Format

Generate a markdown report with this structure:

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)

Filtering

When user specifies a directory filter:

Only analyze files within that path Note the filter in the report header Example: "Analyze only src/core/" → scope = src/core/ Analysis Guidelines Be thorough: Don't skip files. Every state-changing externally callable function matters. Be conservative: When uncertain about access level, flag for review rather than miscategorize. Skip read-only: Exclude view, pure, and equivalent read-only functions. Note inheritance: If a function's access control comes from a parent contract, note this. Track modifiers: List all access-related modifiers/decorators applied to each function. Identify patterns: Look for common patterns like: Initializer functions (often unrestricted on first call) Upgrade functions (high-privilege) Emergency/pause functions (guardian-level) Fee/parameter setters (admin-level) Token transfers and approvals (often public) Common Role Patterns by Protocol Type Protocol Type Common Roles 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 Rationalizations to Reject

When analyzing entry points, reject these shortcuts:

"This function looks standard" → Still classify it; standard functions can have non-standard access control "The modifier name is clear" → Verify the modifier's actual implementation "This is obviously admin-only" → Trace the actual restriction; "obvious" assumptions miss subtle bypasses "I'll skip the callbacks" → Callbacks define trust boundaries; always include them "It doesn't modify much state" → Any state change can be exploited; include all non-view functions Error Handling

If a file cannot be parsed:

Note it in the report under "Analysis Warnings" Continue with remaining files Suggest manual review for unparsable files

← 返回排行榜