ZIP Unpack & Extract

ZIP extraction opens an archive and restores the files stored inside it. People use ZIP extraction when they receive a compressed package, want to inspect its contents before downloading everything, need only one file from a bundle, or want to verify filenames and sizes before trusting an archive. ZIP extraction is lossless for normal files, but it does not make unknown content safe. Archives can contain misleading filenames, unexpected folders, very large expanded data, or files that should not be opened without antivirus scanning. This browser tool reads the archive locally and lets you download selected files, which is convenient for small checks. It does not recreate a full folder tree on disk or replace careful security review for suspicious archives.

Reading a ZIP archive proceeds in the reverse order of writing one. The browser receives the file as an `ArrayBuffer` via the File API (`file.arrayBuffer()`) and the reader scans backward from the file tail looking for the End of Central Directory signature `0x06054b50` (PK\x05\x06). EOCD is at most 22 bytes plus an optional comment of up to 65,535 bytes, so the scan window is bounded. EOCD points at the offset and size of the Central Directory, which holds one File Header (`0x02014b50`) per entry. Each File Header carries the compressed and uncompressed sizes, CRC-32, compression method, filename, and the offset of the matching Local File Header (`0x04034b50`). The reader can then seek directly to any individual entry without parsing the entries before it — which is why single-file extraction from a multi-GB backup is fast. Decompression depends on the method byte: `0x00` is stored (no compression, just a memcpy), `0x08` is DEFLATE per RFC 1951 (~99% of archives in the wild), `0x0C` is BZIP2, `0x0E` is LZMA, and `0x5D` is the older PPMd. This tool uses JSZip (or fflate for higher throughput — fflate's `unzipSync` decodes a typical 10 MB DEFLATE archive in tens of milliseconds, several times faster than JSZip). After decompression the CRC-32 of the raw bytes is recomputed and compared against the value in the central directory; a mismatch indicates corruption or tampering. Two security concerns matter for any extraction code path. The first is the Zip Slip vulnerability (Snyk, 2018): a malicious archive can contain entries with path traversal sequences like `../../etc/passwd`, and a naive extractor that joins the entry name to a target directory will write outside the intended sandbox. The fix is to normalise the joined path with `path.resolve()` and verify it still starts with the target directory before any write. This tool offers each entry as an individual browser download via `URL.createObjectURL(new Blob([bytes]))` and the browser sandboxes the destination, so directory traversal cannot escape the user's Downloads folder, but the same archive on a server-side extractor would be exploitable. Second, encrypted archives are not handled: traditional ZipCrypto is a 32-bit stream cipher that is trivially broken with a known-plaintext attack of three bytes, and modern WinZip AES-256 (PKWARE APPNOTE 7.0) requires the AE-2 extra field with HMAC-SHA1 authentication — neither path is implemented here. Archives over 4 GiB rely on the ZIP64 extension's extra fields for 64-bit sizes and offsets, which the parser must read instead of the 32-bit central directory fields.

• Parse order: scan backward from file tail for EOCD signature `0x06054b50` (max 22 + 65535 bytes from end) → seek to Central Directory → seek to each Local File Header.
• Compression methods: `0x00` stored, `0x08` DEFLATE (RFC 1951, ~99% of archives), `0x0C` BZIP2, `0x0E` LZMA, `0x5D` PPMd.
• Integrity: CRC-32 with polynomial `0xEDB88320` (reversed IEEE 802.3) recomputed on extracted bytes and compared against the central directory value.
• Zip Slip (Snyk 2018): entries with `../` path traversal can write outside the extraction directory; fix by normalising and validating the resolved path before write.
• Browser implementation: `File.arrayBuffer()` → JSZip / fflate `unzipSync()` → per-entry `URL.createObjectURL(new Blob([bytes]))` for downloads, no server round trip.
• Encryption is not handled: ZipCrypto is broken in 3 known-plaintext bytes; WinZip AES-256 (APPNOTE 7.0, AE-2 extra field with HMAC-SHA1) is not implemented here.
• ZIP64 (APPNOTE 4.5+) extends 32-bit size/offset fields to 64-bit via extra fields; required for archives or single entries above 4 GiB (2³² − 1 bytes).