Magic bytes and lying file extensions

A file can be named note.txt while its contents follow another format. An extension is the suffix of the name. A file signature is a characteristic byte pattern, often near the beginning, that supports a format hypothesis. Hexadecimal writes each byte as two digits; an offset names a position counted from zero.

The supplied benign-note.txt begins with the PNG signature. PNG means Portable Network Graphics, an image format. Its first eight bytes are specified, so comparing those bytes gives evidence about the contents rather than relying only on a chosen name. A header match is still narrower than a reader accepting the whole file.

Before you begin

Recommended first: Hex, Base64, and XOR in code, Encoding, hashing, and encryption, Notes: scope, command, result, time, When to stay in CyberChef and when to open Python
Estimated time: 15 min reading, 15 min activity. Setup and optional practice may take longer.
Where you work: Read the supplied byte tables and authored records in any browser, with paper or a text editor. Preserve original files; inspect copies in any later lab. No scanner, image decoder, capture, memory acquisition or installation is required. Practical tool work remains separate from this reading activity.
Without a lab: All evidence needed for the activity appears on this page. Copy it into notes if downloads are unavailable. Read the labeled model and predict each result; a paper trace practises the reasoning while tool operation waits for a lab. Reading needs no JavaScript. Answer checking needs JavaScript and a secure context; saving progress also needs usable browser storage.

After this lesson you can:

Interpret a byte signature using a supplied reference.
Separate signature evidence, classifier output and full-reader confirmation.
Put preservation, inspection, hypothesis and confirmation in a sensible order.

01Example

Worked PNG comparison. It teaches the method; the later independent format has different bytes.

Name: benign-note.txt
Offset 0: 89 50 4E 47 0D 0A 1A 0A
Known signature: PNG
50 4E 47 read as ASCII P N G
Conclusion: PNG is a supported hypothesis; full reader acceptance is separate.

02A signature is a hypothesis with a source

Start by preserving the original and recording its source, then inspect a copy. Compare bytes with an appropriate format reference, record a hypothesis and finally use a suitable reader to check the complete structure. A provenance note says where the bytes came from, when and how they were obtained, and what changed during analysis.

A truncated file can retain its header while missing required content. A polyglot is one byte sequence that fits more than one format interpretation. A classifier such as file can recognize a signature without completing all checks that a full image reader performs. The historical course record reports file classifying this fixture as a 1×1 RGB PNG; it does not record a separate image-decoder confirmation.

Compare a filename with leading bytes, then distinguish a format hypothesis from reader confirmation.Model. A teaching model drawn by hand. It shows the idea, not real tool output.

Read the full explanation below.

Supplied bytes only · no file is parsed, decoded or executed

Source hex: 89 50 4E 47 0D 0A 1A 0A

PNG signature: offset 0, length 8. Known eight-byte PNG signature.

Filename claim: benign-note.txt

Byte evidence: Known eight-byte PNG signature.

Reader acceptance: PNG is a supported hypothesis; full reader acceptance is separate.

Offsets count from zero. Exactly 8 bytes are supplied; next offset 8 is outside this excerpt. Absent bytes and ranges cannot be inferred from a filename or signature.

The supplied eight bytes support a PNG-format hypothesis despite the .txt name.

Follow the explanation

The supplied eight bytes support a PNG-format hypothesis despite the .txt name.
Bytes 50 4E 47 read P N G; signature evidence is separate from full reader acceptance.

Complete supplied bytes and evidence limits

Zero-based offset	Hex	ASCII display
0	89	.
1	50	P
2	4E	N
3	47	G
4	0D	.
5	0A	.
6	1A	.
7	0A	.

PNG signature · offset 0, length 8: Known eight-byte PNG signature.
ASCII P N G · offset 1, length 3: 50 4E 47 read as ASCII P N G.

Filename claim: benign-note.txt. PNG is a supported hypothesis; full reader acceptance is separate.

Display row width: 8. Non-printable ASCII is represented by a dot, not an invented byte. Next offset 8 lies outside the 8-byte excerpt.

A signature can support a format hypothesis without proving the whole file valid.

03Read the signature letters

