entry-point-analyzer

Files (10)

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

SKILL.md (first lines)

# Entry Point Analyzer

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

## Execution in Codex

Use the available file-reading, search, and shell tools. Resolve bundled reference
links relative to this SKILL.md, not the audited repository. Slither is optional;
use manual inspection if it is unavailable or fails. Report unreadable source or
reference files as coverage gaps. Runtime permissions come from the workspace.

## 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 | Read-only function bodies; visibility alone does not establish mutability |
| TON | `get` methods (FunC), read-only receivers (Tact) |
| CosmWasm | `query` entry point and its handlers |

Include state-changing Move `public fun` even without `entry`: Aptos transaction
scripts and Sui programmable transaction blocks can reach them. Trace callees when
needed to determine state effects, and record signer, capability, and object
ownership requirements separately from visibility.

**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

1. **Detect Language** - Identify contract language(s) from file extensions and syntax
2. **Use Tooling (if available)** - For Solidity, check if Slither is available and use it
3. **Locate Contracts** - Find all contract/module files (apply directory filter if specified)
4. **Extract Entry Points** - Parse each file for externally callable, state-changing functions
5. **Classify Access** - Categorize each function by access level
6. **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

```bash
which slither
```

### 2. If Slither is Detected, Run Entry Points Printer

```bash
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 | [references/solidity.md](references/solidity.md) |
| `.vy` | Vyper | [references/vyper.md](references/vyper.md) |
| `.rs` + `Cargo.toml` with `solana-program` | Solana (Rust) | [references/solana.md](references/solana.md) |
| `.move` + `Move.toml` with `edition` | Move (Sui) | [references/move-sui.md](references/move-sui.md) |
| `.move` + `Move.toml` with `Aptos` | Move (Aptos) | [references/move-aptos.md](references/move-aptos.md) |
| `.fc`, `.func`, `.tact` | TON (FunC/Tact) | [references/ton.md](references/ton.md) |
| `.rs` + `Cargo.toml` with `cosmwasm-std` | CosmWasm | [references/cosmwasm.md](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 with no caller-identity or role restriction. Record state conditions such as pause
flags separately; they do not make a function privileged.

### 2. 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

From trailofbits/skills, CC-BY-SA-4.0.

More from trailofbits/skills