Second Pressing

250 pts. Forensics. No service, just a zip. Description was short:

A favorite record deserves another listen. The needle drops, the familiar rhythm returns, and somewhere between the first play and the replay, something feels different.

The zip held four files: library.db, library.db-wal, library.db-shm, desk.log. So a SQLite database with its write-ahead log and shared memory still next to it. That already establishes the shape of the problem: committed state versus replayed state.

desk.log was tiny:

16:41 test pressing queued
16:42 catalogue revised
16:43 counter closed

Schema was one table:

CREATE TABLE pressings(id INTEGER PRIMARY KEY,title TEXT,receipt TEXT);

Reading the base file alone shows nothing committed yet. Reading it with its WAL next to it shows:

1|Test pressing|withdrawn

The catalogue therefore says withdrawn. The WAL still holds the replay. Extracting printable strings from the WAL copy yields one entry of interest:

pressingeJwrTkxLLkmrNjRKSko2NUzRNTcxNdA1MUk2001MM07TNTQ3MjY1NEmySExMqQUALKEM0A==

The trailing blob after pressing is base64, and it starts with eJw, which is almost always zlib. Decoding it:

import base64, zlib
raw = base64.b64decode(class="hljs-string">"eJwrTkxLLkmrNjRKSko2NUzRNTcxNdA1MUk2001MM07TNTQ3MjY1NEmySExMqQUALKEM0A==")
print(zlib.decompress(raw))

produces:

safctf{12bbc51d-7450-44c6-af3f-1723514b8aad}

That value is the replayed receipt, never committed to the catalogue. The first play reads withdrawn, the replay reads flag. This is standard WAL forensics: the answer lives in the uncommitted frames, so the WAL must be carved rather than trusted to SELECT.

Handling note: a copy of the WAL is preserved under evidence/ before any operation that could checkpoint it, alongside row dumps for the committed state and the replay state.

Flag:

safctf{12bbc51d-7450-44c6-af3f-1723514b8aad}