Header Repair: Finding the One Wrong Byte in a PNG Signature
The challenge
A file recovered from a wiped drive is named like a PNG and is almost certainly a PNG, but every decoder refuses to open it. The rest of the structure survived intact: you can see the IHDR, gAMA and cHRM chunk names in the ASCII column, so the damage is limited to the very start. Exactly one byte inside the eight-byte signature was flipped during recovery. Compare the file's leading bytes against the magic-byte reference, and find the single byte that does not belong. Submit that byte in hex: either the wrong value the file currently holds or the correct value it should hold is accepted, because naming either one proves you located the corruption. What is not accepted is the offset.
What you'll learn
- Diff a file header against a known magic-byte signature position by position
- Use the ASCII gutter as a faster read of a printable signature
- Understand that magic bytes are an exact-match contract, not a heuristic
- Distinguish header damage from whole-file corruption using later structure
- Recover the intended value of a damaged byte rather than merely locating it
Skills tested
Prerequisites
- Reading hexadecimal byte values
- Awareness that files begin with a type signature
How it works
Nearly every binary format starts with a fixed signature, and a decoder treats it as a contract. It compares the bytes exactly and refuses the file on any mismatch. That strictness is a feature, because it stops a parser from confidently misreading the wrong kind of data, but it also means a single damaged byte can make a completely intact file unopenable.
The PNG signature is eight bytes: 89 50 4E 47 0D 0A 1A 0A. It is deliberately over-engineered. 0x89 has the high bit set so a transfer that strips the eighth bit is detected, 50 4E 47 spells PNG in ASCII so a human can read it, and the trailing 0D 0A 1A 0A catches line-ending translation and premature end-of-file handling.
This file holds 89 51 4E 47 0D 0A 1A 0A. Seven bytes match. The byte at offset 0x01 is 0x51 where 0x50 is required, which is a single flipped bit turning P into Q, and the ASCII gutter shows it as .QNG instead of .PNG. Everything after the signature is intact, which is why IHDR, gAMA and cHRM are still readable further down. The file is genuinely a PNG; only its front door is broken. The corrected byte is 0x50.
Common mistakes
- Submitting the offset instead of the value. The damaged byte sits at offset
0x01, but the question asks what value belongs there, which is50. - Diffing against the wrong reference row. The ZIP signature
50 4B 03 04also begins with50, so skimming the reference can anchor you to the wrong format. Match the full PNG row. - Answering PNG. The type is already given in the brief. This hack is a repair task, not an identification task.
- Suspecting 0x89. It looks anomalous because it is non-printable, but it is the correct first byte of a PNG signature.
- Assuming the whole file is corrupt. The later chunk names prove the damage is confined to the signature.
How to defend against it
For anyone building tooling that ingests files, the takeaway is that signature checking should be strict at the boundary and informative in the logs.
- Validate the full signature and reject on mismatch. Never fall back to trusting the file extension when the magic bytes disagree.
- Log which byte position failed and what was expected, so a recovery engineer can repair a header without a manual diff.
- Store a checksum alongside archived assets so corruption is detected on write rather than discovered years later during a restore.
- Keep verified copies of format signatures in your tooling instead of hardcoding partial prefixes, since a four-byte PNG check would have accepted several damaged variants.
- Remember the flip side: because signatures are only the first few bytes, an attacker can prepend a valid header to hostile content. Signature checks establish format, not safety.