How does one make a Zip bomb?

This question about zip bombs naturally led me to the Wikipedia page 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 "how-stuff-works" 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?

126374 次浏览
小开

创建一个1.3 exabyte 的0文件。

右键单击 > 发送到压缩(压缩)文件夹。

小开

我不知道 ZIP 是否使用了运行长度编码，但如果使用了，这样一个压缩文件将包含一小段数据和一个非常大的运行长度值。游程长度值将指定小块数据的重复次数。当您有一个非常大的值时，结果数据按比例变大。

小开

也许，在 unix 上，你可以直接将一定数量的零导入一个 zip 程序或其他什么东西？我对 Unix 的了解还不足以解释你是怎么做到的。除此之外，你需要一个零的来源，并管道他们到一个拉链，读取 stdin 或东西..。

小开

要在实际环境中创建一个文件(即不需要在巨大的硬盘上创建一个1.3 EB 的文件) ，你可能需要学习二进制文件格式，然后写一些东西，转换成你想要的文件在压缩后的样子。

小开

严肃的回答:

(非常基本)压缩依赖于发现重复模式，因此压缩文件将包含表示类似

0x100000000000000000000000000000000000
(Repeat this '0' ten trillion times)

非常短的 zip 文件，但是当你展开它的时候会很大。

小开

下面是 Windows:

来自 概念证明(NSFW!)这是一个包含16个文件夹的 ZIP 文件，每个文件夹包含16个文件夹，如下所示(42是 ZIP 文件名) :

42lib0书0章0 doc 00. dll
...
42lib F 书 F 章 F doc F0. dll

这个数字可能是错误的，但它生成了4 ^ 16(4,294,967,296)个目录。因为每个目录需要 N 个字节的分配空间，所以它最终会变得很大。最后的 dll 文件是0字节。

单独解压第一个目录 \42\lib 0\book 0\chapter 0\doc 0\0.dll会产生4gb 的分配空间。

小开
最佳答案

引自维基百科:

Zip 炸弹的一个例子是文件 45.1.zip 是45.1 KB 的压缩数据，< strong > 包含9个 集合中嵌套的压缩文件层 10，每个底层存档 一个包含1.30 GB 文件 的 总共有1.30 EB 的未压缩文件 资料。

所以你只需要一个1.3 GB 的文件，里面全是零，压缩成一个 ZIP 文件，复制10份，打包成一个 ZIP 文件，然后重复这个过程9次。

这样，你得到一个文件，当完全解压缩，产生一个荒谬的数据量，而不需要你开始与该数量。

此外，嵌套的档案使得像病毒扫描器(这些“炸弹”的主要目标)这样的程序更难以智能化，并拒绝解压缩“太大”的档案，因为直到最后一级的数据总量不是那么多，你不会“看到”在最低级别的文件有多大，直到你达到那个级别，每个文件不是“太大”-只有巨大的数量是有问题的。

小开

在 Linux 下使用以下命令很容易做到这一点:

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

将 count 替换为要压缩的 KB 数。上面的示例创建了一个10MiB 压缩炸弹(其实算不上什么炸弹，但它显示了整个过程)。

您不需要硬盘空间来存储所有未压缩的数据。

小开

所有文件压缩算法都依赖于要压缩的信息的 熵。 从理论上讲，你可以压缩0或1的数据流，如果它足够长，就会压缩得很好。

这是理论部分，实践部分已经被其他人指出来了。

小开

创建 zipBomb (或 gzBomb)的一个很好的方法是了解您所针对的二进制格式。否则，即使您使用流文件(例如使用 /dev/zero) ，您仍然会受到压缩流所需的计算能力的限制。

Gzip 炸弹的一个很好的例子: http://selenic.com/googolplex.gz57(在进行了几个级别的压缩之后，文件中嵌入了一条消息，导致文件很大)

祝你找到这条信息愉快:)

小开

最近(1995年后)的压缩算法，如 bz2，lzma (7-zip)和 rar，给出了对单调文件的精彩压缩，单层压缩就足以将超大内容包装成可管理的大小。

另一种方法是创建一个大小极端的稀疏文件(exabytes) ，然后用一些能够理解稀疏文件(例如 tar)的普通文件压缩它，现在如果检查者流化文件，检查者将需要读取所有那些只存在于文件实际内容之间的零，如果检查者将其写入磁盘，然而只有很少的空间将被使用(假设一个行为良好的非归档程序和一个现代文件系统)。

小开

试过了，输出的 zip 文件大小是一个84-KB 的小文件。

