zwesty
Write-ups / Day 27 / Metadata
Day 27 · Tue, Oct 27 · Metadata

Packet Loss Prevention

Prey slaughtered

Classic pcap (four magic forms, record walk), pre-built parsers, sorting questions by whether a pre-built parser covers them

STTMClaude Homebase Both

Flags are shortened to their first 8 and last 4 characters because they're unique per team.

Challenge ID
metadata-forensics-day-27-packet-loss-prevention (+ /time_trial, /mastery)
Solved
2026-10-27: all three modes CORRECT on the first submit, by 09:00:58 ET, 53 s after the solver's first start request (09:00:05 ET) and 58 s after the 9 AM release. Both timed modes were ranked runs.
Player
Zwesty (solo), with Claude Code (Opus 5.5): our automated morning solver (a scheduled script on our Kali VM) solved it, with no hands-on Claude work needed

The challenge

"Packet captures, exports, and host artifacts describe the same incident from different angles. Count traffic, reject malformed captures, and find the host narrative missing network evidence."

answer_id Question Format
d27-pcap-001-pcap-packet-count "Determine pcap.packet_count for capture-001.pcap." (artifact metadata-day-27-evidence.zip -> capture-001.pcap) integer: "base-10 integer with no units, separators, or explanatory text"; trimmed

The Time Trial asked 32 questions: every earlier day's field (copied-file names and hashes, roster, BOM, JPEG, PNG, PDF, ZIP, PE, .NET, MSI, LNK, OOXML, email, audio, video, ELF, Mach-O, APK, JAR, SQLite, EVTX, registry hive, Prefetch), today's packet count, and the SHA-256 ordering synthesis. The Mastery asked the same family across 11 sets (352 questions).

Reading the prompt: what it said we'd need

Clue What it pointed to What I did about it
"Packet captures" .pcap (or .pcapng) files A capture reader for both had been pre-built on 2026-10-16
"Count traffic" The number of packet records pcap.packet_count: walk the records from the global header to the end of the file
"reject malformed captures" A truncated or inconsistent file must not give a number The reader raises on a record header or body that runs past the end, or an out-of-range timestamp fraction. No capture today was malformed, and no question asked to flag one
"find the host narrative missing network evidence" Cross-checking host artifacts against the captures No question asked for it; the synthesis field was the usual SHA-256 order list
"Packet Loss Prevention" (title) A pun on DLP; packets are the subject Confirmed the reading

What was in the files

  • Single Solve: metadata-day-27-evidence.zip, 277 bytes, one member: capture-001.pcap, 119 bytes. A classic pcap with the little-endian microsecond magic (d4 c3 b2 a1), version 2.4, snaplen 65,535, and link type 147 (USER0, a private link type). Three records, of 16, 21, and 10 captured bytes, end exactly at the end of the file. Answer 3.
  • Time Trial: evidence.zip, 648,967 bytes, 24 members: one sample per earlier day's file type plus capture-001.pcap (2,450 bytes; little-endian microsecond, snaplen 32,768, Ethernet, 16 packets).
  • Mastery: one 7,495,648-byte zip of 11 evidence sets (evidence-01.zip … evidence-11.zip), 32 questions each. Each set's capture-001.pcap (414 to 5,580 bytes) had 3 to 37 packets, and between them they used all four classic magics: little-endian and big-endian, microsecond and nanosecond (4d 3c b2 a1 / a1 b2 3c 4d). Link types were Ethernet (1), raw IP (101), and 802.11 (105); snaplens 32,768 to 262,144.

Same field, more variety in the timed sets. The Single was one tiny little-endian file; the Mastery mixed byte orders and timestamp resolutions. A reader that knew only d4 c3 b2 a1 would have failed several Mastery sets.

Single Solve

The solver solved it with no stop, straight from the pre-built parser. Its preparation step started the Single Solve untimed and sorted the one question by coverage: known 0, pre-built 1, unconfirmed 0, new 0. The field was new to the event, but its slug pcap-packet-count was already registered by a pre-built parser, so the solver sent the answer straight away.

