entityMap|blocks|key|43bs2|text|引用自维基百科页面：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4kpci|Zip炸弹的一个例子是文件45.1.zip，其是45.1千字节的压缩数据，|ftj3b|包含9层嵌套的zip文件，每组10个，每个底层归档文件包含一个1.30+10的文件|esbr9|总共1.30艾字节的未压缩数据。|d17ge|d9q2c|因此，您所需要的只是一个1.3+is的充满零的文件，将其压缩为ZIP文件，复制10个副本，将这些文件打包为ZIP文件，然后重复此过程9次。|5ef7v|这样，你得到一个文件，当完全解压时，它会产生一个荒谬的数据量，而不需要你从这个数量开始。|1hojc|此外，嵌套的归档文件使像病毒扫描程序(这些“炸弹”的主要目标)这样的程序变得更难聪明，并拒绝解压“太大”的归档文件，因为直到最后一层数据总量不是那么多，你才能“看到”最低层的文件有多大，直到你达到那个级别，并且每个单独的文件都不“太大”-只有巨大的数字才是有问题的。^0|0|0|0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|P|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|Q|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|R|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|S|9|@]|A|@]|B|$]]|$2|I|4|-4|6|7|8|T|9|@]|A|@]|B|$]]|$2|J|4|K|6|7|8|U|9|@]|A|@]|B|$]]|$2|L|4|M|6|7|8|V|9|@]|A|@]|B|$]]|$2|N|4|O|6|7|8|W|9|@]|A|@]|B|$]]]]

Citing from the Wikipedia page:

<blockquote>
 One example of a Zip bomb is the file
 45.1.zip which was 45.1 kilobytes of compressed data, containing nine
 layers of nested zip files in sets of
 10, each bottom layer archive
 containing a 1.30 gigabyte file for a
 total of 1.30 exabytes of uncompressed
 data.
</blockquote>

So all you need is one single 1.3GB file full of zeroes, compress that into a ZIP file, make 10 copies, pack those into a ZIP file, and repeat this process 9 times. 

This way, you get a file which, when uncompressed completely, produces an absurd amount of data without requiring you to start out with that amount. 

Additionally, the nested archives make it much harder for programs like virus scanners (the main target of these "bombs") to be smart and refuse to unpack archives that are "too large", because until the last level the total amount of data is not that much, you don't "see" how large the files at the lowest level are until you have reached that level, and each individual file is not "too large" - only the huge number is problematic.

entityMap|blocks|key|63tgq|text|创建一个1.3艾字节的零文件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|agbk|右键单击>发送到压缩(压缩)文件夹。^0|0^^$0|$]|1|@$2|3|4|5|6|7|8|E|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|F|9|@]|A|@]|B|$]]]]

Create a 1.3 exabyte file of zeros.

Right click > Send to compressed (zipped) folder.

entityMap|blocks|key|87kfo|text|在Linux下，使用以下命令可以轻松完成此操作：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|dq3r3|dd+if=/dev/zero+bs=1024+count=10000+%7C+zip+zipbomb.zip+-|a3416|将count替换为要压缩的KB数。上面的例子创建了一个10MiB的zip炸弹(根本不是一个炸弹，但它展示了这个过程)。|7ffai|您不需要硬盘空间来存储所有未压缩的数据。^0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|I|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|J|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|K|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|L|9|@]|A|@]|B|$]]]]

This is easily done under Linux using the following command:

<code>dd if=/dev/zero bs=1024 count=10000 | zip zipbomb.zip -</code>

Replace count with the number of KB you want to compress. The example above creates a 10MiB zip bomb (not much of a bomb at all, but it shows the process).

You DO NOT need hard disk space to store all the uncompressed data.

