Your browser is obsolete!

The page may not load correctly.

  • add to favourites
    Add to Bookmarks

Dr.Web the anti-bomber

Read: 15352 Comments: 9 Rating: 14

Monday, August 5, 2019

Files can be archived to save disk space, and users aren’t the only ones who find this convenient—cybercriminals do, too.

We’ve already written about zip bombs in the issues Bombs and evolution and The mother of all bombs!. Let's recall what these are.

These are zip archives containing files whose size will increase manifold if they are extracted. For example, one of the most notorious zip bombs,, only occupies 42 KB, but it contains files on 5 nesting levels, with 16 files per level. The size of each file at the last level is 4.3 GB, and the entire archive unpacked will occupy 4.5 petabytes.



A file stuffed, for example, with multiple 1s can be a zip bomb. And an archive is essentially a small file indicating that the number 1 needs to be written repeatedly to the file many times. As a result, the archive is small, but the output file is huge. It’s a no-brainer really.

But this is the simplest implementation. Not long ago a more sophisticated zip bomb appeared.

This article shows how to construct a non-recursive zip bomb that achieves a high compression ratio by overlapping files inside the zip container. "Non-recursive" means that it does not rely on a decompressor recursively unpacking zip files nested within zip files: it expands fully after a single round of decompression. The output size of the zip bomb increases quadratically from the input size.


Anti-viruses are known to decompress all the files they analyse.

Files like this one should instantly be marked as malicious and deleted. They definitely don’t contain any legitimate files.

Should anti-viruses start leaving some compressed files unexamined, attackers will take advantage of this and start transferring the files to target machines by hiding them on lower layers in nested archives.

Tavis Ormandy pointed out that some anti-virus engines timed out instead of identifying as a malicious file (screenshot dated June 6, 2019): AhnLab-V3, ClamAV, DrWeb, Endgame, F-Secure, GData, K7AntiVirus, K7GW, MaxSecure, McAfee, McAfee-GW-Edition, Panda, Qihoo-360, Sophos ML, and VBA32. Scan results for (dated June 6, 2019) look similar, although the engines that timed out aren't exactly the same: Baido, Bkav, ClamAV, CMC, DrWeb, Endgame, ESET-NOD32, F-Secure, GData, Kingsoft, McAfee-GW-Edition, NANO-Antivirus, and Acronis.

Hmmm. Let's test it again!

Attention! In the comments made about the above-mentioned article, users noted that some browsers automatically start extracting the contents of archives. Well, that can be disastrous for obvious reasons.

I downloaded the smallest 5 gigabyte file, and Chrome immediately started to unpack it, although I never asked it to.

And I did download it. As a consequence, my C partition became unresponsive.

The same thing happened with Yandex.Browser.

Vivaldi couldn't cope with it either. So I just loaded the kernel to process the data, and now it’s frozen.

Edge, however, handled it without a hitch.

We downloaded the files with Firefox.

The article described three variants of the new bombs.

  • 42 KB → 5.5 GB
  • 10 MB → 281 TB
  • 46 MB → 4.5 PB (Zip64)

Let's scan them one by one.


We won't post the results for all the archives here. Here’s what we got for zbsm:


Dr.Web even managed to detect malware in one of the archives:


We experienced no performance issues whatsoever.


The Anti-virus Times recommends

Use Dr.Web—it even scans files that can be concealed using unknown compression formats. No bombs can break us!


Tell us what you think

To leave a comment, you need to log in under your Doctor Web site account. If you don't have an account yet, you can create one.