posted on Aug, 21 2016 @ 04:23 AM
a reply to:
DontTreadOnMe
A decompression bomb is designed to unzip a small file to an enourmous or even infinite size file. This is supposed to crash the AV program when
internal buffers overflow.
Like the famous "halting problem" in computation, you can't know that the file cannot be successfully unzipped until you try to do it, hence the
problem.
Avast decompresses in a VM and so a crash of the VM (which obviously has limited resources compared with the 'real' machine) could be taken to
indicate the action of a decompression bomb. It leaves the core program executing normally (which should start a new VM and continue with the next
file to scan, marking the suspect file as a potential threat or preferably, quarantining it).
Because the operating systems these days also have the capability of 'opening' zipped files, a decompression bomb can compromise OS function, too.
Where a file being scanned is not a decompression bomb but the VM crashes anyway, the AV can only assume that it must have been a decompression bomb.
Normally, file locking or permissions issues cannot crash a VM (the file-opening errorslevels are different) so it isn't likely to be a case of an
unreadable file causing a false positive.
It is possible that a file could randomly contain a sequence of data which will produce a large data-set if a decompression algorithm is applied. In
this case, the file would be a decompression bomb, but only by acident, not design. If no decompression algorithm is ever attempted, then the file is
inert and no danger.
edit on 21/8/2016 by chr0naut because: (no reason given)