audit-recon

# Audit Reconnaissance ## Phase Overview Recon is the first phase of a security audit. The goal is to build a mental model of the system before diving into code. Spend 10-20% of total audit time here. ## Step 1: Automated Tools First Run automated scanners to identify low-hanging fruit and build familiarity: ```bash # Slither — static analysis slither . --filter-paths "test|script|node_modules" \ --print human-summary \ --print contract-summary # Aderyn — Solidity-specific linter aderyn . --exclude test/ --output aderyn-report.md # Solidity Metrics — complexity and SLOC solidity-metrics src/ # Dependency tree forge tree ``` ### Slither Detectors to Focus On | Detector | Severity | What It Finds | |----------|----------|---------------| | `reentrancy-eth` | High | ETH reentrancy | | `reentrancy-no-eth` | Medium | State reentrancy | | `unchecked-transfer` | High | Unchecked ERC20 returns | | `arbitrary-send-eth` | High | Uncontrolled ETH transfer | | `suicidal` | High | Unprotected selfdestruct | | `uninitialized-state` | High | Uninitialized variables | | `controlled-delegatecall` | High | User-controlled delegatecall | ### Slither Printers for Recon ```bash # Call graph slither . --print call-graph # Function summary (visibility, modifiers, state changes) slither . --print function-summary # Inheritance graph slither . --print inheritance-graph # Variables read/written per function slither . --print vars-and-auth ``` ## Step 2: Dependency Review ```bash # List all dependencies and versions forge tree # Check for known vulnerabilities # Cross-reference OpenZeppelin version against security advisories # https://github.com/OpenZeppelin/openzeppelin-contracts/security/advisories ``` Key questions: - Are dependencies pinned to specific commits/versions? - Any modified/forked dependencies? - Solidity compiler version — known compiler bugs? ## Step 3: Architecture Mapping Build this map by reading code, starting from entry points: ```markdown ## Contract Map ### Core - Vault.sol (512 SLOC) — main entry point - Inherits: ERC4626, Ownable, ReentrancyGuard, Pausable - External calls: Strategy, Oracle, USDC - State: deposits, withdrawals, share pricing ### Periphery - Strategy.sol (189 SLOC) — yield deployment - External calls: Aave Pool, USDC - Called by: Vault (only) ### Libraries - MathLib.sol (45 SLOC) — fixed-point math - Pure functions, no state ``` ## Step 4: Entry Point Identification Map every `external` and `public` function with their access control: ```markdown ## Entry Points | Contract | Function | Access | State Changes | Risk | |----------|----------|--------|---------------|------| | Vault | deposit(uint256,address) | Anyone | balances, totalSupply | Medium | | Vault | withdraw(uint256,address,address) | Owner/approved | balances, totalSupply | High | | Vault | setStrategy(address) | Owner only | strategy | Critical | | Vault | pause() | Owner only | paused flag | Low | | Strategy | harvest() | Keeper only | deployed amount | Medium | | Strategy | emergencyWithdraw() | Owner only | all state | Critical | ``` ## Step 5: Trust Boundary Mapping ```markdown ## Trust Boundaries ### Fully Trusted - Owner multisig (can change parameters, pause, upgrade strategy) - Timelock controller (executes governance decisions) ### Semi-Trusted - Keeper bot (can trigger harvest, but cannot steal funds) - Oracle feeds (Chainlink — trusted but can go stale) ### Untrusted - End users (deposit/withdraw — fully adversarial) - External protocols (Aave — could be exploited) - Token contracts (USDC — could blacklist) ### Attack Surfaces by Trust Level 1. Untrusted user -> Vault: reentrancy, share manipulation, front-running 2. Stale oracle -> Vault: incorrect valuations, over-borrowing 3. Compromised keeper -> Strategy: timing attacks on harvest 4. External protocol exploit -> Strategy: loss of deployed funds ``` ## Step 6: External Call Mapping Every external call is a potential vulnerability vector: ```markdown ## External Calls | Source | Target | Function | Untrusted? | Risk | |--------|--------|----------|------------|------| | Vault | USDC | transferFrom | No (known) | Low | | Vault | Strategy | deploy | No (owned) | Low | | Strategy | Aave Pool | supply | Semi | Medium | | Strategy | Aave Pool | withdraw | Semi | Medium | | Oracle | Chainlink | latestRoundData | Semi | Medium | ``` ## Step 7: Access Control Enumeration ```bash # Use Slither to enumerate access controls slither . --print vars-and-auth # Manually verify: # 1. Every onlyOwner function is truly admin-only # 2. No function missing access control that modifies state # 3. Initializer functions protected against re-initialization # 4. Constructor sets correct initial values ``` ## Recon Report Template ```markdown # Audit Recon Report — [Protocol Name] ## Summary - **Total SLOC**: X - **Contracts in scope**: Y - **External dependencies**: Z - **Compiler**: solc X.Y.Z ## Architecture Diagram [Mermaid or text diagram] ## Entry Points (sorted by risk) [Table from Step 4] ## External Calls [Table from Step 6] ## Trust Boundaries [From Step 5] ## Automated Tool Findings - Slither: X high, Y medium, Z low (after triage) - Aderyn: X findings ## Initial Leads for Depth Analysis 1. [Finding/area that needs deeper review] 2. [Suspicious pattern identified] 3. [Complex logic requiring manual review] ``` ## Checklist - [ ] Slither run with findings triaged (true/false positive) - [ ] Aderyn run reviewed - [ ] Dependency versions checked against known vulnerabilities - [ ] All entry points mapped with access controls - [ ] External calls enumerated and risk-assessed - [ ] Trust boundaries documented - [ ] Architecture diagram created - [ ] Initial depth-analysis leads identified - [ ] Recon report completed before moving to breadth scan