entityMap|blocks|key|co4u|text|下面是针对Windows的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|bm0su|从安全焦点概念验证(NSFW!)，它是一个包含16个文件夹的ZIP文件，每个文件夹包含16个文件夹，如下所示(42是zip文件名)：|cliru|\42\lib+0\book+0\第0章\doc+0\0.dll|37mfd|..。|4tv1n|\42\lib+F\book+F\章节F\doc+F\0.dll|7p2v4|8e8ca|我可能看错了这个数字，但它生成了4%5E16+(4,294,967,296)个目录。因为每个目录需要N字节的分配空间，所以它最终是巨大的。末尾的dll文件为0字节。|erlk7|已单独解压缩第一个目录\42\lib+0\book+0\chapter+0\doc+0\0.dll|4lbru|会产生4+4gb的分配空间。^0|0|0|0|0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|R|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|S|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|T|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|U|9|@]|A|@]|B|$]]|$2|I|4|J|6|7|8|V|9|@]|A|@]|B|$]]|$2|K|4|-4|6|7|8|W|9|@]|A|@]|B|$]]|$2|L|4|M|6|7|8|X|9|@]|A|@]|B|$]]|$2|N|4|O|6|7|8|Y|9|@]|A|@]|B|$]]|$2|P|4|Q|6|7|8|Z|9|@]|A|@]|B|$]]]]

Below is for Windows:

From the <a href="http://www.securityfocus.com/data/vulnerabilities/exploits/42.zip" rel="noreferrer">Security Focus proof of concept</a> (NSFW!), it's a ZIP file with 16 folders, each with 16 folders, which goes on like so (42 is the zip file name):

<blockquote>
 \42\lib 0\book 0\chapter 0\doc 0\0.dll 
 ... 
 \42\lib F\book F\chapter F\doc F\0.dll
</blockquote>

I'm probably wrong with this figure, but it produces 4^16 (4,294,967,296) directories. Because each directory needs allocation space of N bytes, it ends up being huge. The dll file at the end is 0 bytes.

Unzipped the first directory alone <code>\42\lib 0\book 0\chapter 0\doc 0\0.dll</code> results in 4gb of allocation space.

entityMap|blocks|key|fn1po|text|严肃的回答：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|7krbt|(基本上)压缩依赖于识别重复模式，因此zip文件将包含表示以下内容的数据|2ukm4|0x100000000000000000000000000000000000++
(Repeat+this+'0'+ten+trillion+times)|code-block|syntax|javascript|26vim|非常短的zip文件，但当你展开它时，它会变得很大。^0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|L|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|M|9|@]|A|@]|B|$]]|$2|E|4|F|6|G|8|N|9|@]|A|@]|B|$H|I]]|$2|J|4|K|6|7|8|O|9|@]|A|@]|B|$]]]]

Serious answer:

(Very basically) Compression relies on spotting repeating patterns, so the zip file would contain data representing something like

<pre><code>0x100000000000000000000000000000000000 
(Repeat this '0' ten trillion times)
</code></pre>

Very short zip file, but huge when you expand it.

entityMap|blocks|key|5ms29|text|要在实际环境中创建一个压缩后的文件(即，不在巨大的硬盘上创建一个1.3EB的文件)，您可能必须学习二进制级别的文件格式，并编写一些转换为您所需文件的压缩后外观的东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data^0^^$0|$]|1|@$2|3|4|5|6|7|8|C|9|@]|A|@]|B|$]]]]

To create one in a practical setting (i.e. without creating a 1.3 exabyte file on you enormous harddrive), you would probably have to learn the file format at a binary level and write something that translates to what your desired file would look like, post-compression.

