ZIP Files Are Read Backwards

Mon, 17 Aug 2026 10:00:00 -0500

Every format in this series so far reads front to back. PNG starts with a signature and you walk chunks in order. A text file is bytes from the beginning. Markdown parsers scan line by line, top to bottom.

ZIP reads backwards. The index is at the end of the file, and a reader is expected to seek to the end first and work its way back.

That one decision explains almost everything strange about ZIP, including a few things that look like bugs and one thing that is definitely a bug.

The Index Lives at the End

Here’s a real ZIP containing two small text files. 241 bytes total. Scanning it for the four-byte record signatures gives the whole layout:

offset  bytes         ascii   record
     0  50 4b 03 04   P K . . Local File Header      <- hello.txt
    53  50 4b 03 04   P K . . Local File Header      <- second.txt
   108  50 4b 01 02   P K . . Central Directory Header
   163  50 4b 01 02   P K . . Central Directory Header
   219  50 4b 05 06   P K . . End of Central Directory

Every one of those starts with the same two bytes. 0x50 is decimal 80, which is P in ASCII. 0x4b is decimal 75, which is K.

PK. Phil Katz, who wrote PKZIP in 1989, put his initials in the first two bytes of every structure in the format, and they are still there in every .docx, .jar, and .epub on your machine.

The two bytes after PK are the record type: 03 04 for a local file header, 01 02 for a central directory entry, 05 06 for the end-of-central-directory record. Those aren’t printable characters, which is deliberate. A four-byte constant made of two readable letters and two control bytes is unlikely to appear by accident in text, and easy to spot by eye in a hex dump.

The last 22 bytes are the End of Central Directory record, and it’s the entry point:

50 4b 05 06 00 00 00 00 02 00 02 00 6f 00 00 00 6c 00 00 00 00 00

signature            0x06054b50
total CD records     2
central dir size     111 bytes
central dir offset   108
comment length       0

A reader opens the file, jumps to the end, finds that record, reads “the index is at offset 108,” seeks there, and reads the catalog. Listing the contents of a 4 GB archive touches a few hundred bytes.

Note that each file appears twice: once as a Local File Header immediately before its compressed data, and once as an entry in the Central Directory at the end. Hold that thought.

Why Would You Do This?

Because in 1989 you were writing to a floppy disk, and often to a floppy disk that wasn’t big enough.

If the index goes at the front, you have to know everything about every file before you write the first byte: how many files, how big each one compresses to, where each one lands. That means compressing everything to a temporary location, then writing the header, then copying it all back. On a machine with 640K of RAM and two floppy drives, that’s brutal.

Put the index at the end and you can stream. Compress a file, write it, remember where it went. Compress the next one. When you run out of files, write down everything you remembered. One pass, no temporary copy, and you never needed to know the total size in advance.

TAR solved the same problem by having no index at all, which is why tar has to read an entire archive to find one file, and why you cannot randomly access a .tar.gz. ZIP got both streaming writes and random-access reads. That’s the trade that made it win.

The Backwards Scan Is Fuzzier Than It Sounds

The EOCD record is 22 bytes, so you’d think a reader could just read the last 22 bytes and be done.

It can’t, because the record ends with a variable-length archive comment of up to 65,535 bytes. The signature isn’t at a fixed offset from the end of the file. So a reader has to seek near the end and scan backwards looking for the four-byte signature, potentially across 65,557 bytes.

Searching for a magic number is not the same as knowing where a structure is. If those four bytes happen to appear inside the comment, or inside compressed data near the end of the file, a naive parser can lock onto the wrong one. Different implementations pick different candidates when there’s more than one. This is a recurring source of “this archive opens in one tool and not another.”

You Can Put Anything in Front of a ZIP

If a reader finds the archive by scanning backwards from the end, then whatever sits at the front of the file is not the reader’s problem.

Take a valid 69-byte PNG, take the 241-byte ZIP, and concatenate them with cat. No special tooling:

$ file polyglot.png
polyglot.png: PNG image data, 1 x 1, 8-bit/color RGB, non-interlaced

$ unzip -l polyglot.png
  Length      Date    Time    Name
---------  ---------- -----   ----
       12  08-10-2026 16:44   hello.txt
       13  08-10-2026 16:44   second.txt
---------                     -------
       25                     2 files

One 310-byte file. An image viewer reads the PNG signature at byte 0 and renders an image. An archive tool scans backwards, finds the EOCD, and extracts two files. Both are correct. Neither is being fooled by a trick; they’re each doing exactly what their format says to do.

This is the mechanism behind self-extracting archives, where the front of the file is a real executable and the back is a real ZIP. The same property is why “GIFAR” attacks worked: a file that a server accepted as a harmless image was loaded by Java as an archive of classes.

