Why File Size Checks Miss Corruption: ZIP CRC32 Checksum Validation in Browser RAM

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.