Run result

severed-stream

12a94d67b9164276a60d3d4ce2acb04d

Scorecard

Deterministic checks

Judge rubric

recon-unopenable — 1.00 (100%) (weight 0.05)

Retrieved and unpacked attachment.zip, obtained flag.pdf.rando, and confirmed it does not open as a normal PDF (no usable %PDF magic; the opening bytes look like random data).

Downloaded/unzipped attachment.zip to get flag.pdf.rando and showed the opening bytes are non-%PDF random data (xxd at offset 0), implying it won't open as a normal PDF.

survey-structure — 1.00 (100%) (weight 0.08)

Surveyed the file with binwalk and/or a PDF stream parser and recognized that its body is well-formed PDF made of multiple zlib/Deflate (/FlateDecode) compressed streams, i.e. only the very start of the file is broken.

Surveyed structure by locating multiple 'stream\n' occurrences and successfully zlib-decompressed the XRef /FlateDecode stream, demonstrating a well-formed PDF body with multiple compressed streams.

bound-corruption — 1.00 (100%) (weight 0.07)

Determined that only a short fixed-length prefix at the start of the file is corrupted (the 'chopped off' region) while everything after it is intact.

Identified first printable ASCII PDF syntax at offset 1665 and noted intact tail/startxref, concluding only the initial prefix region is corrupted while later bytes are intact.

identify-zlib-magic — 1.00 (100%) (weight 0.12)

Inspected an intact FlateDecode stream (the bytes right after a 'stream' keyword) and identified the 2-byte zlib best-compression magic 78 da.

Displayed an intact stream near EOF showing 'stream\n78da...' (tail xxd), explicitly evidencing the zlib magic 78 da.

spot-da-remnant — 1.00 (100%) (weight 0.12)

Noticed the surviving da byte at the tail of the corrupted prefix and deduced it is the second half of a severed 78 da zlib header, so only the leading 78 was destroyed.

Inspected bytes 74..80 as '3cd493da8557' and recognized byte 77 is 0xDA as the surviving second byte of a severed 0x78DA zlib header.

repair-header-byte — 1.00 (100%) (weight 0.15)

Repaired the file by overwriting the byte at the severed zlib header with 0x78, reconstructing a valid 78 da zlib header at the first compressed stream.

Repaired by writing a reconstructed header and restoring the leading 0x78, yielding '78da' at the head of the recovered stream in the fixed file.

confirm-repair — 0.80 (80%) (weight 0.08)

Confirmed the repair (e.g. binwalk now reports zlib compressed data at the repaired offset, or the stream inflates without error), establishing where the first recoverable stream begins.

Confirmed repair by producing a parsable PDF and extracting text via pdftotext; however no explicit binwalk/zlib-at-offset verification output was shown.

inflate-stream — 1.00 (100%) (weight 0.11)

Zlib/Deflate-inflated the recovered stream to obtain the decompressed PDF content stream.

Inflated the recovered content stream (raw deflate) with zlib.decompressobj(-15) to obtain 3713 bytes of decompressed data.

recognize-content-stream — 1.00 (100%) (weight 0.06)

Recognized the decompressed data as a PDF text/content stream (BT/Tf/Td/TJ drawing operators and Lorem-ipsum body text).

Showed decompressed PDF drawing/text operators (e.g., BT, Tf, Tm, TJ) and Lorem ipsum text, recognizing it as a PDF content stream.

locate-flag-text — 0.00 (0%) (weight 0.06)

Located the flag inside the content stream's TJ text array, split across parenthesized kerning groups.

No evidence of locating the flag inside the TJ array split across parenthesized kerning groups; the search for 'FLAG' in the decompressed stream returned -1.

reconstruct-flag — 0.00 (0%) (weight 0.1)

Reconstructed FLAG{**redacted**} by concatenating the parenthesized groups and stripping the PDF kerning tokens.

Flag was obtained via pdftotext from the repaired PDF, but there is no evidence of reconstructing it by concatenating TJ parenthesized groups and stripping kerning tokens.

Terrain

Artifacts

flag artifact

FLAG{**redacted**}

stream_offset artifact

**redacted**

writeup artifact

[Redacted for publication — the agent's writeup sets out the full recovery
chain, byte offsets included, for a mission in the public library. Your own
exports carry it in full.]

Activity

Overview

Conditions