🌳 Advanced ⏱️ ongoing

More CTFs: Capture the Ether, QuillCTF, Paradigm

After Ethernaut and Damn Vulnerable DeFi, you have a solid foundation. Now it is time to broaden your exposure across different CTF platforms, each teaching different vulnerability patterns at increasing levels of sophistication. This lesson covers all the major platforms, how they compare, and a systematic methodology for approaching any CTF challenge.

CTF Platform Comparison

Platform	Difficulty	Style	Best For	Cost
Ethernaut	Beginner-Medium	Guided, one vuln per level	Starting out	Free
Damn Vulnerable DeFi	Medium-Hard	Multi-contract DeFi systems	DeFi exploits	Free
Capture The Ether	Beginner-Medium	Classic Solidity vulns	EVM fundamentals	Free
QuillCTF	Medium-Hard	Modern DeFi challenges	Current patterns	Free
Paradigm CTF	Expert	Competition, novel research	Top-level prep	Free (competitive)
Mr. Steal Yo Crypto	Hard	Real protocol clones	Advanced DeFi	Free
Curta CTF	Expert	Gas golf + logic	EVM optimization	Free
ETH Security Wargames	Medium	Guided learning	Structured practice	Free

Capture The Ether — The Classic

Created by smarx, Capture The Ether is one of the earliest smart contract CTFs. Some challenges use very old Solidity patterns (pre-0.8.0), which makes it excellent for understanding historical vulnerabilities that still appear in legacy codebases.

Why It's Still Valuable

EVM fundamentals: Forces you to understand how the EVM works at a low level
Historical bugs: Overflow, constructor naming — bugs that made headlines
Block-level manipulation: Teaches blockhash and pseudo-randomness deeply
Storage layout: Levels requiring you to read raw storage slots

🎯 CTE Key Challenges and Concepts

Category: Math
  - Token Sale: Integer overflow in unit price calculation
    → (uint overflow attack on multiplication)
  - Token Whale: Transfer between accounts triggers underflow
    → Understanding approve/transferFrom interaction

Category: Accounts
  - Fuzzy Identity: Force an address to have a specific hash property
    → CREATE2 address prediction and mining

Category: Miscellaneous
  - Assume Ownership: Unprotected ownership function
    → Classic missing access control
  - Deploy a contract: Understand how contracts are deployed
    → EVM CREATE opcode

Category: Lotteries (all about fake randomness)
  - Guess the number: Read "private" storage variables
    → storage slot layout
  - Predict the blockhash: Blockhash returns 0 for old blocks
    → Exploit: submit block number 256+ blocks old
  - Predict the future: Commit-reveal scheme needed
    → blockhash manipulation

💥 CTE: Predict the Blockhash Exploit

// Ethereum only stores blockhashes for the last 256 blocks
// blockhash(N) returns 0x0 for blocks more than 256 old

contract PredictTheBlockHashSolver {
    PredictTheBlockHashChallenge challenge;

    function lockInGuess() external payable {
        // Guess that the blockhash will be 0x0
        // by committing now and not settling for 256+ blocks
        challenge.lockInGuess{value: 1 ether}(bytes32(0));
    }

    function settle() external {
        // Wait 256+ blocks after lockInGuess, then settle
        // The blockhash of that old block = 0x0 (not stored anymore)
        // Our guess of bytes32(0) = 0x0 → WIN!
        challenge.settle();
    }
}

QuillCTF — Modern DeFi Challenges

QuillCTF (by QuillAudits) features more modern Solidity patterns and DeFi constructs. These challenges are closer to real audit work — well-written contracts with subtle bugs that require careful reading.

What Makes QuillCTF Different

Recent Solidity versions: Uses 0.8.x features and patterns
Real DeFi patterns: Staking, vesting, DEX-like contracts
Subtle bugs: No obvious single-line fixes — requires understanding the whole system
ERC standard exploits: ERC-20, ERC-721, ERC-4626 vulnerabilities

🎯 QuillCTF Challenge Examples

VRFNFTRandomDraw:
  Topic: Fake randomness, VRF manipulation
  Pattern: Challenge assumes VRF coordinator is honest
  Attack: Deploy fake VRF coordinator, return predictable values

WETH10:
  Topic: Reentrancy in token wrapper
  Pattern: withdraw() + receive() interaction in wrapped ETH
  Attack: Classic reentrancy through ETH receive

Panda Token:
  Topic: Signature replay
  Pattern: Missing nonce in off-chain signature
  Attack: Replay same signature multiple times to mint unlimited tokens

