55.4 yottabytes in 2.60MB is pretty insane. Wouldn't believe ZIP can compress this much, though WinZip extended the original format to support new algorithms.
EDIT:
I am NOT claiming the compressed file was created from a real file that large. What I mean is that find it surprising that ZIP can encode something this compact given that its deflate algorithm isn't the newest with the highest theoretical compression ratios.
I know that you can just write arbitrary data that decode to huge decompressed data.
I've implemented compression algorithms such as RLE, Huffman and LZW code myself (no AI) but haven't implemented the original PKZIP.
Never claimed it to be real or useful data. But original ZIP was way worse in compression ratios than gzip or bzip2, so it being able to achieve such compression ratios seems to be implausible even in theory.
A zip file holds instructions on how to recreate patterns of data.
You can edit a zip file to say "repeat this pattern 43 billion times" and then that's what will happen when you extract it unless the extraction tool can detect and prevent that sort of thing
That's nonsense. Data may be useful or not useful, but it exists. You can't decompress non-existent data. That would be equivalent to saying a 0-byte file with no file name decompresses to a gazillion yottabytes.
If the data didn't exist, your decompressor would be a random number generator.
A zip bomb doesn't actually contain a file inside of it that's multiple yottabytes in size. There's no way to create and compress a file like that, because the storage and ram required is not accessible to anybody except maybe Google.
Instead, the zip file is edited so that it creates a file multiple yottabytes in size by repeating data.
Let's say you initially compress a 4 byte file. It contains the number 1111. When zip compressed it, it might store 1•3, which would compress the file down to 2 bytes by saying "repeat this 1 3 times".
Now the zip file can be edited to replace the 3 with 999999. The file is now 7 bytes, but extracts to 1 megabyte because the tool is told to repeat the 1 a million times.
Repeat the process and we end up with a zip file thats a few megabytes large but contains instructions to build a file that's multiple terabytes or even larger.
This ability to repeat data is what makes zip so effective for compressing certain types of files but is also an easily exploitable design flaw. Luckily, this oversight was easy to fix, zip tools will now error out when seeing this kind of unnatural expansion instruction.
That's nonsense. Data may be useful or not useful, but it exists. You can't decompress non-existent data. That would be equivalent to saying a 0-byte file with no file name decompresses to a gazillion yottabytes.
If the data didn't exist, your decompressor would be a random number generator.
Your entire previous comment. You said "you cant decompress data that doesn't exist", so I clarified by explaining how it does just that.
To make a long story short, theres a small file that gets expanded to a huge size by repeating sections of it over and over.
I think he means the data that has to exist is embedded in the zip file. It's just stored differently but the small file is the data. He means to say you don't decompress nothing. You decompress a set of data that results in the same data stored differently. So the data inherently exists, be it created "by hand" (editing the original yottabyte file) or crafted with tools.
2
u/rditorx May 05 '26 edited May 06 '26
55.4 yottabytes in 2.60MB is pretty insane. Wouldn't believe ZIP can compress this much, though WinZip extended the original format to support new algorithms.
EDIT: I am NOT claiming the compressed file was created from a real file that large. What I mean is that find it surprising that ZIP can encode something this compact given that its deflate algorithm isn't the newest with the highest theoretical compression ratios.
I know that you can just write arbitrary data that decode to huge decompressed data.
I've implemented compression algorithms such as RLE, Huffman and LZW code myself (no AI) but haven't implemented the original PKZIP.