The capture reader had been built on 2026-10-16, eleven days early: - A file starting 0a 0d 0d 0a goes to the pcapng reader (Section Header, Interface Description, and packet blocks, with block-length checks); anything else to the classic reader. - The classic reader accepts only the four known magics, reads the 24-byte global header, then walks the 16-byte record headers. Each record's captured length must fit in the file and the timestamp fraction must be below 10⁶ (or 10⁹ for nanosecond files); anything off raises. - packet-count (with aliases such as packets, frame-count, record-count) is the number of records walked. The same reader also answers snaplen, link type, version, byte order, timestamp resolution, and captured-byte totals.

started_at  2026-10-27 09:00:06.133 ET   (started by the solver's preparation step)
deadline    none (Single Solve)
answers     1   3
start        274 ms   (the solver reconnected at 09:00:12)
artifact     309 ms   (277 bytes)
solve          1 ms
submit       977 ms
TOTAL       1560 ms   (submit +7.54 s after started_at; the preparation step ran in between)
result      CORRECT   flag 6402701a…01d7   (09:00:12.863)

Before the timed runs, a regression rehearsal against earlier days' puzzles passed.

Time Trial

CORRECT on the first attempt, ranked. The start replied unique_attempts_remaining: 31 and variant_fresh: true.

In the Metadata timed modes the solver's parser chain answers first, then a set of stored per-field rules overwrites any field they cover. Today's packet count came from the chain itself. Day 25's hive root name was a real value in the request log (QFFA…), not none.

started_at  2026-10-27 09:00:46.855 ET
deadline    2026-10-27 09:01:36.855 ET   (50 s)
answers     32   (packet count 16)
start        623 ms
artifact     405 ms   (648,967 bytes)
solve        198 ms
submit       825 ms
TOTAL       2051 ms   (submit +1.53 s after started_at)
result      CORRECT   flag 49a7c00a…ae88   (09:00:47.841)

The synthesis answer listed six files in ascending SHA-256 order, today's capture among them.

Mastery

CORRECT on the first attempt, ranked (11 sets, 355 s clock; Day 26 had 10 sets and 325 s). All eleven packet counts came from each set's own capture; the log shows 352 answers and no none.

started_at  2026-10-27 09:00:54.772 ET
deadline    2026-10-27 09:06:49.772 ET   (355 s)
answers     352 across 11 sets   (packet counts 3 to 37)
start        136 ms after started_at
artifact     908 ms after started_at   (7.5 MB)
solve       3417 ms after started_at   (2509 ms)
submit      4316 ms after started_at
result      CORRECT   flag f863bf09…7681   (09:00:58.359)

Checked afterwards by hand (read-only, a few lines of Python on our Kali VM that walk the record headers): the Single's 3, the TT's 16, and all eleven Mastery counts match what the solver sent, and no capture had a truncated record.

No code was written for this lane today.

Time to solve

All three modes were solved by 09:00:58 ET, 58 s after release and 53 s after the solver's first start request. Each went through on the first submit, and both timed modes were ranked (+1.53 s and +4.32 s after their started_at).

Takeaways

  • Pre-building paid off a third day running. Day 25's hive reader, Day 26's Prefetch reader, and today's capture reader all came from the pre-build passes of 2026-10-14 to 2026-10-16, and each answered a brand-new field with no stop.
  • Build every form of a format. The Single was one little-endian microsecond file; the Mastery used all four classic magics. The pre-built reader handled them all because it was written from the format, not from one sample.
  • A strict walk is the "reject malformed captures" half. The reader refuses a record that runs past the end instead of counting it. No question asked for it today, but a malformed capture would have stopped the solver rather than sent a wrong count.
  • The prompt promises more than the questions ask, as on Day 26. "Find the host narrative missing network evidence" sounds like a cross-artifact check; no field asked for it.