Zip bomb revisited

The upcoming 0.9.2 release of the Profiler removes the virtual memory constraint, meaning that it is now able to open and process files of any size (the hex editor can edit large files as well). This feature has actually been in the TODO list from day 1 and I’ll write about the internals of it in some other post, in order to better demonstrate the capabilities gained by these changes to the core.

Also, because of the increased functionality, it made sense to add detection for Zip (decompression) bombs. Almost a year ago we’ve talked about Zip bombs, but it was limited to the safe exploration of such files. Let’s start with the new ‘Limits’ page in the setup.


  • What had been once the maximum size of a file is now the size of virtual memory the memory pool is allowed to use. Of course, the more virtual memory is granted, the faster it becomes to analyze large files. But it’s only a matter of speed, you can choose to give to the pool the bare minimum, it’ll work just as well.
  • The nesting option shouldn’t need any explanation since it hasn’t changed. But just for completeness: it specifies the maximum level of scanning into a root object. If more levels are available, it is signaled. For instance, level 0 specifies that children objects should not be scanned automatically (though they might still be opened manually by the user).
  • The maximum file size can be used to discard files larger than the specified size during batch scan operations. The default is 0, which stands for infinite.
  • The decompression bomb threshold is the limit we’re interested in for this post. It represents a cumulative size which can’t be exceeded. In other words if an archive contains 1 file of 100+ GBs (let’s use this number for the purpose of this example) it’s the same as whether one sub-archive contains 100 files of 1 GB each (plus a single byte in excess). If the threshold is exceeded, it will be reported as a threat. While 100 GBs is the default, you can speed up scanning by specifying a lower limit.
  • The maximum number of children files is cumulative as well. This constraint depends on virtual memory limitations (as all children are shown in a tree). 100.000 (the default) is a safe choice. If more children than the imposed limit are present, it is signaled.

So let’s again take the famous as an example of Zip bomb and let’s scan it. We’ll get this in the summary:

Decompression bomb threat

Please note that the threat may not be reported in the summary of the root object itself, but in one of its children objects (once the bomb threshold has indeed been exceeded). But since we know there’s a threat (as reported by the risk factor) we can just jump to it by pressing F2 in the hierarchy view.

Zip bomb

While the Profiler was designed for document analysis and currently has virtual memory limitations, let’s see how it performs with a Zip bomb. 🙂

A friend of mine linked me the Zip file on this page.

The file contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped, which again contains 16 zipped files, which contain 1 file, with the size of 4.3GB.

That’s 16^5 or 1048576 files. If we try to scan it with the Profiler, it will just take endless time trying to scan all the files. It won’t crash nor exhaust memory, just take ages. But we want to analyze the file right now, so how do we do it?

It’s very easy. By default the Profiler has quite a huge nesting limit (10), we can decrease that limit from the Setup -> Limits page. The nesting limit tells the Profiler at which depth of embedding/referencing the scan should stop.

Nesting limit

In this case I have decreased it to 1, but 2 or 3 would still have been reasonable. A value of 1 means that only files at the first level will be analyzed. By inserting a value of 0, the file will be opened without any scanning of sub-files.

Zip bomb level 1

But what if we want to analyze more in depth one or more branches in the hiearchy? The nesting limit applies only to automatic analyzes, not to manual ones, which means that we can activate items and get the analysis for them (and their children).

Zip bomb manual analysis

As you can see, we’re now analyzing the Zip bomb at the fourth level of nesting. 🙂

Zip archives support

Among other additions, the new 0.7.8 version of the Profiler features support for Zip archives and an improved interface for displaying the file hierarchy.

Zip Archive

The supported decompression methods are Deflate and BZIP2 (more will be added). All popular encryption technologies are supported: ZipCrypto and WinZip AES. Support for the undocumented and proprietary PKWare encryption technology is still missing.

One of the handy UI improvements is the in depth risk report.

Risk tooltip

In this case the global risk signals that the calculated risk is 45% but could be more because some files could not be analyzed, since their format is not supported. This risk reporting is available both for the global risk and individual files.

Risk tooltip 2

In this case the main file “” was decrypted but the decryption of the embedded file “” failed, because I didn’t enter the password for it. We can see that “” has not been decrypted (nor the files it contains) because of the e character next to the risk percentage. The meaning of these kind of characters is explained by the tooltip.

The Zip format covers an enourmous amount of extensions and hugely increases the usefulness of the Profiler. Enjoy! 😉