Reentrancy attacks in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Reentrancy attacks

Start Transaction

↓

Call External Contract

↓

External Contract Calls Back

↓

Re-enter Vulnerable Function

↓

Modify State Unexpectedly

↓

Complete Original Function

↓

Funds Drained or State Corrupted

This flow shows how a contract calls an external contract, which then calls back into the original contract before its state is updated, causing unexpected state changes.

Execution Sample

Blockchain / Solidity

function withdraw(uint amount) public {
  require(balances[msg.sender] >= amount);
  (bool success, ) = msg.sender.call{value: amount}();
  require(success);
  balances[msg.sender] -= amount;
}

This function sends Ether to the caller before updating their balance, allowing reentrancy if the caller is a contract.

Execution Table

Step	Action	balances[msg.sender]	Call Success	State Change	Notes
1	Check balance >= amount	100	N/A	No	Balance sufficient, proceed
2	Send Ether via call	100	true	No	Ether sent, external call starts
3	External contract calls withdraw again	100	N/A	No	Reentrancy occurs before balance update
4	Check balance >= amount (reentrant)	100	N/A	No	Still sufficient, proceed again
5	Send Ether via call (reentrant)	100	true	No	Ether sent again
6	Update balance (reentrant)	0	N/A	Yes	Balance set to 0 after reentrant call
7	Return from reentrant call	0	N/A	No	Back to first call
8	Update balance (original call)	0	N/A	Yes	Balance set to 0 again, but funds already drained
9	End function	0	N/A	No	Funds drained due to reentrancy

💡 Execution stops after balance is drained due to reentrancy before state update.

Variable Tracker

Variable	Start	After Step 2	After Step 6	After Step 8	Final
balances[msg.sender]	100	100	0	0	0
Call Success	N/A	true	N/A	N/A	N/A

Key Moments - 3 Insights

Why does the balance not update before the external call?

Because the balance is updated after sending Ether (step 8), the external contract can call back before the update (step 3), causing reentrancy.

What allows the external contract to call withdraw again?

The external call uses low-level call which forwards control, allowing the external contract to re-enter the vulnerable function before state changes.

Why is the balance zero after the reentrant call?

Because the balance is only updated after the external call returns, the reentrant call drains funds before the balance is reduced.

Visual Quiz - 3 Questions

Look at the execution table, what is balances[msg.sender] after step 6?

A 0

B 100

C 50

D Undefined

💡 Hint

Check the 'balances[msg.sender]' column at step 6 in the execution_table.

At which step does the external contract call withdraw again?

A Step 5

B Step 2

C Step 3

D Step 8

💡 Hint

Look for the row mentioning 'External contract calls withdraw again' in the execution_table.

If the balance was updated before the external call, how would the execution_table change?

A Reentrancy would still occur with same results

B The balance would be reduced before call, preventing reentrancy

C The call success would be false

D The external contract could not call back

💡 Hint

Consider the variable_tracker and when balances[msg.sender] changes relative to the call.

Concept Snapshot

Reentrancy attacks happen when a contract calls an external contract before updating its own state.
The external contract can call back into the original contract, causing unexpected repeated execution.
Always update state before sending Ether or calling external contracts.
Use patterns like checks-effects-interactions to prevent this.
Low-level calls (call, delegatecall) can enable reentrancy if not handled carefully.

Full Transcript

This visual trace shows a reentrancy attack in a blockchain smart contract. The withdraw function sends Ether to the caller before updating the caller's balance. Because the balance update happens after the external call, a malicious contract can call withdraw again during the external call, draining funds multiple times. The execution table tracks each step, showing the balance remains unchanged during the reentrant call, allowing repeated withdrawals. The variable tracker highlights how balances[msg.sender] changes only after the reentrant call finishes, causing the vulnerability. Key moments clarify why the order of operations matters and how reentrancy happens. The quiz tests understanding of the balance changes and call flow. The snapshot summarizes the key rule: always update state before external calls to prevent reentrancy.

Practice

1. What is a reentrancy attack in blockchain smart contracts?

easy

A. An attack where a contract is called repeatedly before finishing its first call

B. An attack that steals private keys from a wallet

C. An attack that floods the network with transactions

D. An attack that changes the blockchain consensus rules

Solution

1. Step 1: Understand the concept of reentrancy

   Reentrancy happens when a contract allows another call to itself before the first call finishes, causing unexpected behavior.

2. Step 2: Identify the correct description

   An attack where a contract is called repeatedly before finishing its first call correctly describes repeated calls before finishing, which is the core of reentrancy attacks.

