Vesper — Missed-Handover Recovery

Flag: isfcr{fd0a085830b0802f234486bd05c201818fb469ae02c597cd}

1. Overview

The bundle describes a deterministic recovery export from a small RV32IM fixture. An MCU talks to a simulated sensor hub and a two-lane RF bridge, both of which stay powered while the MCU does not. The export contains:

The task is to recover the powered-slot count Q for every boot, replay the fixture exactly, rebuild the handover serialization from the gateway acceptances, and decrypt record.sealed.

2. Reversing the firmware

The ELF has only one loadable 0x500-byte .text segment at 0x10000, no symbols, and no compressed instructions. Disassembling with Capstone (CS_ARCH_RISCV, CS_MODE_RISCV32) gives the complete boot routine.

2.1 Boot sequence

Each boot performs these steps:

1. Read all 64 NVM bytes (op 0, unmetered).
2. Validate the four 16-byte slots and select the valid slot with the highest sequence number.
3. Select the sensor hub, send 0x0D, read two sensor entries, and deselect.
4. Derive k from the NVM state and the first two entries, then read another 3+k entries. The complete vector has N = 5+k entries.
5. Hash the vector and build a six-byte RF frame.
6. Stage the frame through op 3 and submit it with op 4.
7. Commit a new NVM slot with 17 op-5 writes: invalidate marker, 15 data bytes, then write the 0xA5 marker.
8. Enter sleep (op 6).

A full boot executes exactly

40 + 2k

metered commands, and a source-level reimplementation mixed with the RF and sensor model is sufficient; a full CPU emulator is not required once the routine is understood.

2.2 NVM slot layout

Each 16-byte slot is:

A slot is valid when VP, the marker, the zero byte, the complement, and the CRC all check out. With no valid slot the firmware uses the defaults

seq = 0, a3 = 0x6d2b, a2 = 0x9137, a5 = 0

and it commits the first new slot as sequence 1.

2.3 Sensor selection

The first sensor command reads entries e0, e1. The firmware computes

k = (seq ^ a3 ^ (e0 & 0xff) ^ (e1 >> 3)) & 3
N = 5 + k

The second command reads the remaining 3+k entries. The complete vector is [e0, e1, ...], including the original 16-bit type and sign-extension bits.

2.4 Hash and frame

For each vector entry x at index i:

t    = ((x ^ 0xa73d) + a2) & 0xffff
a3   = (rol16(a3 ^ ((i*0x31 + (x & 0x3fff) + 0x31) & 0xffff), 5) + a2) & 0xffff
a2   = (a3 ^ rol16(t, 3)) & 0xffff

Two details matter:

• The NVM CRC is full CRC-16/CCITT-FALSE, init 0xFFFF, not a 12-bit CRC.
• The t4 term is x & 0x3fff, not x & 0xfff, because the firmware does a 32-bit (x << 18) >> 18.

The frame is:

id        = old sequence number (u16 LE)
byte 2    = ((a3 >> 2) ^ (a2 >> 5) ^ a5_old) & 0x1f
byte 3    = ((a2 >> 8) + (a3 >> 11)) & 7
bytes 4..5= CRC-16/CCITT-FALSE over bytes 0..3

The NVM commit stores the new a3, a2, byte 2 as the new a5, and N in the new sequence's slot.

3. Fixture model

3.1 Power slots

Boot b has Q powered slots and G unpowered slots. At the start of every slot both RF lanes advance once. In a powered slot, after the lane advance, the MCU executes one metered command if it is still awake. If the firmware sleeps early, the remaining powered slots still elapse.

If the rail falls before a command, that command never happens. A completed command is atomic. Reset clears the MCU staging register and deasserts sensor chip select, but leaves the NVM, sensor FIFO, RF lanes and gateway untouched.

3.2 Sensor FIFO

The cursor advances by

ceil(number_of_data_bytes / 2)

