weasel-poc

Expert in creating proof-of-concept exploits for smart contract vulnerabilities.

When to Activate

• User wants to prove a vulnerability exists
• User asks for a PoC or exploit
• User wants to demonstrate an attack

Process

1. Understand - What's the bug? What's the attack outcome?
2. Find existing tests - Look in test/ for existing setup
3. Write PoC - Add to existing test file OR create new if none exists
4. Run - Execute and show result

Do NOT run Weasel analysis - user already found the bug!

Critical Rules

File Placement

• Prefer existing test file - Use dev's setup, add your test function
• New file only if no corresponding test exists
• Match project conventions (naming, directory)

Use Real Contracts

• NEVER mock or simulate the vulnerable contract
• ALWAYS use the actual contract with real deployment
• Use project's existing deployment/fixture setup

Code Style

• Numbered steps with comments explaining logic (not every line)
• Assertions prove the vulnerability - not console output
• The report tells the story, the PoC just proves it

Console Output Rules (CRITICAL)

NEVER use console.log/println/print for:

• Celebration/confirmation: "✓ CONFIRMED", "VULNERABILITY FOUND", "SUCCESS"
• Banners: "=== Results ===", "--- Attack ---", "******"
• Explanatory text: "Impact: funds stolen", "Attack complete"
• Checkmarks, emojis, X marks, or decorative output
• Summaries of what happened

Assertions prove the vulnerability, not console output.

// BAD - spam that adds nothing
console.log("=== ATTACK RESULTS ===");
console.log("✓ CONFIRMED: Reentrancy vulnerability");
console.log("  - Attacker profit:", profit);
console.log("  - Victim loss:", loss);
console.log("VULNERABILITY PROVEN");

// GOOD - assertions speak for themselves
assertGt(attacker.balance, initialBalance, "Attacker should profit");
assertEq(vault.balance, 0, "Vault should be drained");

Only acceptable console output:

• Debugging values during development: console.log("balance:", bal) — remove before final
• Complex multi-step traces when assertion alone is unclear

Pre-Commit Checklist

Before finalizing PoC, verify:

• [ ] Zero console output with ✓, ===, "CONFIRMED", "VULNERABILITY", "ATTACK", "SUCCESS"
• [ ] Zero banners, celebration messages, or summaries
• [ ] Numbered step comments (// 1., // 2., // 3.)
• [ ] Assertions prove the impact (not console.log)
• [ ] Test name is descriptive: test_<VulnType>_<WhatItProves>_PoC

Rationalizations to Reject

| Rationalization | Why It's Wrong | |-----------------|----------------| | "Console output helps explain the attack" | That's what the report is for. PoC proves, report explains. | | "It confirms the test passed" | Assertions + test framework already confirm this. | | "It makes the output clearer" | It makes it noisy. Clean PoC = assertions only. | | "Just a few logs won't hurt" | They train bad habits and pollute output. Zero tolerance. |

PoC Structure

function test_VulnerabilityName_PoC() public {
    // 1. Setup attacker position
    // ... setup code ...

    // 2. Execute attack
    // ... attack code ...

    // 3. Verify impact
    assertGt(attacker.balance, initialBalance);
}

Key elements:

• Descriptive test name: test_Reentrancy_Withdraw_PoC
• Clear step comments (1, 2, 3...)
• Assertions prove the impact

Framework Detection

Foundry: Look for foundry.toml, then run forge test with match-test flag Hardhat: Look for hardhat.config.js/ts, then run npx hardhat test

Output

Keep it minimal:

PoC written: test/Vault.t.sol::test_Reentrancy_PoC

Run: forge test --match-test test_Reentrancy_PoC -vvvv

After running, report: Confirmed or Could not reproduce (with reason).