3. Final Answer:

   An attack where a contract is called repeatedly before finishing its first call -> Option A

4. Quick Check:

   Repeated calls before finish = Reentrancy attack [OK]

Hint: Look for repeated calls before state update to spot reentrancy [OK]

Common Mistakes:

• Confusing reentrancy with key theft
• Thinking it floods network instead
• Mixing with consensus attacks

2. Which Solidity code snippet correctly prevents reentrancy by updating state before sending Ether?

easy

A. payable(msg.sender).transfer(amount); balances[msg.sender] = 0;

B. require(balances[msg.sender] > 0); payable(msg.sender).transfer(amount);

C. balances[msg.sender] = 0; payable(msg.sender).transfer(amount);

D. balances[msg.sender] += amount; payable(msg.sender).transfer(amount);

Solution

1. Step 1: Identify the safe order of operations

   To prevent reentrancy, update the user's balance before sending Ether to avoid repeated withdrawals.

2. Step 2: Check each option's order

   balances[msg.sender] = 0; payable(msg.sender).transfer(amount); updates balance first, then sends Ether, which is the correct pattern.

3. Final Answer:

   balances[msg.sender] = 0; payable(msg.sender).transfer(amount); -> Option C

4. Quick Check:

   Update state before transfer = Safe pattern [OK]

Hint: Always update balances before sending Ether to avoid reentrancy [OK]

Common Mistakes:

• Sending Ether before updating balance
• Not checking balance before transfer
• Increasing balance instead of resetting

3. Consider this Solidity function snippet:

function withdraw(uint amount) public {
  require(balances[msg.sender] >= amount);
  payable(msg.sender).transfer(amount);
  balances[msg.sender] -= amount;
}

What is the likely outcome if this contract is attacked by a reentrancy exploit?

medium

A. The attacker can withdraw more than their balance multiple times

B. The contract will reject the withdrawal due to require failing

C. The contract will revert due to syntax error

D. The attacker cannot withdraw more than their balance

Solution

1. Step 1: Analyze the order of operations in withdraw

   The contract sends Ether before reducing the balance, allowing reentrant calls to withdraw repeatedly.

2. Step 2: Understand the attack effect

   Because balance is reduced after transfer, attacker can call withdraw again before balance updates, draining funds.

3. Final Answer:

   The attacker can withdraw more than their balance multiple times -> Option A

4. Quick Check:

   Transfer before balance update = Vulnerable to reentrancy [OK]

Hint: Check if balance updates happen after transfer to spot vulnerability [OK]

Common Mistakes:

• Assuming require protects fully
• Thinking syntax error occurs
• Believing attacker can't withdraw extra

4. This Solidity function is vulnerable to reentrancy. What is the best fix?

function withdraw(uint amount) public {
  require(balances[msg.sender] >= amount);
  payable(msg.sender).transfer(amount);
  balances[msg.sender] -= amount;
}

medium

A. Add a loop to call transfer multiple times

B. Remove the require statement

C. Increase balances[msg.sender] after transfer

D. Move balances[msg.sender] -= amount; before transfer call

Solution

1. Step 1: Identify vulnerability cause

   Balance is updated after sending Ether, allowing reentrant calls to exploit the contract.

2. Step 2: Apply fix by reordering

   Moving balance update before transfer prevents reentrancy by blocking repeated withdrawals.

3. Final Answer:

   Move balances[msg.sender] -= amount; before transfer call -> Option D

4. Quick Check:

   Update state before transfer = Fix reentrancy [OK]

Hint: Update balances before sending Ether to fix reentrancy [OK]

Common Mistakes:

• Removing require weakens security
• Adding loops increases risk
• Increasing balance after transfer worsens issue

5. You want to secure a smart contract against reentrancy attacks. Which combination of techniques is best practice?

hard

A. Allow multiple reentrant calls to improve performance

B. Update state before external calls and use a reentrancy guard modifier

C. Use only require statements without updating state

D. Send Ether first, then update state, and avoid using modifiers

Solution

1. Step 1: Recall best practices for reentrancy protection

   Update contract state before external calls and use reentrancy guard modifiers to block repeated calls.

2. Step 2: Evaluate options

   Update state before external calls and use a reentrancy guard modifier combines both safe state update order and reentrancy guard, providing strong protection.

3. Final Answer:

   Update state before external calls and use a reentrancy guard modifier -> Option B

4. Quick Check:

   State update + guard = Best reentrancy defense [OK]

Hint: Combine state update and guard modifier for strong defense [OK]

Common Mistakes:

• Sending Ether before state update
• Ignoring reentrancy guard usage
• Allowing reentrant calls for speed