Use the printed PNG byte card. It is enough to practise the same observation → hypothesis → confirmation distinction required by later evidence.

Label: PNG signature from the PNG specification, section 5.2, as eight bytes.
The file benign-note.txt is those eight bytes followed by a small authored PNG datastream.
Historical 2026-10-12 classifier record: file(1) reported PNG image data, 1 x 1, 8-bit/color RGB, non-interlaced. This card does not use a separate image decoder.

Offset 0: 89 50 4E 47 0D 0A 1A 0A
Bytes 89 is outside ASCII. Bytes 50 4E 47 are the letters P N G.
The download name ends in .txt. The name is a label.

Download the signature card

Label: teaching note for benign-note.txt.
These bytes are the teaching file.
A PNG signature is placed at offset 0, and a small truecolor image follows it.
No photograph of a person. No camera. Preserve this file. Inspect a copy if you open it.
The signature supports a PNG hypothesis. This card does not confirm the image with a decoder.

Download the author record for the PNG bytes

Copy the eight leading bytes and identify the three ASCII letters at positions 1–3 using 50=P, 4E=N and 47=G.
Write the observation separately from the inference: these bytes match the supplied PNG reference, so the likely format is PNG despite the name suffix.
Write the next unresolved step: a suitable reader must accept the complete copied file before you claim it decodes successfully. Preserve the original and its name.
Stop after this note. A browser-only trace establishes reasoning, not a new file-classifier or decoder run.

04Optional challenge

For about ten optional minutes, draw the safe sequence from an original artifact to an inspected copy and then to a checked hypothesis. Beside the reader step, write the distinction between a successful header match and successful full parsing. Do not rename or overwrite the original.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Signature card A: fresh independent file cardOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Filename: meeting.dat. Preserve the original and inspect a copy.
Offset 0 bytes: 25 50 44 46 2D 31 2E 37.
Reference mappings: 25=%, 50=P, 44=D, 46=F, 2D=-.
The supplied format reference says a header beginning %PDF- supports a PDF hypothesis.
No full-format reader result is supplied. Filename extensions do not override the bytes.

Failure card B: separate reader resultOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

A preserved copy has a header matching its supplied reference. A suitable full reader rejects the object as incomplete. No repair has been attempted.

06Explain the evidence and its limit

Optional self-check: write source, preserved-copy method, observed bytes, format hypothesis and missing confirmation.

Review it: distinguish a filename, classifier/header evidence and full-reader acceptance; preserve original evidence and avoid calling a recognizable object safe by signature alone.

07Common mistakes

If a suffix settles the format, compare its origin with the byte evidence: a person can choose the name independently of the contents.

If a header match becomes a claim of successful decoding, state which reader accepted the complete file. If none did, retain the hypothesis wording.

If you change the original name during analysis, preserve its original source/name in your record and work on a copy in later practice.

Check 1
Use Signature card A. Translate only the three bytes after the initial 25 and before 2D. Enter the three uppercase letters without punctuation.
Format: Match the text, including capital and lowercase letters. Spaces at the ends do not matter.
Check 2
Use Signature card A. Which evidence note is justified?
- The .dat extension proves the object cannot match that header.
- Renaming the original supplies missing full-reader evidence.
- A matching header proves the whole file is valid and safe.
- The leading bytes match the supplied header reference, supporting a format hypothesis; full-reader acceptance is untested.
Check 3
Arrange these steps for an independent unknown artifact, from preservation through confirmation.
Use Move up and Move down until the list is in order, first at the top.
1. Use a suitable reader on the copy to check the complete structure.
2. Make and inspect a copy.
3. Preserve the original and record its source.
4. Compare copied bytes with a reference and record a hypothesis.
Check 4 (optional)
Optional: use independent Failure card B. Which conclusion follows?
- Overwrite the original until it opens.
- The header makes the failed reader irrelevant and proves complete validity.
- The header observation remains, but this reader did not accept a complete object; preserve the failure and investigate within scope.
- Reader rejection proves the object is safe.

0 of 3 required checks answered.

Practice

References

PNG specification, third edition
Section 5.2 specifies PNG’s eight-byte signature; later structure and decoding remain separate checks.