Common vulnerability patterns in Blockchain / Solidity - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Reentrancy Attack Output

What is the output of this simplified Solidity-like pseudocode when a reentrancy attack occurs?

Blockchain / Solidity

contract Vulnerable {
    mapping(address => uint) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

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

// Attacker calls withdraw repeatedly before balances[msg.sender] is updated.

A The contract locks funds permanently due to a deadlock in withdraw.

B The attacker drains all funds by repeatedly calling withdraw before balance updates.

C The contract rejects the withdrawal due to insufficient balance immediately.

D The contract throws a compile-time error due to missing return statement.

💡 Hint

Think about what happens if the external call happens before the balance is updated.

Because the balance is updated after sending funds, the attacker can call withdraw recursively before the balance decreases, draining all funds.

❓ Predict Output

intermediate

Integer Overflow Result

What is the value of variable `total` after running this Solidity-like pseudocode?

Blockchain / Solidity

uint8 a = 250;
uint8 b = 10;
uint8 total = a + b; // uint8 max is 255

A 4

B 260

C OverflowError at runtime

D 250

💡 Hint

Remember uint8 can only hold values from 0 to 255 and wraps around on overflow.

Adding 250 + 10 equals 260, but uint8 max is 255, so it wraps around: 260 - 256 = 4.

🔧 Debug

advanced

Fix the Timestamp Dependency Bug

This smart contract uses block.timestamp to decide a winner. What is the main vulnerability here?

Blockchain / Solidity

contract Lottery {
    address public winner;

    function pickWinner() public {
        require(block.timestamp % 2 == 0, "Not even timestamp");
        winner = msg.sender;
    }
}

A Function pickWinner is missing a return statement causing compile error.

B The contract will always revert because block.timestamp is never even.

C Miner can manipulate block.timestamp to influence winner selection.

D There is no vulnerability; the code is safe.

💡 Hint

Think about who controls the block timestamp and how it affects randomness.

Miners can slightly manipulate block.timestamp, allowing them to influence the outcome unfairly.

📝 Syntax

advanced

Identify the Syntax Error in Access Control

Which option contains the correct Solidity code to restrict a function to the contract owner?

A

modifier onlyOwner() {
    require(msg.sender == owner)
    _;
}

B

modifier onlyOwner() {
    if(msg.sender != owner) {
        revert();
    }
}

C

modifier onlyOwner() {
    require(msg.sender == owner);
    _;
}

D

modifier onlyOwner() {
    require(msg.sender == owner, "Not owner");
    _;
}

💡 Hint

Look for correct syntax including semicolons and the placeholder _; in modifiers.

Option D correctly uses require with an error message and includes the _; placeholder properly.

🚀 Application

expert

Detecting Front-Running Vulnerability

Which of the following code snippets is vulnerable to front-running attacks in a blockchain environment?

A

function bid() public payable {
    require(msg.value > highestBid);
    highestBidder = msg.sender;
    highestBid = msg.value;
}

B

function bid() public payable {
    require(msg.value >= highestBid);
    highestBid = msg.value;
    highestBidder = msg.sender;
}

C

function bid() public payable {
    require(msg.value > highestBid);
    emit NewBid(msg.sender, msg.value);
    highestBid = msg.value;
    highestBidder = msg.sender;
}

D

function bid() public payable {
    require(msg.value > highestBid);
    highestBid = msg.value;
    highestBidder = msg.sender;
}

💡 Hint

Consider the order of state changes and how miners or attackers can exploit it.

Option A updates highestBidder before highestBid, allowing an attacker to front-run and submit a higher bid before state is fully updated.