It also means the offsets inside the Central Directory are relative to the start of the archive, not the start of the file, and readers have to work out that difference. Prepending data shifts everything, and well-behaved parsers cope by computing the delta between where the EOCD says the directory should be and where it found it.

Two Indexes, One File

Back to that detail from earlier: every file’s name and metadata are stored twice, in the Local File Header and again in the Central Directory.

Nothing enforces that they agree.

Here’s the same archive with only the Central Directory copy of the first filename patched from hello.txt to BOGUS.txt. The local header is untouched:

$ unzip -l mismatch.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
       12  08-10-2026 16:44   BOGUS.txt
       13  08-10-2026 16:44   second.txt

  local file header at offset 0 still says: hello.txt

The archive is not corrupt. unzip lists it happily. It just contains two different answers to “what is this file called,” and which one you get depends on which structure your parser decided to trust.

Now imagine two programs reading the same archive, one checking a signature and the other extracting files. That’s the Android “Master Key” bug from 2013, and the detail is better than the summary.

An APK is a ZIP. The attacker puts two entries in it, both named classes.dex. Android’s Java verifier loaded entries into a map keyed by filename, so a duplicate name overwrote the earlier one and the last entry was the one whose signature got checked. The native installer used a hash table with linear probing that didn’t replace on collision, so the first entry was the one that got loaded and run. Plant malicious code first, legitimately signed code second, and the device verifies one file and executes the other.

A second bug the same year came from the same “two readings, one file” family, via a signed integer. The extra-field length is a 16-bit value, and the Java code read it signed. A length of 65,533 (0xFFFD) sign-extends to −3. Since the offset of the compressed data is computed by adding that length, a negative value moves the read pointer backward into the header region instead of forward past it.

The lesson generalizes past ZIP. Any format that stores the same fact twice has to decide what happens when the copies disagree, and “the spec doesn’t say” is the same answer as “attackers decide.”

Offsets Are Just Numbers

The Central Directory locates each file by offset. Nothing in the format says two entries can’t point at the same bytes.

The classic zip bomb didn’t need that. 42.zip is 42 kilobytes of archives nested five layers deep, sixteen at each layer, unpacking to roughly 4.5 petabytes. The defense is obvious once you’ve seen it: cap recursion depth, don’t auto-extract nested archives.

David Fifield’s 2019 construction doesn’t recurse at all. It expands in a single pass, so depth limits are irrelevant. The trick is overlap: many Central Directory entries reference one shared kernel of compressed data, and each entry’s compressed stream uses DEFLATE’s stored-block mode to quote the next entry’s local file header as literal bytes. Entries nest inside each other, and output grows quadratically against input.

He published several, and they aren’t interchangeable:

File	Compressed	Uncompressed	Ratio	Needs Zip64
`zbsm.zip`	42 KB	5.5 GB	~130,000:1	No
`zblg.zip`	10 MB	281.4 TB	~28,000,000:1	No
`zbxl.zip`	46 MB	4.5 PB	~98,000,000:1	Yes

The Zip64 requirement on the largest one matters, because not every reader supports Zip64, which makes the merely-enormous version the more portable weapon.

None of these are malformed files. Every one is a valid archive that a conforming parser is supposed to accept. The format allows two entries to describe the same bytes, and no rule anywhere says the total uncompressed size has to bear any relationship to the file you’re holding.

Everything Is Secretly a ZIP

Once you know the structure, you start recognizing it:

.docx, .xlsx, .pptx are ZIP archives of XML
.jar, .war, .apk are ZIP archives of class files and resources
.epub is a ZIP of XHTML
.odt, .ods are ZIP of XML again

That’s not a coincidence or a hack. ISO/IEC 21320-1, “Document Container File,” defines a constrained ZIP profile for exactly this use. It narrows the format so a .docx reader doesn’t have to implement all of ZIP’s accumulated history: compression must be stored or deflated and nothing else, and the various encryption and digital-signature mechanisms in the original spec are all forbidden.

It’s a narrowing, not a rewrite. Zip64 version 1 is still permitted, for instance; only version 2 is ruled out. The profile is best understood as a list of the parts of ZIP that turned out to be a bad idea.

Which means the next post in this series is mostly about a ZIP file with XML inside it. You already know half of how a Word document works.

Sources

PKWARE APPNOTE.TXT — the original and still-authoritative ZIP specification, currently version 6.3.10; §4.3.16 defines the end of central directory record
ISO/IEC 21320-1:2015 — the constrained ZIP profile used by document formats. Fair warning, this one is a paid ISO standard; the catalog page tells you what it covers but you cannot read the text without buying it
Library of Congress format description for ZIP — history and preservation notes
David Fifield: A Better Zip Bomb — the overlapping-stream construction

I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @logan@llbbl.blog.

Zip on LLBBL Blog