entityMap|blocks|key|9fdso|text|这篇文章提到了9层zip文件，所以这不是一个简单的压缩一堆零的例子。为什么是9个文件，为什么每个文件有10个文件？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|7989g|82l1u|首先，维基百科的文章目前说有5层，每层有16个文件。不确定差异来自哪里，但这并不都是相关的。真正的问题是为什么首先要使用嵌套。|41bfj|DEFLATE，唯一通常支持的zip文件压缩方法*，最大压缩比为1032。对于任何1-3字节的重复序列，这可以渐进地实现。无论您如何处理zip文件，只要它只使用DEFLATE，解压后的大小将最多是原始zip文件大小的1032倍。|6cl79|因此，有必要使用嵌套zip文件来获得非常惊人的压缩比。如果你有两层压缩，最大比率变成1032%5E2+=+1065024。对于3，它是1099104768，以此类推。对于42.zip中使用的5层，理论上的最大压缩比是1170572956434432。如您所见，实际的42.zip远未达到该级别。一部分原因是zip格式的开销，另一部分原因是他们根本不在乎。|emsb9|如果要我猜的话，我会说42.zip是通过创建一个大的空文件，并反复压缩和复制它而形成的。没有试图突破格式的限制或最大化压缩或任何东西-他们只是随意选择每层16个副本。重点是不费太多力气就能创建一个大的有效负载。|62onf|注意:其他压缩格式，如bzip2，提供了更大、更大、更大的最大压缩比。但是，大多数zip解析器不接受它们。|db93c|备注:可以创建一个zip文件，将其解压缩为自身的副本(一个quine)。你也可以做一个解压成多个副本的文件。因此，如果您递归解压缩一个文件永远，最大可能的大小是无限的。唯一的限制是它在每次迭代中最多可以增加1032。|fa9q7|附注:+1032图假设zip中的文件数据是不相交的。zip文件格式的一个奇特之处在于，它有一个中央目录，其中列出了存档中的文件和文件数据的偏移量。如果创建指向相同数据的多个文件条目，即使没有嵌套，也可以获得更高的压缩比，但是这样的zip文件很可能会被解析器拒绝。^0|0|0|0|0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|R|9|@]|A|@]|B|$]]|$2|C|4|-4|6|7|8|S|9|@]|A|@]|B|$]]|$2|D|4|E|6|7|8|T|9|@]|A|@]|B|$]]|$2|F|4|G|6|7|8|U|9|@]|A|@]|B|$]]|$2|H|4|I|6|7|8|V|9|@]|A|@]|B|$]]|$2|J|4|K|6|7|8|W|9|@]|A|@]|B|$]]|$2|L|4|M|6|7|8|X|9|@]|A|@]|B|$]]|$2|N|4|O|6|7|8|Y|9|@]|A|@]|B|$]]|$2|P|4|Q|6|7|8|Z|9|@]|A|@]|B|$]]]]

<blockquote>
 The article mentions 9 layers of zip files, so it's not a simple case of zipping a bunch of zeros. Why 9, why 10 files in each?
</blockquote>

First off, the Wikipedia article currently says 5 layers with 16 files each. Not sure where the discrepancy comes from, but it's not all that relevant. The real question is why use nesting in the first place.

DEFLATE, the only commonly supported compression method for zip files*, has a maximum compression ratio of 1032. This can be achieved asymptotically for any repeating sequence of 1-3 bytes. No matter what you do to a zip file, as long as it is only using DEFLATE, the unpacked size will be at most 1032 times the size of the original zip file.

Therefore, it is necessary to use nested zip files to achieve really outrageous compression ratios. If you have 2 layers of compression, the maximum ratio becomes 1032^2 = 1065024. For 3, it's 1099104768, and so on. For the 5 layers used in 42.zip, the theoretical maximum compression ratio is 1170572956434432. As you can see, the actual 42.zip is far from that level. Part of that is the overhead of the zip format, and part of it is that they just didn't care.

If I had to guess, I'd say that 42.zip was formed by just creating a large empty file, and repeatedly zipping and copying it. There is no attempt to push the limits of the format or maximize compression or anything - they just arbitrarily picked 16 copies per layer. The point was to create a large payload without much effort.

Note: Other compression formats, such as bzip2, offer much, much, much larger maximum compression ratios. However, most zip parsers don't accept them.

P.S. It is possible to create a zip file which will unzip to a copy of itself (a quine). You can also make one that unzips to multiple copies of itself. Therefore, if you recursively unzip a file forever, the maximum possible size is infinite. The only limitation is that it can increase by at most 1032 on each iteration.

P.P.S. The 1032 figure assumes that file data in the zip are disjoint. One quirk of the zip file format is that it has a central directory which lists the files in the archive and offsets to the file data. If you create multiple file entries pointing to the same data, you can achieve much higher compression ratios even with no nesting, but such a zip file is likely to be rejected by parsers.

entityMap|blocks|key|8m4d7|text|创建zipbomb+(或gzbomb)的一个好方法是知道目标的二进制格式。否则，即使您使用流文件(例如，使用/dev/zero)您仍然会受到压缩流所需的计算能力的限制。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|6pcbu|gzip炸弹的一个很好的例子：|efkpt|http://selenic.com/googolplex.gz57|1ldhe|(在几个级别的压缩后，文件中嵌入了一条消息，导致产生巨大的文件)|55neh|祝你找到这条信息的乐趣:)^0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|K|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|L|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|M|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|N|9|@]|A|@]|B|$]]|$2|I|4|J|6|7|8|O|9|@]|A|@]|B|$]]]]