Ro0tMi4:
  Topic: Access control with CREATE2
  Pattern: Admin check uses extcodesize (0 for constructors)
  Attack: Call admin function from constructor of a new contract

Paradigm CTF — Research-Grade Challenges

Paradigm CTF is an annual competition run by Paradigm, one of the most respected crypto investment and research firms. These challenges are designed by world-class security researchers and often require understanding EVM internals, cryptography, or novel attack patterns.

⚠️ Difficulty Warning

Paradigm CTF challenges are extremely difficult. They are not a good starting point. Many require deep EVM knowledge, mathematical reasoning, and understanding of advanced protocols. Attempting them too early leads to frustration. Recommended: tackle them after 6+ months of CTF practice and after completing Cyfrin Updraft's security course.

What You Learn from Paradigm CTF

Novel attack patterns: Things that haven't been publicly documented yet
Cross-contract multi-step exploits: 5-10 contract interactions per attack
EVM internals: Opcode-level reasoning, assembly, storage layout
Cryptographic attacks: ECDSA quirks, hash collision scenarios

Mr. Steal Yo Crypto

Created by the same team as Damn Vulnerable DeFi, Mr. Steal Yo Crypto features clones of real DeFi protocols (Uniswap, Compound, Curve clones) with a single bug injected. This is as close to real audit work as CTFs get.

🥷 Mr. Steal Yo Crypto: Style

Each challenge:
  1. A near-exact clone of a known DeFi protocol
  2. One subtle bug injected (could be 1-2 lines different)
  3. You must: find the bug, build the exploit, drain the funds

Example challenge types:
  - Curve-like pool with wrong slippage calculation
  - Uniswap clone with missing reentrancy guard
  - Compound fork with incorrect interest rate rounding
  - Synthetix staking with reward accounting bug

Why this is valuable:
  - Real protocols have well-known correct implementations
  - If you know the original code, the diff is the bug
  - Teaches "diff auditing" — a common technique for forked protocols

CTF Solve Methodology

A systematic methodology for approaching any CTF challenge. Apply this every time — even for challenges you cannot solve, going through the steps builds pattern recognition:

🧠 The 6-Step CTF Methodology

Step 1: READ THE WIN CONDITION
  What does "solved" look like?
  Who has what balance? What state is set?
  Work backwards from the goal.

Step 2: READ THE FULL CONTRACT CAREFULLY
  Don't skim. Read every line.
  Pay special attention to:
    - Every require() condition
    - Every mapping/state update
    - Access control modifiers
    - External calls
    - Events (they tell you what state changes are expected)

Step 3: TRACE ALL STATE-CHANGING PATHS
  For each function: what state does it change?
  Can that state be changed unexpectedly by combining calls?
  What does each function ASSUME about the state?

Step 4: SPOT THE INVARIANT VIOLATION
  What invariant SHOULD hold?
    "pool.balance >= sum(deposits)"
    "only owner can call this"
    "price oracle can't change by more than 5% per block"
  Can you violate it?

Step 5: BUILD THE EXPLOIT
  Write the attacker contract in Foundry
  Start with the end goal: what final calls drain/win?
  Work backwards: what state do those calls need?
  Build the setup: flash loans, approvals, deposits

Step 6: TEST AND ITERATE
  forge test -vvvv shows full execution trace
  Use console.log() to debug state at each step
  If it reverts: read the exact revert reason
  Common issues: wrong amount, missing approval, wrong order

Reading Other People's Writeups

📝 How to Extract Maximum Value from Writeups

When reading someone else's CTF solution:

WHAT TO LOOK FOR:
  1. How did they identify the vulnerability?
     → What clues in the code pointed to it?
     → Could you have spotted those same clues?

  2. What was the key insight?
     → Often one sentence: "The balance check uses X but should use Y"
     → Write this insight in your own words

  3. How did they build the exploit?
     → What's the sequence of calls?
     → What approvals were needed first?

  4. What would have PREVENTED this bug?
     → Write the 2-line fix
     → What test would have caught it?

WHAT NOT TO DO:
  ✗ Don't just copy the exploit code
  ✗ Don't read the solution before genuinely trying
  ✗ Don't move on without understanding the root cause

FORMAT FOR YOUR NOTES:
  # Level: [Name]
  # Platform: [Ethernaut / DVDF / etc.]
  # Vulnerability: [Reentrancy / Integer Overflow / etc.]
  # Root Cause: [One sentence]
  # Attack: [Step-by-step sequence]
  # Fix: [How to prevent it]
  # Real World: [Analogous hack with link]

Building Your Personal Vulnerability Pattern Library

