> ... a partial download would be totally useless ...

no, not totally. The directory at the end of the archive points backwards to local headers, which in turn include all the necessary information, e.g. the compressed size inside the archive, compression method, the filename and even a checksum.

If the archive isn't some recursive/polyglot nonsense as in the article, it's essentially just a tightly packed list of compressed blobs, each with a neat, local header in front (that even includes a magic number!), the directory at the end is really just for quick access.

If your extraction program supports it (or you are sufficiently motivated to cobble together a small C program with zlib....), you can salvage what you have by linearly scanning and extracting the archive, somewhat like a fancy tarball.

Partial zip shouldn't be totally useless and a good unzip tool should be able to repair such partial downloads. In addition to catalog at end zip also have local headers before each file entry. So unless you are dealing with maliciously crafted zip file or zip file combined with something else, parsing it from start should produce identical result. Some zip parsers even default to sequential parsing behavior.

This redundant information has lead to multiple vulnerabilities over the years. As having redundant information means that a maliciously crafted zip file with conflicting headers can have 2 different interpretations when processed by 2 different parsers.

Partial downloads weren't useless, though, as other commenters have said.

The PKZIP tools came with PKZIPFIX.EXE, which would scan the file from the beginning and rebuild a missing central archive. You could extract any files up to the truncated file where your download stopped.

I hate that the most common video container on the web does this too. Most non-"stream-ready" mp4 files lack even the basic information such as height/width until the file has completed loading.[1]

  [1]: https://forum.videohelp.com/threads/393096-Fixing-Partially-Download-MP4-Files

Well what do you want it to do, it doesn't know full directory with offsets until it's done compressing and dispersed directory would have lousy access pattern for quick listing. And you know, if you are compressing you probably want the smallest file so duplicate directories are not idea.

Yep, these kinds of format shenanigans are increasingly rejected for security reasons. Not zip bombs specifically, but to prevent parser mismatch vulnerabilities (i.e. two parser implementations decompressing the same zip file to different contents, without reporting an error).

I think these mitigations are misguided and I've had false-positives at least once. Rather than caring about structural details (overlapping files etc.), decompressors should just limit the overall decompression ratio by default (bytes in vs bytes out). It shouldn't matter how the ratio is achieved.

Trivially. Zip file headers specify where the data is. All other bytes are ignored.

That's how self extraction archives and installers work and are also valid zip files. The extractor part is just a regular executable that is a zip decompresser that decompresses itself.

This is specific to zip files, not the deflate algorithm.

Isn't that mathematically impossible?

You have bigger enemies more worthy of that personal risk. This comment bewilders me a bit.

Don't commit felonies because you're unhappy with your former employer.

A valid HTML zip bomb - https://news.ycombinator.com/item?id=44670319 - July 2025 (37 comments)

I use zip bombs to protect my server - https://news.ycombinator.com/item?id=43826798 - April 2025 (452 comments)

How to defend your website with ZIP bombs (2017) - https://news.ycombinator.com/item?id=38937101 - Jan 2024 (75 comments)

The Most Clever 'Zip Bomb' Ever Made Explodes a 46MB File to 4.5 Petabytes - https://news.ycombinator.com/item?id=20410681 - July 2019 (5 comments)

Defending a website with Zip bombs - https://news.ycombinator.com/item?id=14707674 - July 2017 (183 comments)

Zip Bomb - https://news.ycombinator.com/item?id=4616081 - Oct 2012 (108 comments)

I don't understand the code itself, but here's Debian's patch to detect overlapping zip bombs in `unzip`:

https://sources.debian.org/patches/unzip/6.0-29/23-cve-2019-...

    The detection maintains a list of covered spans of the zip files
    so far, where the central directory to the end of the file and any
    bytes preceding the first entry at zip file offset zero are
    considered covered initially. Then as each entry is decompressed
    or tested, it is considered covered. When a new entry is about to
    be processed, its initial offset is checked to see if it is
    contained by a covered span. If so, the zip file is rejected as
    invalid.

For any compression algorithm in general, you keep track of A = {uncompressed bytes processed} and B = {compressed bytes processed} while decompressing, and bail out when either of the following occur:

1. A exceeds some unreasonable threshold

2. A/B exceeds some unreasonable threshold

Many of them already do this. [0]

It is a much easier problem to solve than you would expect. No need to drag in a data centre when heuristics can get you close enough.

[0] https://sources.debian.org/patches/unzip/6.0-29/23-cve-2019-...

My guess is this is a subset of the halting problem (does this program accept data with non-halting decompression), and is therefore beautifully undecidable. You are free to leave zip/tgz/whatever fork bombs as little mines for live-off-the-land advanced persistent threats in your filesystems.

Previously: I use zip bombs to protect my server (idiallo.com) 1076 points https://news.ycombinator.com/item?id=43826798

There was https://idiallo.com/blog/zipbomb-protection earlier this year. It sends highly compressed output of /dev/zero. No overlapping files or recursively compressed payloads.

Added. Thanks!