A nice way to create a zipbomb (or gzbomb) is to know the binary format you are targeting. Otherwise, even if you use a streaming file (for example using <code>/dev/zero</code>) you'll still be limited by computing power needed to compress the stream.

A nice example of a gzip bomb: <a href="http://selenic.com/googolplex.gz57" rel="nofollow noreferrer">http://selenic.com/googolplex.gz57</a> (there's a message embedded in the file after several level of compression resulting in huge files)

Have fun finding that message :)

entityMap|blocks|key|eccng|text|硅谷第三季第七集把我带到了这里。生成zip炸弹的步骤如下所示。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3lopi|创建一个大小为0(如果您认为它们很薄，则为1)的虚拟文件(例如1+GB)。|ordered-list-item|76v3o|将这个文件压缩成zip文件1.zip..。|8rc8c|制作n(比方说10个)拷贝这个文件，并将这10个文件添加到压缩的存档中(比方说2.zip)。|a07va|重复步骤3k次数。|ch0q|你会得到一个邮编炸弹。|32bmt|对于Python实现，请选中这个..。^0|0|0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|P|9|@]|A|@]|B|$]]|$2|C|4|D|6|E|8|Q|9|@]|A|@]|B|$]]|$2|F|4|G|6|E|8|R|9|@]|A|@]|B|$]]|$2|H|4|I|6|E|8|S|9|@]|A|@]|B|$]]|$2|J|4|K|6|E|8|T|9|@]|A|@]|B|$]]|$2|L|4|M|6|E|8|U|9|@]|A|@]|B|$]]|$2|N|4|O|6|7|8|V|9|@]|A|@]|B|$]]]]

Silicon Valley Season 3 Episode 7 brought me here. The steps to generate a zip bomb would be. 

<ol>
<li>Create a dummy file with zeros (or ones if you think they're skinny) of size (say 1 GB).</li>
<li>Compress this file to a zip-file say <code>1.zip</code>.</li>
<li>Make <code>n</code> (say 10) copies of this file and add these 10 files to a compressed archive (say <code>2.zip</code>).</li>
<li>Repeat step 3 <code>k</code> number of times.</li>
<li>You'll get a zip bomb. </li>
</ol>

For a Python implementation, check <a href="https://github.com/abdulfatir/ZipBomb" rel="nofollow">this</a>.

entityMap|blocks|key|dc1la|text|也许，在unix上，您可以将一定数量的零直接输入到zip程序或其他什么程序中？不过，我对unix的了解还不够多，无法解释你是如何做到这一点的。除此之外，您还需要一个零源，并将它们通过管道传输到拉链中，以便从标准输入或其他内容读取数据……|type|unstyled|depth|inlineStyleRanges|entityRanges|data^0^^$0|$]|1|@$2|3|4|5|6|7|8|C|9|@]|A|@]|B|$]]]]

Perhaps, on unix, you could pipe a certain amount of zeros directly into a zip program or something? Don't know enough about unix to explain how you would do that though. Other than that you would need a source of zeros, and pipe them into a zipper that read from stdin or something...

entityMap|blocks|key|4hchf|text|所有文件压缩算法都依赖于熵(http://en.wikipedia.org/wiki/Entropy_(information_theory%2529|type|unstyled|depth|inlineStyleRanges|entityRanges|data|9674r|)要压缩的信息。从理论上讲，你可以压缩一个0或1的流，如果它足够长，它会压缩得很好。|cpllp|这就是理论部分。其他人已经指出了实际的部分。^0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|G|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|H|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|I|9|@]|A|@]|B|$]]]]

All file compression algorithms rely on the <a href="http://en.wikipedia.org/wiki/Entropy_(information_theory)" rel="nofollow noreferrer">entropy</a> of the information to be compressed. 
Theoretically you can compress a stream of 0's or 1's, and if it's long enough, it will compress very well.

That's the theory part. The practical part has already been pointed out by others.

entityMap|blocks|key|rtmf|text|最近(1995年后)的压缩算法，如bz2，lzma+(7-zip)和rar，对单调的文件进行了惊人的压缩，单层压缩就足以将过大的内容包装成可管理的大小。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|dioqn|另一种方法可以是创建一个极端大小(艾字节)的稀疏文件，然后用理解稀疏文件的普通东西(例如tar)压缩它，现在如果审查者流式传输文件，审查者将需要读取所有存在于文件实际内容之间的零，如果审查者将其写入磁盘，那么将使用很少的空间(假设行为良好的未归档程序和现代文件系统)。^0|0^^$0|$]|1|@$2|3|4|5|6|7|8|E|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|F|9|@]|A|@]|B|$]]]]

