zwesty
Write-ups / Day 5 / Metadata
Day 5 · Mon, Oct 5 · Metadata

Chunk Norris

Prey slaughtered

PNG structure (signature, chunks, CRCs) · reading IHDR · spotting what doesn't belong in a file

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-05-chunk-norris (+ /time_trial, /mastery)
Solved
2026-10-07, all three modes, first attempt each, in 1 min 2 s from the first start (15:39:35 → 15:40:37 UTC)
Player
Zwesty (solo), with Claude Code (Opus 5.5)

The challenge

The PNGs render, but rendering is not proof. Walk their chunks, verify their declared geometry, and locate the image with an unexpected structural passenger.

One question per file: "Determine png.ihdr_dimensions_pixels for panel-NNN.png." Exact text, trimmed. The Single Solve asks about panel-001.png, the Time Trial panel-002.png, and Mastery panel-003.png and panel-004.png (two zips).

Reading the prompt: what it said we'd need

Clue What it pointed to What I did about it
"Rendering is not proof" A viewer showing the image says nothing about its structure Parse the bytes, not the picture
"Walk their chunks" A PNG is a chain of chunks; walk it properly rather than grepping A chunk parser with CRC checks
"Verify their declared geometry" + the field png.ihdr_dimensions_pixels IHDR, the header chunk that declares width and height Read IHDR, which must be the first chunk
"Unexpected structural passenger" Extra content: an unknown chunk, data in a text chunk, or bytes appended after IEND The inventory reports every chunk type, CRC status, and trailing byte
Same zip layout as Days 1–4 The Metadata lane compounds again Build on Picture This's solver

How a PNG is built

89 50 4E 47 0D 0A 1A 0A          signature ("\x89PNG\r\n\x1a\n")
[length:4][type:4][data][crc:4]  chunk, repeated
Chunk Role
IHDR Must come first. 13 bytes: width (4), height (4), bit depth, colour type, compression, filter, interlace
PLTE, tRNS, gAMA, pHYs, … Optional ancillary data
tEXt / zTXt / iTXt Text key-value pairs, a favourite hiding place
IDAT The compressed pixels
IEND The end. Anything after it is ignored by viewers, which is why data gets appended there

Every chunk carries a CRC-32 over its type and data, so a tampered chunk usually shows up as a bad CRC, unless whoever changed it also recomputed the CRC.

What was in the files

Every panel was a minimal, clean PNG: IHDR, one IDAT, IEND. Every CRC was valid, there was no ancillary chunk, and there was nothing after IEND.

Mode File Bytes Chunks IHDR Answer
Single Solve panel-001.png 414 IHDR IDAT(357) IEND 269 × 153, 8-bit RGB 269x153
Time Trial panel-002.png 438 IHDR IDAT(381) IEND 282 × 162 282x162
Mastery set 1 panel-003.png 463 IHDR IDAT(406) IEND 295 × 171 295x171
Mastery set 2 panel-004.png 488 IHDR IDAT(431) IEND 308 × 180 308x180

The "passenger" image wasn't among them, as with Picture This's deceptive photo. The prompt describes the whole pool; each mode drew clean panels. The sizes step by exactly +13 × +9 per panel, so like Picture This's +17 × +11, they're generated from a counter.

Single Solve: CORRECT in 17 seconds

Started at 15:39:35 UTC. The zip's SHA-256 matched. Walking panel-001.png gave IHDR 269 × 153. The format was the same unstated kind as Picture This, so I used the form accepted there (257x146), with 269 x 153 as the fallback. 269x153 was CORRECT at 15:39:52, flag 5322ea86…8f4f.

The solver

Our Day 5 solver loads Picture This's solver by path, which keeps four days of Metadata handling, and adds the field …-png-ihdr-dimensions-pixels: - It checks the PNG signature. - It reads the first chunk only, and requires it to be a 13-byte IHDR. - It answers width x height.

The inventory goes further, for the "passenger" question that might come later: every chunk, its CRC status, any non-standard chunk type, and anything after IEND.

7 tests, all passing before any timed run: - the real file; - width/height order; - passengers (a tEXt claiming "1920x1080", an unknown zzZz chunk, a zip appended after IEND) not changing the answer; - a second, fake IHDR later in the file, ignored; - a bad CRC, reported but not fatal; - the Mastery shape; - a JPEG named .png, refused.

Time Trial: 1.47 s of a 6-second clock

started_at 2026-10-07T15:40:31.026Z  deadline 2026-10-07T15:40:37.026Z
  artifact metadata-day-05-evidence.zip 378 bytes sha256 0e2866300ff0061a… (checked)
  d05-png-002-png-ihdr-dimensions-pixels: 282x162
  start         458 ms
  artifact      352 ms
  solve           1 ms
  submit        658 ms
  TOTAL        1469 ms
result CORRECT  flag 4d2da8e0…8ddb

Mastery: 1.29 s of a 6-second clock, first attempt

started_at 2026-10-07T15:40:35.867Z  deadline 2026-10-07T15:40:41.867Z
  artifact metadata-forensics-day-05-chunk-norris-mastery.zip 1035 bytes sha256 286713e78c4ce113… (checked)
  set1.d05-png-003-png-ihdr-dimensions-pixels: 295x171
  set2.d05-png-004-png-ihdr-dimensions-pixels: 308x180
  start         387 ms
  artifact      321 ms
  solve           1 ms
  submit        581 ms
  TOTAL        1290 ms
result CORRECT  flag afceaa5f…5579

The fastest timed run of the day so far.

Time to solve

All three modes were solved on 2026-10-07 by 15:40:37 UTC, 1 min 2 s after the first start. The Single Solve took 17 s, the solver was extended in under a minute, and the Time Trial (1.47 s of 6 s) and the Mastery (1.29 s of 6 s) each went through on the first submit.

Takeaways

  • The spec tells you where to look. IHDR must be the first chunk, so reading the first chunk, not searching for the bytes IHDR, can't be fooled by a second, fake one.
  • Walk the whole structure even when the question is narrow. The answer only needed IHDR, but the inventory checks every CRC and everything after IEND, which is where a passenger would ride.
  • Reuse the answer format across related questions. Picture This's WxH was right for Chunk Norris too, so the format guess cost nothing.
  • The Metadata lane is a growing toolkit: zip handling (Day 1), magic bytes (Day 2), text encodings (Day 3), JPEG segments (Day 4), and now PNG chunks.