🔁 How Reentrancy Works: Call Before Update
Learn how attackers exploit external calls to drain contract funds
Your Progress
0 / 5 completed⚙️ How Reentrancy Attacks Work
Let's simulate a live reentrancy attack to understand exactly how attackers exploit the vulnerability. Watch as the contract is drained step by step.
🎯 Interactive: Attack Simulator
Run the attack simulation to see how reentrancy exploits vulnerable contracts:
🏦Contract Balance
👤Attacker Balance
📚Call Stack
Attack Progress
Initial State
Contract has 100 ETH, Attacker deposited 10 ETH
Key Concepts
1️⃣External Calls Are Dangerous
When your contract calls another address (especially with call), that address can execute arbitrary code, including calling back into your contract.
msg.sender.call{value: amount}("");
2️⃣Checks-Effects-Interactions Pattern
Always follow this order: check conditions, update state, then interact externally.
3️⃣State Consistency
The attack works because the contract's state (balances) is inconsistent during the external call. The balance hasn't been zeroed yet, so the check passes on reentry.
4️⃣Fallback/Receive Functions
When a contract receives ETH, its receive() or fallback() function executes. Attackers put malicious code here.
// Malicious reentrancy code here
VictimContract.withdraw();
}
Attack Variations
Attacker reenters the same function repeatedly (like our simulation above).
Attacker calls different function that shares state. Harder to detect.
Exploit delegatecall to execute code in target's context.
Attack via multiple related contracts that share state.
💡 Understanding The Flow
The attack succeeds because:
- Control flow is transferred to attacker during external call
- State hasn't been updated when attacker regains control
- Same checks pass again on reentry because balances unchanged
- Loop continues until contract is fully drained