Recent (post 1995) compression algorithms like bz2, lzma (7-zip) and rar give spectacular compression of monotonous files, and a single layer of compression is sufficient to wrap oversized content to a managable size. 

Another approach could be to create a sparse file of extreme size (exabytes) and then compress it with something mundane that understands sparse files (eg tar), now if the examiner streams the file the examiner will need to read past all those zeros that exist only to pad between the actual content of the file, if the examiner writes it to disk however very little space will be used (assuming a well-behaved unarchiver and a modern filesystem).

entityMap|blocks|key|9ajc4|text|试过了。输出的zip文件大小是一个84KB的小文件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4he6|到目前为止我所做的步骤：|bu6o1|创建一个1.4+GB的.txt文件，文件中全是'0‘|ordered-list-item|emch4|压缩它。|apigq|将.zip重命名为.txt，然后创建16个拷贝|8ctth|将所有内容压缩到一个.zip文件中，|bga98|将.zip文件中重命名的.txt文件重命名为.zip|b4kn1|重复步骤3至5+8次。|3q8s6|享受:)|54l4b|虽然我不知道如何解释重命名的zip文件的压缩仍然将其压缩成更小的大小的部分，但它可以工作。也许我只是缺少技术术语。^0|0|0|0|0|0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|V|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|W|9|@]|A|@]|B|$]]|$2|E|4|F|6|G|8|X|9|@]|A|@]|B|$]]|$2|H|4|I|6|G|8|Y|9|@]|A|@]|B|$]]|$2|J|4|K|6|G|8|Z|9|@]|A|@]|B|$]]|$2|L|4|M|6|G|8|10|9|@]|A|@]|B|$]]|$2|N|4|O|6|G|8|11|9|@]|A|@]|B|$]]|$2|P|4|Q|6|G|8|12|9|@]|A|@]|B|$]]|$2|R|4|S|6|G|8|13|9|@]|A|@]|B|$]]|$2|T|4|U|6|7|8|14|9|@]|A|@]|B|$]]]]

Tried it. the output zip file size was a small 84-KB file.

Steps I made so far:

<ol>
<li>create a 1.4-GB .txt file full of '0'</li>
<li>compress it.</li>
<li>rename the .zip to .txt then make 16 copies</li>
<li>compresse all of it into a .zip file,</li>
<li>rename the renamed .txt files inside the .zip file into .zip again</li>
<li>repeat steps 3 to 5 eight times.</li>
<li>Enjoy :)</li>
</ol>

though i dont know how to explain the part where the compression of the renamed zip file still compresses it into a smaller size, but it works. Maybe i just lack the technical terms.

entityMap|blocks|key|1ikc6|text|我不知道ZIP是否使用游程编码，但如果使用游程编码，这样的压缩文件将包含一小段数据和非常大的游程长度值。游程长度值将指定一小段数据重复多少次。当你有一个非常大的值时，结果数据就会成比例的大。|type|unstyled|depth|inlineStyleRanges|entityRanges|data^0^^$0|$]|1|@$2|3|4|5|6|7|8|C|9|@]|A|@]|B|$]]]]

I don't know if ZIP uses Run Length Encoding, but if it did, such a compressed file would contain a small piece of data and a very large run-length value. The run-length value would specify how many times the small piece of data is repeated. When you have a very large value, the resultant data is proportionally large.

