Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A better zip bomb (2019)

bamsoftware.com

Post reply on HN
Print view View original

41–50 of 60 posts

Re: A better zip bomb (2019)

#41

Post by Retr0id »

nwallin wrote: post #33
est wrote: post #22

I wonder if there's any reverse zip-bombs? e.g. A realy big .zip file, takes long time to unzip, but get only few bytes of content. Like bomb the CPU time instead of memory.

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.

There are also deflate-specific tricks you can use - just spam empty non-final blocks ad infinitum.

    import zlib
    zlib.decompress(b"\x00\x00\x00\xff\xff" * 1000 + b"\x03\x00", wbits=-15)
If you want to spin more CPU, you'd probably want to define random huffman trees and then never use them.

Re: A better zip bomb (2019)

#42

Post by tjpnz »

colechristensen wrote: post #7
kleiba wrote: post #2

In one of my previous jobs, I got laid off in the most condescending way, only to be asked days later by my former boss to send her some documents. If only I knew about this then...

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

Nothing wrong with getting some satisfaction. Just don't do it in a way that can be traced back to you.

Re: A better zip bomb (2019)

#43

Post by NaOH »

dang wrote: post #38

Related. Others? A better zip bomb [WOOT '19 Paper] [pdf] - https://news.ycombinator.com/item?id=20685588 - Aug 2019 (2 comments) A better zip bomb - https://news.ycombinator.com/item?id=20352439 - July 2019 (131 comments)

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)

Re: A better zip bomb (2019)

#44

Post by jclarkcom »

lossyalgo wrote: post #12
colechristensen wrote: post #7

Earlier quoted context omitted.

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

Is it a felony to crash someone's computer?

Would it even crash a computer? They would fill up their hard drive but that would just yield warnings to the user in most operating systems. Chances are they would kill it manually because it would take a long time

Re: A better zip bomb (2019)

#45

Post by tonyedgecombe »

st_goliath wrote: post #26
arjie wrote: post #14

The fact that ZIP files include the catalog/directory at the end is such nostalgia fever. Back in the day it meant that if you naïvely downloaded the file, a partial download would be totally useless. Fortunately, in the early 2000s, we got HTTP's Range and a bunch of zip-aware downloaders that would fetch the catalog first so that you could preview a zip you were downloading and even extract part of a file! Good tim…

> ... 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 c…

XPS (Microsoft's alternative to PDF) supported this. XPS files were ZIP files under the hood and were handled directly by some printers. The problem was the printer never had enough memory to hold a large file so you had to structure the document in a way it could be read a page at a time from the start.

Re: A better zip bomb (2019)

#46

Post by necovek »

btilly wrote: post #36
nwallin wrote: post #32

Earlier quoted context omitted.

At work, our daily build (actually 4x per day) is a handful of zip files totaling some 7GB. The script to get the build would copy the archives over the network, then decompress then into your install directory. This works great on campus, but when everyone went remote during COVID it wasn't anymore. It went from three minutes to like twenty minutes. However. Most files change only rarely. I don't need all the files,…

How would this have compared to using rsync?

Not as much geek cred for using an off the shelf solution? ;)

Re: A better zip bomb (2019)

#47

Post by necovek »

danudey wrote: post #6
542458 wrote: post #4

Okay, so I know back in the day you could choke scanning software (ie email attachment scanners) by throwing a zip bomb into them. I believe the software has gotten smarter these days so it won’t simply crash when that happens - but how is this done; How does one detect a zip bomb?

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 decomp…

I wonder if this has actually been used for backing up in real use cases (think how LVM or ZFS do snapshotting)?

I.e. an advanced compressor could abuse the zip file format to share base data for files which only incrementally change (get appended to, for instance).

And then this patch would disallow such practice.

Re: A better zip bomb (2019)

#48

Post by shakna »

measurablefunc wrote: post #16

Decompression is equivalent to executing code for a specialized virtual machine. It should be possible to automate this process of finding "small" programs that generate "large" outputs. Could even be an interesting AI benchmark.

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-...

Re: A better zip bomb (2019)

#49

Post by Retr0id »

Retr0id wrote: post #41
nwallin wrote: post #33

Earlier quoted context omitted.

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.

There are also deflate-specific tricks you can use - just spam empty non-final blocks ad infinitum. import zlib zlib.decompress(b"\x00\x00\x00\xff\xff" * 1000 + b"\x03\x00", wbits=-15) If you want to spin more CPU, you'd probably want to define random huffman trees and then never use them.

I had claude implement the random-huffman-trees strategy and it works alright (~20MB/s decompression speed), but a minimal huffman tree that only encodes the end symbol works out even slower (~10MB/s), presumably because each tree is more compact.

The minimal version boils down to:

    bytes.fromhex("04c001090000008020ffaf96") * 1000000 + b"\x03\x00"

Re: A better zip bomb (2019)

#50

Post by hayley-patton »

zipping1549 wrote: post #28
est wrote: post #22

I wonder if there's any reverse zip-bombs? e.g. A realy big .zip file, takes long time to unzip, but get only few bytes of content. Like bomb the CPU time instead of memory.

Isn't that mathematically impossible?

I'm pretty sure it's mathematically guaranteed that you have to be bad at compressing something. You can't compress data to less than its entropy, so compressing totally random bytes (where entropy = size) would have a high probability of not compressing at all, if no identifiable patterns appear in the data by sheer coincidence. Establishing then that you have incompressible data, the least bad option would be to signal to the decompressor to reproduce the data verbatim, without any compression. The compressor would increase the size of the data by including that signal somehow. Therefore there is always some input for a compressor that causes it to produce a larger output, even by some miniscule amount.
Post reply on HN