到目前为止我所采取的步骤:

  1. 创建一个1.4 GB 的. txt 文件，其中包含“0”
  2. 压住它。
  3. 将. zip 重命名为. txt，然后复制16份
  4. 将所有内容压缩到一个. zip 文件中,
  5. 再次将.zip 文件中的重命名的.txt 文件重命名为.zip
  6. 重复步骤3至58次。
  7. 享受:)

虽然我不知道如何解释重命名的压缩压缩文件仍然压缩到一个较小的尺寸，但它工作的一部分。也许我只是缺乏专业术语。

小开

硅谷，第三季，第7集。

  1. 创建一个虚拟文件，大小为0(或者如果你认为它们很小的话就是0)(比如1GB)。
  2. 将这个文件压缩为一个 zip 文件，比如 1.zip。
  3. 制作该文件的 n(比如10个)副本，并将这10个文件添加到压缩归档文件(比如 2.zip)中。
  4. 重复步骤3 k多次。
  5. 你会得到一个拉链炸弹。

对于 Python 实现，请检查 这个。

小开

这篇文章提到了9层的 zip 文件，所以这不是一个简单的压缩一堆零的例子。为什么是9个，为什么每个里面有10个文件？

首先，维基百科目前的文章说5层，每层16个文件。不知道这种差异是从何而来的，但这并不完全相关。真正的问题是为什么要首先使用嵌套。

DEFLATE 是唯一通常支持的压缩 zip 文件的方法，它的最大压缩比为1032。对于任何1-3字节的重复序列，这可以渐近地实现。无论您对压缩文件做什么，只要它只使用 DEFLATE，解压缩后的大小最多是原始压缩文件的1032倍。

因此，有必要使用嵌套的压缩文件，以实现真正惊人的压缩比。如果有两层压缩，则最大比值为1032 ^ 2 = 1065024。对于3，是1099104768，以此类推。对于42.zip 中使用的5层，理论上的最大压缩比是1170572956434432。正如您所看到的，实际的42.zip 远远没有达到这个级别。一部分原因是压缩格式的开销，另一部分原因是他们根本不在乎。

如果让我猜的话，我会说42.zip 是通过创建一个大的空文件，然后反复压缩和复制它而形成的。他们并没有试图突破格式的限制或者最大化压缩或者其他什么——他们只是随意的选择每层16个拷贝。关键是不费吹灰之力就能制造出一个巨大的有效载荷。

注意: 其他压缩格式(如 bzip2)提供了大得多得多的最大压缩比。但是，大多数压缩解析器不接受它们。

附言。可以创建一个 zip 文件，将其解压缩为自身的一个副本(一个 quine)。您还可以创建一个可以解压缩到多个自身副本的文件。因此，如果您永远递归地解压缩一个文件，最大可能的大小是无限的。唯一的限制是每次迭代最多增加1032个。

附注。1032图假定 zip 中的文件数据是不相交的。Zip 文件格式的一个特点是它有一个中心目录，其中列出了归档文件中的文件，并偏移到文件数据。如果创建多个指向相同数据的文件条目，即使没有嵌套，也可以获得更高的压缩比，但解析器可能会拒绝这样的 zip 文件。

小开

不需要使用嵌套文件，可以利用 zip 格式覆盖数据。

Https://www.bamsoftware.com/hacks/zipbomb/

“这篇文章展示了如何构建一个非递归的 zip 炸弹，通过在 zip 容器中重叠文件来实现高压缩比。“非递归”意味着它不依赖于解压缩器递归地解压缩嵌套在 zip 文件中的 zip 文件: 它在一轮解压缩之后完全展开。输出大小在输入大小上呈二次增长，在 zip 格式的限制下，压缩比超过2800万(10MB →281TB)。使用64位扩展可以实现更大的扩展。该结构仅使用最常用的压缩算法 DEFLATE，并且与大多数 zip 解析器兼容。”

“使用 zip 格式的压缩炸弹必须应对这样一个事实，即压缩算法 DEFLATE (压缩解析器最常支持的压缩算法)的压缩比不能超过1032。由于这个原因，压缩炸弹通常依赖于递归解压缩，在压缩文件中嵌套压缩文件，以获得每层1032的额外因子。但是这个技巧只适用于递归解压缩的实现，而且大多数都不适用。最著名的压缩炸弹是42.zip，如果它的所有六个层都被递归解压缩，那么它将扩展到令人生畏的4.5 PB，但是在顶层只有区区的0.6 MB。像埃林森和考克斯那样的拉链奎因，它们包含自己的一个副本，因此如果递归地解压缩，它们可以无限扩展，解压一次也是完全安全的。”


提交答案