entityMap|blocks|key|dirr3|text|没有必要使用嵌套文件，您可以利用zip格式来覆盖数据。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|6527a|https://www.bamsoftware.com/hacks/zipbomb/|6gc6p|“这篇文章展示了如何构建一个非递归压缩炸弹，通过在压缩容器中重叠文件来实现高压缩比。”非递归“意味着它不依赖解压程序递归解压缩嵌套在zip文件中的zip文件:它在单轮解压后完全扩展。输出大小在输入大小中增加二次，在zip格式的限制下达到超过2800万(10MB→281TB)的压缩比。使用64位扩展名可以实现更大的扩展。该结构使用|b3tb2|“使用zip格式的压缩炸弹必须处理这样一个事实，即压缩算法DEFLATE是zip解析器最常支持的压缩算法，它不能达到大于1032的压缩比。出于这个原因，zip炸弹通常依赖于递归解压缩，将zip文件嵌套在zip文件中，以获得每层1032的额外系数。但这个技巧只适用于递归解压缩的实现，大多数都不起作用。最著名的zip炸弹，42.zip，如果所有六层都递归解压缩，则扩展到令人敬畏的4.5PB，但顶层只有微不足道的0.6MB。Zip+quines，如Ellingsen和Cox的quines，包含自身的副本，因此如果递归解压缩，则会无限扩展，同样，解压缩一次也是完全安全的。^0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|I|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|J|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|K|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|L|9|@]|A|@]|B|$]]]]

It is not necessary to use nested files, you can take advantage of the zip format to overlay data.
<a href="https://www.bamsoftware.com/hacks/zipbomb/" rel="nofollow noreferrer">https://www.bamsoftware.com/hacks/zipbomb/</a>
&quot;This article shows how to construct a non-recursive zip bomb that achieves a high compression ratio by overlapping files inside the zip container. &quot;Non-recursive&quot; means that it does not rely on a decompressor's recursively unpacking zip files nested within zip files: it expands fully after a single round of decompression. The output size increases quadratically in the input size, reaching a compression ratio of over 28 million (10 MB → 281 TB) at the limits of the zip format. Even greater expansion is possible using 64-bit extensions. The construction uses only the most common compression algorithm, DEFLATE, and is compatible with most zip parsers.&quot;
&quot;Compression bombs that use the zip format must cope with the fact that DEFLATE, the compression algorithm most commonly supported by zip parsers, cannot achieve a compression ratio greater than 1032. For this reason, zip bombs typically rely on recursive decompression, nesting zip files within zip files to get an extra factor of 1032 with each layer. But the trick only works on implementations that unzip recursively, and most do not. The best-known zip bomb, 42.zip, expands to a formidable 4.5 PB if all six of its layers are recursively unzipped, but a trifling 0.6 MB at the top layer. Zip quines, like those of Ellingsen and Cox, which contain a copy of themselves and thus expand infinitely if recursively unzipped, are likewise perfectly safe to unzip once.&quot;

<a href="https://stackoverflow.com/questions/1459080/how-can-i-protect-myself-from-a-zip-bomb">This question</a> about zip bombs naturally led me to the <a href="http://en.wikipedia.org/wiki/Zip_bomb" rel="noreferrer">Wikipedia page</a> on the topic. The article mentions an example of a 45.1 kb zip file that decompresses to 1.3 exabytes.
What are the principles/techniques that would be used to create such a file in the first place? I don't want to actually do this, more interested in a simplified &quot;how-stuff-works&quot; explanation of the concepts involved.
The article mentions 9 layers of zip files, so it's not a simple case of zipping a bunch of zeros. Why 9, why 10 files in each?

How does one make a Zip bomb?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

 这个问题有关zip炸弹的信息自然将我带到了维基百科页面关于这个话题。这篇文章提到了一个45.1kb的zip文件的例子，它可以解压缩到1.3EB。 创建这样一个文件首先要用到的原则/技术是什么？我实际上并不想这样做，我更感兴趣的是对所涉及的概念的简化的“如何工作”的解释。 附注： 这篇文章提到了9层zip文件，所以这不是一个简单的压缩一堆零的例子。为什么是9个文件，为什么每个文件有10个文件？

问如何制作Zip炸弹？
EN

回答 15

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何制作Zip炸弹？EN

回答 15

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何制作Zip炸弹？
EN