💡 Pattern Library Strategy

After each CTF challenge (solved or not), add an entry to your personal vulnerability library. Use Notion, Obsidian, or a GitHub repo. Format: vulnerability type → how to identify it in code → exploit technique → prevention. After 50+ CTF challenges, you will have a personal reference that makes you dramatically faster at finding bugs in real audits.

📚 Example Pattern Library Entry

## Vulnerability: Reentrancy via .call

### How to Identify:
  - External .call{value: X}("") before state update
  - msg.sender.call before balances[msg.sender] = 0
  - .call in a withdraw/claim function

### Exploit Technique:
  1. Deploy contract with receive() that calls back withdraw()
  2. Deposit funds to get positive balance
  3. Call withdraw() — triggers receive() before balance zeroed
  4. receive() calls withdraw() again — balance still non-zero
  5. Repeat until pool is drained

### Code Pattern (Red Flag):
  function withdraw(uint amount) external {
      require(balances[msg.sender] >= amount);
      (bool ok,) = msg.sender.call{value: amount}("");  // ← DANGER
      balances[msg.sender] -= amount;  // ← too late
  }

### Prevention:
  - Checks-Effects-Interactions pattern
  - ReentrancyGuard (nonReentrant modifier)
  - Pull payments pattern

### Real World Analogues:
  - The DAO 2016: $60M
  - Lendf.me 2020: $25M
  - Cream Finance 2021: $130M

From CTFs to Real Auditing

📈 The Journey: CTFs → Real Audit Work

Phase 1: CTF Foundation (2-3 months)
  ✓ Complete Ethernaut levels 1-20
  ✓ Complete DVDF challenges 1-8
  ✓ Complete QuillCTF beginner challenges
  → Output: Pattern library with 30+ vulnerability types

Phase 2: Structured Learning (2-3 months)
  ✓ Cyfrin Updraft Security Course
  ✓ Read OpenZeppelin contracts source code
  ✓ Read major protocol audit reports (Aave, Compound, Uniswap)
  → Output: Understanding of professional audit methodology

Phase 3: First Competitions (2-4 months)
  ✓ Code4rena First Flights (beginner contests)
  ✓ Sherlock beginner contests
  ✓ Focus on reading, not winning — observe what top wardens find
  → Output: Understanding of professional audit reports

Phase 4: Real Auditing (ongoing)
  ✓ Code4rena and Sherlock main contests
  ✓ Immunefi bug bounties
  ✓ Private firm application (Trail of Bits, OZ, Spearbit)
  → Output: Real findings, real payouts

Key insight: CTFs teach you to find the bug.
Real auditing also requires: clear writing, impact assessment,
accurate severity rating, and professional communication.

Common Mistakes Section

⚠️ Mistake #1: Skipping to Harder CTFs Too Fast

Paradigm CTF challenges solved by brute force memorization without understanding produce almost no skill gain. The goal is not to check boxes — it is to internalize patterns. If you cannot explain the root cause of a vulnerability you just "solved" by following a writeup, you have not actually learned it.

⚠️ Mistake #2: Not Timing Your Attempts

Real audits are time-limited (3-7 days for competitive contests). Start timing yourself on CTF challenges. If you've spent 4 hours and have no progress, read a hint or one section of a writeup — not the full solution. Learn to calibrate "I should look for hints now" vs "I can figure this out with more time".

⚠️ Mistake #3: Not Building with Foundry

Solving Ethernaut in the browser console is fine for early levels. But if you continue solving CTFs via browser scripts for more than the first 5 levels, you are building the wrong muscle memory. Real auditing uses Foundry. Practice building exploit contracts in Foundry from the start.

Summary / Key Takeaways

Platform	When to Use	Key Learning
Capture The Ether	After Ethernaut 1-10	EVM internals, historical bugs
QuillCTF	After DVDF	Modern Solidity patterns, DeFi
Paradigm CTF	After 6+ months practice	Research-level novel attacks
Mr. Steal Yo Crypto	After DVDF	Real protocol clone auditing
All CTFs	Continuously	Pattern recognition = faster auditing

🎮

CTF Platform

Capture The Ether — Classic Challenges

→

💻

CTF Platform

QuillCTF — Modern DeFi Challenges

→

🏆

GitHub

Paradigm CTF 2023 — Challenges Archive

→

🥷

CTF Platform

Mr. Steal Yo Crypto — Real Protocol Clones

→

📚

Reference Code

Solmate — Well-Written Reference Contracts to Study

→

← Damn Vulnerable DeFi — Real DeFi Exploits Take Chapter Quiz →