poc

# PoC Generation & Validation **Input**: $ARGUMENTS (attack scenario file path) --- # Part 1: PoC Code Generation ## Core Principle ``` 1 Attack Scenario = 1 PoC Code ``` ## Workflow ### 1. Read Attack Scenario ``` Read(".vigilo/findings/{severity}/{auditor}/{Severity}-{id}-{title}.md") ``` Example: `.vigilo/findings/high/logic/H-01-donation-attack-inflated-collateral.md` Extract: Finding ID, Bug Class, Preconditions, Attack Steps, Impact, Vulnerable Code ### 2. Generate PoC **File**: `test/poc/{Severity}-{id}-{title}.t.sol` Example: `test/poc/H-01-donation-attack-inflated-collateral.t.sol` **NOTE**: PoC code goes in `test/poc/` (project root), NOT in `.vigilo/` folder. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; import "forge-std/Test.sol"; import "forge-std/console2.sol"; contract PoC_{ID}_{BugClass} is Test { // State variables, actors function setUp() public { // Reproduce preconditions } function test_Exploit_{ID}() public { // 1. Log initial state // 2. Execute attack steps // 3. Log final state // 4. Assert impact } } ``` ### 3. PoC Checklist - [ ] setUp(): Fully reproduce preconditions - [ ] Actor labels: Use `makeAddr()` for all addresses - [ ] console2.log: Output before/after attack state - [ ] Attack steps: Follow scenario order exactly - [ ] **Impact assertion: Directly prove scenario's claimed impact** (required) ### 4. Bug Class Patterns Detailed templates: [references/poc-templates.md](references/poc-templates.md) --- # Part 2: Foundry Validation ## Core Principle ``` Test Pass ≠ Vulnerability Validated ``` **Goal**: Verify that the Attack Scenario's claimed Impact actually occurs ## Workflow ### 1. Execute Test ```bash forge test --match-test "test_Exploit_{ID}" -vvv ``` | Verbosity | Use Case | |-----------|----------| | `-vvv` | Default recommended | | `-vvvvv` | Detailed debugging | ### 2. Analyze Results | Result | Meaning | Action | |--------|---------|--------| | PASS + Impact proven | Vulnerability valid | → Complete | | PASS + Impact unclear | Insufficient verification | → Strengthen assertions | | FAIL | Issue occurred | → Fix PoC (max 3 attempts) | ### 3. Impact Verification ``` Scenario Impact → Assertion Mapping ───────────────────────────────────── "Vault drain" → assertGt(attackerAfter, attackerBefore) "Collateral loss" → assertLt(userAfter, userBefore) "Admin bypass" → assertTrue(attacker.hasRole(ADMIN)) ``` ### 4. Modification Workflow ``` Test failure or Impact mismatch ↓ Fix PoC (max 3 attempts) ↓ After 3 failures → Review Attack Scenario ↓ If scenario needs update → Reverse-modify ``` **If PoC validation differs from scenario, update Attack Scenario**: - Expected profit ≠ actual profit → Update Impact numbers - Additional precondition needed → Update Preconditions - Exploit impossible → Downgrade severity or mark Invalid ### 5. Output **Files** (use same naming format `{Severity}-{id}-{title}`): ``` test/poc/H-01-donation-attack.t.sol # PoC code (project root) .vigilo/poc/H-01-donation-attack.md # Validation log .vigilo/findings/high/logic/H-01-donation-attack.md # (Modified) Attack Scenario ``` **Naming Convention**: `{Severity}-{id}-{kebab-case-title}` - Same format across all three file types - Makes it easy to track: scenario → PoC code → validation log --- ## Reference Files | File | When to Load | |------|--------------| | [poc-templates.md](references/poc-templates.md) | When writing PoC - Bug class patterns | | [debugging.md](references/debugging.md) | When test fails - Error resolution |