for each sensor command. If power is lost after an odd number of data bytes, the pending high byte is discarded and the next boot continues at the next entry's low byte. This is why the cursor must be updated incrementally, not only at deselect.

3.3 RF lanes and gateway

A submission enters the lowest empty lane. Its countdown is

D = 60 + 12 * ((frame[2] ^ frame[3]) & 15)

Both lanes decrement at every slot. A lane reaching zero delivers its frame before the MCU command in that slot; simultaneous deliveries occur in lane order. If both lanes are occupied, the submission is dropped.

The gateway accepts the first delivered frame for each identifier and counts all later deliveries with that identifier as duplicates. Every delivery increments RX. Dropped submissions increment DROPPED but never RX.

3.4 Journal checks

memory_check is CRC-16/CCITT-FALSE over all 64 NVM bytes. radio_check is the same CRC over lane 0 then lane 1, where an empty lane contributes nine zero bytes and an occupied lane contributes 01, the u16 remaining count, and the six-byte frame.

4. Recovering the power sequence

Boots are grouped into 24 intervals of six boots. power.csv gives an inclusive range [min, max] for each Q, plus the fixed G. The capture windows additionally pin six exact values:

boot  11 -> 25
boot  35 -> 50
boot  59 -> 38
boot  83 -> 41
boot 107 -> 13
boot 131 -> 3

For each interval a depth-first search tries every Q in the allowed range for its six boots. The search carries the complete fixture state:

• NVM bytes,
• sensor FIFO cursor,
• both RF lane states,
• the set of already accepted identifiers,
• interval counters RX / DUPLICATES / DROPPED.

Branches are pruned using:

• monotonic cursor growth,
• partial RX / duplicate / dropped counts,
• the receipt frames for the current interval: any new acceptance must be the next expected frame; later duplicates are free,
• at the interval boundary, exact cursor, memory_check, radio_check and counter equality.

The final interval also advances the extra 512 unpowered drain slots before checking the last journal row.

The recovered Q values are:

Replaying this sequence reproduces every journal row, including the final NVM export byte-for-byte.

5. Reconstructing the handover records

receipts.bin actually contains

0x1b = 27

records, not 25. Each record is a diagnostic-interval index and the accepted six-byte frame.

During replay, every submission is stored with its vector start and N:

vector = acquisition[start : start + N]

When a lane delivers a frame whose identifier has not been accepted before, the gateway creates a new acceptance, so the vector attached to that lane is the correct one. This also handles the retry case where several submissions share an identifier: only the first delivered frame is accepted, and the vector comes from that specific submission.

The accepted records are:

The canonical serialization is 440 bytes:

b"VESPER-HANDOVER\x00\x01"
u32 record_count = 27
per record:
    u16 id
    u8  N
    N * u16 original FIFO entries

The vectors are the original u16 values from acquisition.bin, not the byte-swapped SPI stream.

6. Decryption

record.sealed starts with VSR1, followed by:

salt   = sealed[4:20]
nonce  = sealed[20:32]
ct+tag = sealed[32:]

The key is HKDF-SHA256 with:

IKM  = canonical serialization
salt = sealed[4:20]
info = b"vesper/handover/v1"

Decrypting with ChaCha20-Poly1305, using the first 32 bytes as associated data, authenticates and yields:

isfcr{fd0a085830b0802f234486bd05c201818fb469ae02c597cd}

7. Verification

The reconstruction was checked in several independent ways:

• Every one of the 24 journal rows matched for cursor, memory_check, radio_check, RX, DUPLICATES and DROPPED.
• The final NVM state matched fram.bin exactly.
• The final journal checks matched:
  • memory_check = 9465
  • radio_check = 17835
• All 27 rebuilt acceptance frames matched receipts.bin in order.
• The canonical serialization authenticated under the sealed record's AEAD, which confirms the exact vector contents as well as the record order.

Artifacts in work/: