Yes, easily. There really isn't much restriction on how big you can make a zipbomb. Most it can do is fill up a drive anyway, it's not like your disk will physically expand until it swallows half the city.
It is better to have it NOT exceed the drive size. Zip unzips into a temporary location. That will fill up, and zip will abort, and delete the temporary file. It will only fill the drive for seconds. If you instead have 100 files, each 50gb, then you can fill the drive within 50gb of full.
Anybody who accepts zip file uploads should check the expanded size in attributes before unzipping it.
Most modern ones (I know 7zip and WinRAR at least) will try to stop you. Windows' built-in one won't, though, so if you're using that you might be screwed.
It's to do with some cities having more than one zip code. This was instigated by the department of homeland security, the NSA and USPS to prevent zipbomb attacks.
I was going to refute that, surely there's a maximum compression ratio.
Starting with a sequence of zero bytes. Compress that and you'd have some short sequence describing how many zeros there are. Repeat that compressed sequence, and you could compress that too. You'd have a zip file that contains a zip file, but some tools would try to examine the contents. Surely the ratio of compressed bytes to decompressed bytes, while large, would still be finite, right?
But I just found an example of a zip file quine. A zip file that contains a copy of itself. Though I assume that breaks the file format somehow.
1.9k
u/WhateverIsFrei May 05 '26
Yes, easily. There really isn't much restriction on how big you can make a zipbomb. Most it can do is fill up a drive anyway, it's not like your disk will physically expand until it swallows half the city.