What the challenge gives you#

The server lets you upload a custom Solana program (SBF .so) and send exactly two top-level instructions. That already smells like an instruction-introspection bug.

The key mistake (repayment verification)#

The bank does a normal transfer from its vault PDA to the user, then tries to verify that the next instruction repays the loan.

The check is basically:

• read the next instruction from the instructions sysvar
• ensure data[0..4] == 2 (assumed to mean “system transfer”)
• ensure the amount is big enough
• ensure accounts[1] is the bank vault

But it does not verify that the next instruction is actually a System Program transfer (program_id == 111111...).

Here is the vulnerable part (trimmed):

1
let discriminant = u32::from_le_bytes(next_ix.data[0..4].try_into().unwrap());
2
let amount = u64::from_le_bytes(next_ix.data[4..12].try_into().unwrap());
3

4
if discriminant != 2 {
5
    return Err(ProgramError::InvalidInstructionData);
6
}
7

8
let destination_meta = &next_ix.accounts[1];
9
if destination_meta.pubkey != *bank_pda {
10
    return Err(ProgramError::InvalidAccountData);
11
}

WARNING

On Solana, “the next instruction looks like repayment” is not the same as “repayment happened”.

My exploit idea#

I used both allowed instructions like this:

1. Instruction #1 (to my uploaded solve program): CPI into the bank program to:

   • open my account
   • pass KYC (the proof is computable from slot_hashes)
   • request a large loan

2. Instruction #2 (also to my solve program): a no-op call whose data bytes are crafted to look like a System Program transfer payload and whose account metas put the bank vault at index 1.

The bank reads the sysvar, sees “a valid repayment instruction”, and accepts the loan path. But the second instruction never repays anything.

Concept map#

1
flowchart TD
2
    A[Upload custom solve program] --> B[Tx has exactly two top-level instructions]
3
    B --> C[Instruction 1 triggers malicious CPI chain]
4
    C --> C1[OpenAccount]
5
    C --> C2[Compute slot-hash proof and VerifyKYC]
6
    C --> C3[RequestLoan huge amount]
7
    C3 --> D[Bank transfers lamports to user]
8
    D --> E[Bank calls verify_repayment via instructions sysvar]
9
    B --> F[Instruction 2 is forged bytes, not real repayment]
10
    F --> E
11
    E --> G[Check passes on syntax only]
12
    G --> H[No real repayment executed]
13
    H --> I[Bank vault drops below 1,000,000]
14
    I --> J[Challenge prints flag]

Flag

BITSCTF{8ANk_h3157_1n51D3_A_8L0cK_ChA1n_15_cRa2Y}

Defensive notes (how to fix)#

• Validate next_ix.program_id == system_program::id().
• Decode the transfer properly (don’t guess by a magic number).
• Validate source account + signer constraints.
• Prefer explicit escrow / balance-delta checks over sysvar-introspection.

Vulnerability#

The binary reads 0x200 bytes into a 0x100 stack buffer, then ends with leave; ret.

1
sub rsp, 0x100
2
...
3
read(0, rbp-0x100, 0x200)
4
...
5
leave
6
ret

With no canary and no PIE, I can control saved rbp and rip and pivot into a stable writable region.

Why this exploit is fun#

This was a “low gadget” binary, so I leaned on three ideas:

1. Repeated leave; ret pivots to move my stack into predictable writable memory.
2. Partial GOT overwrite (2 bytes) to redirect read@plt into a libc syscall; ret gadget while staying ASLR-safe.
3. SROP to load all registers at once and call execve("/bin/sh", 0, 0).

SROP in one sentence

If I can make a syscall with rax=15 (rt_sigreturn) and a fake signal frame on the stack, I can set almost every register in one shot.

After I got a shell, I read the flag from the filesystem.

Concept map#

1
flowchart TD
2
    A["Overflow in main: read 0x200 into 0x100"] --> B["Overwrite saved RBP + RET"]
3
    B --> C["Pivot with leave; ret to controlled pages"]
4
    C --> D["Stage data at c00100 and c00400"]
5
    D --> E["2-byte overwrite: read@GOT low16"]
6
    E --> F["read@PLT now jumps to syscall; ret"]
7
    F --> G["First syscall: read (returns 15)"]
8
    G --> H["Second syscall: rt_sigreturn (rax=15)"]
9
    H --> I["Load SigreturnFrame"]
10
    I --> J["Set rax=59, rdi=/bin/sh, rip=read@PLT"]
11
    J --> K["execve(/bin/sh,0,0)"]
12
    K --> L["Read flag"]
13
    L --> M["BITSCTF flag"]

Flag

BITSCTF{c21090e2034f279a241db1327ecd5775}

The story#

The service implements a “smart safe” with a password reset option. The firmware includes a SUID binary that prints:

• current time
• a challenge code

Then it asks for a numeric response.

My approach#

1. Identify the artifact and extract the initramfs (binwalk + cpio).
2. Find and reverse the SUID safe app.
3. Rebuild the reset math and PRNG exactly (call order and 32-bit overflow).
4. Compute the correct response from the printed challenge code and submit it.

The important equations are:

1
challenge_code    = mask xor A
2
expected_response = mask xor B
3

4
=> response = (challenge_code xor A) xor B

Concept map#

1
flowchart TD
2
    A["Firmware dump"] --> B["Extract zImage payload"]
3
    B --> C["Extract initramfs cpio"]
4
    C --> D["Inspect /init"]
5
    D --> E["Find SUID /challenge/lock_app"]
6
    E --> F["Reverse reset routine"]
7
    F --> G["Time seed to shuffled S-box"]
8
    F --> H["/dev/urandom 4-byte mask"]
9
    G --> I["sub(rand1), sub(rand2)"]
10
    I --> J["A = ((sub1 * 31337) low32 + sub2) mod 1e6"]
11
    I --> K["B = (sub1 xor sub2) mod 1e6"]
12
    H --> L["challenge = mask xor A"]
13
    H --> M["response = mask xor B"]
14
    L --> N["mask = challenge xor A"]
15
    N --> O["response = mask xor B"]
16
    O --> P["Send code to remote"]
17
    P --> Q["Gift prints flag"]

IMPORTANT

32-bit overflow mattered here. If you compute sub1 * 31337 with unbounded integers, you get the wrong result.

Flag

BITSCTF{7h15_41n7_53cur3_571ll_n07_p47ch1ng_17}