Why File Size Checks Miss ZIP Corruption

When unpacking an archive, conventional client tools inspect the local file header or central directory record, decompress the payload using the browser's native DecompressionStream('deflate-raw'), and compare the resulting buffer length against the declared uncompressedSize. If you compress a 429-byte text file, decompress it, and receive 429 bytes, standard logic assumes the job succeeded. However, length measurement is fundamentally blind to byte alteration: - A transmission glitch or bit-flip on disk corrupts data without changing the total byte count. - If byte 42 of your binary payload flips from 0x4A to 0xB5, the file is still exactly 429 bytes long. - Handing those corrupted bytes to the user risks silent data destruction—from corrupted SQLite database headers to malfunctioning binary executables. A length check cannot detect corruption. Only an independent mathematical checksum of the original bytes can distinguish intact data from damaged storage.

The PKWARE ZIP specification mandates that every entry record its original uncompressed content as an IEEE 802.3 32-bit Cyclic Redundancy Check (crc32). In lib/tools/archive/zip-reader.ts, our extraction pipeline executes a strict verification contract: 1. Header Parsing: The central directory provides the authoritative 32-bit CRC32 integer (entry.crc32). 2. Decompression: The compressed slice is piped through DecompressionStream('deflate-raw'). 3. Buffer Check: The uncompressed length is validated against entry.uncompressedSize. 4. CRC-32 Recomputation: The inflated buffer is passed through the IEEE 802.3 CRC32 lookup table: ``typescript const actual = crc32(data); if (actual !== entry.crc32) { throw new Error( "${entry.path}" failed its checksum — the archive expects ${entry.crc32.toString(16).padStart(8, '0')} and the data gives ${actual.toString(16).padStart(8, '0')}. The file is damaged. ); } `` If even a single byte differs, the polynomial computation yields a completely divergent 32-bit integer, immediately halting extraction.

We do not assume this check functions—we pin it with automated browser end-to-end testing in e2e/archive-toolkit.spec.ts. In the test named *"refuses a damaged file instead of handing it over"*: 1. The test loads stored.zip from disk. 2. It locates the payload byte offset of readme.txt. 3. It performs a bitwise XOR flip on exactly one byte: bytes[dataStart] ^= 0xff. 4. The file length remains identical. 5. The browser loads the archive into /file/archive and clicks "Take out". The result is deterministic: the UI immediately catches the mismatch, renders an alert reading failed its checksum, and displays zero download or save buttons. The user is protected from receiving damaged files.

Beyond checksum validation, local archive extraction must defend against Zip Slip directory traversal attacks. A malicious archive can define an entry path such as ../../.ssh/authorized_keys or ../../../../etc/passwd. If extracted naively, it overwrites critical files on the operating system. Our reader inspects every entry path before extraction: - Flags root-relative paths (/foo, C:\foo). - Rejects entries containing folder-traversal components (..). - Refuses non-printable control characters that mask authentic paths. All warnings are highlighted in the UI index before any file is saved.

CRC32 is a cyclic redundancy check, designed for accidental corruption on storage and transmission channels. Its guarantees are precise and worth knowing rather than assuming.

A 32-bit CRC with a well-chosen polynomial — ZIP uses 0xEDB88320 in its reflected form — reliably detects:

• any single-bit error;
• any two-bit error within a very large window;
• any odd number of bit errors;
• any burst error shorter than 33 bits, which is the common failure mode for damaged storage and dropped packets.

For random corruption beyond those classes, the probability of a collision is approximately 1 in 2^32, about one in 4.3 billion.

What it categorically does not provide is tamper detection. CRC32 is a linear function, which means an attacker who modifies file contents can compute exactly which further bits to change to restore the original checksum. That is not a weakness in the implementation; it is arithmetic. Anyone verifying authenticity rather than integrity needs a cryptographic hash such as SHA-256, or a signature.

The practical framing: CRC32 answers "did this arrive intact?" and never "did this come from who I think?"

Comparing the uncompressed byte count against the expected figure is the check most extraction code performs, and it detects only one failure mode: truncation.

It cannot see a flipped bit, a swapped block, a corrupted byte in the middle of a stream, or a decompression that produced the right length from the wrong data. All of those produce a file of exactly the expected size that is nonetheless wrong.

This matters most for the formats where corruption is silent. A damaged JPEG usually looks visibly wrong. A damaged CSV, SQL dump, or configuration file frequently opens without complaint and is simply incorrect — which is discovered much later, after the data has been used.

The ZIP format already stores the correct answer: every entry carries a CRC32 computed at compression time, in both the local header and the central directory. Verifying costs one pass over the decompressed bytes, which for a browser-based extractor is work already being done as the data streams out of the inflater.

The reason many tools skip it is that failing loudly is inconvenient. It is nonetheless the right behaviour: a file that fails its checksum should be reported, not silently handed over, because the alternative is a user acting on data that is quietly wrong.