Weasel PoC Writer

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

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).