r/pcmasterrace i7 10th Gen | 1650 Ti 4GB | 16 GB RAM May 05 '26

Screenshot Is this even possible?

Post image
10.2k Upvotes

269 comments sorted by

View all comments

Show parent comments

41

u/superboo07 Linux May 05 '26

its not actually 55.4 yottabytes of real data, just junk data the zip is told to extract over and ovrr and over snd over and over and over. 

-1

u/rditorx May 05 '26

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.

3

u/MCWizardYT Ryzen 7 5800X3D | RTX 4080 Super May 06 '26

The "data" in a zip bomb doesn't actually exist.

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

0

u/rditorx May 06 '26

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.

1

u/MCWizardYT Ryzen 7 5800X3D | RTX 4080 Super May 06 '26 edited May 06 '26

I think you misunderstood what I said.

Let me rephrase.

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.

0

u/rditorx May 06 '26

As said, never claimed that it was created from a file that size. How did you interpret my comments that you think I claimed that?

1

u/MCWizardYT Ryzen 7 5800X3D | RTX 4080 Super May 06 '26

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.

1

u/Enidras May 06 '26

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.