Как сделать бомбу на молнии?

создайте файл 1.3 эксабайта нулей.

Правой Кнопкой Мыши > отправить в сжатая zip-папка ().

Это легко сделать в Linux с помощью следующей команды:

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

замените счетчик на количество КБ, которое вы хотите сжать. В приведенном выше примере создается 10mib zip бомба (не так много бомбы вообще, но это показывает процесс).

вам не нужно место на жестком диске для хранения всех несжатых данных.

ниже для Windows:

С фокус безопасности доказательство концепции (NSFW!), это ZIP-файл с 16 папками, каждая из которых имеет 16 папок, которая продолжается так (42-это имя zip-файла):

\42\lib 0\book 0\chapter 0\doc 0\0.dll
...
\42\Либ Ф\книги Ф\глава Ф\док ф\0.dll

Я, вероятно, ошибаюсь с этой цифрой, но она производит 4^16 (4,294,967,296) каталогов. Потому что каждый каталог должен пространство выделения N байт, оно оказывается огромным. Файл dll в конце составляет 0 байт.

распаковал только первый каталог \lib 0\book 0\chapter 0\doc 0

серьезный ответ:

(очень в основном) сжатие зависит от обнаружения повторяющихся шаблонов, поэтому zip-файл будет содержать данные, представляющие что-то вроде

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

очень короткий zip-файл, но огромный, когда вы его расширяете.

чтобы создать его в практической настройке (т. е. без создания 1,3-экзабайтного файла на вашем огромном жестком диске), вам, вероятно, придется изучить формат файла на двоичном уровне и написать что-то, что переводит на то, как будет выглядеть ваш желаемый файл, после сжатия.

в статье упоминается 9 слоев zip-файлов, так что это не простой случай молнии кучу нулей. Почему 9, почему 10 файлов в каждой?

во-первых, в статье Википедии В настоящее время говорится о 5 слоях с 16 файлами каждый. Не уверен, откуда это расхождение, но это не так важно. Реальный вопрос заключается в том, зачем использовать вложенность в первую очередь.

DEFLATE, единственный обычно поддерживаемый метод сжатия для zip-файлов*, имеет максимальное сжатие соотношение 1032. Это может быть достигнуто асимптотически для любой повторяющейся последовательности 1-3 байта. Независимо от того, что вы делаете с zip-файлом, пока он использует только DEFLATE, размер распаковки будет не более 1032 раз больше размера исходного zip-файла.

поэтому необходимо использовать вложенные zip-файлы для достижения действительно возмутительных коэффициентов сжатия. Если у вас есть 2 слоя сжатия, максимальное соотношение становится 1032^2 = 1065024. Для 3, это 1099104768, и так далее. Для 5 слоев используется в 42.zip, теоретическая максимальная степень сжатия составляет 1170572956434432. Как видите, собственно 42.zip далек от этого уровня. Часть этого-накладные расходы формата zip, а часть-это то, что им просто было все равно.

если бы я должен был догадаться, я бы сказал, что 42.zip был сформирован путем простого создания большого пустого файла и многократного его архивирования и копирования. Нет никакой попытки раздвинуть границы формата или максимизировать сжатие или что - то еще- они просто произвольно выбрали 16 копии на слой. Смысл был в том, чтобы создать большую полезную нагрузку без особых усилий.

Примечание: другие форматы сжатия, такие как bzip2, предлагают гораздо, гораздо, гораздо большие максимальные коэффициенты сжатия. Однако большинство парсеров zip не принимают их.

P. S. Возможно, чтобы создать zip-файл, который будет распаковать в копию себя (Куайн). Вы также можете сделать один, который распаковывается на несколько копий самого себя. Поэтому, если вы рекурсивно разархивируете файл навсегда, максимально возможный размер будет равен бесконечный. Единственным ограничением является то, что он может увеличиваться не более чем на 1032 на каждой итерации.

P. P. S. На рисунке 1032 предполагается, что данные файла в zip не пересекаются. Одна из особенностей формата zip-файла заключается в том, что он имеет Центральный каталог, в котором перечислены файлы в архиве и смещения к данным файла. Если вы создадите несколько записей файлов, указывающих на одни и те же данные, вы можете достичь гораздо более высоких коэффициентов сжатия даже без вложенности, но такой zip-файл, скорее всего, будет отклонен анализаторы.

хороший способ создать zipbomb (или gzbomb) должен знать двоичный формат, на который вы нацелены. В противном случае, даже если вы используете потоковый файл (например, с помощью /dev/zero) вы все равно будете ограничены вычислительной мощности, необходимой для сжатия потока.

хороший пример бомбы gzip:http://selenic.com/googolplex.gz57 (в файл встроено сообщение после нескольких уровней сжатия, что приводит к огромным файлам)

получайте удовольствие, находя это сообщение :)

возможно, в unix вы могли бы передать определенное количество нулей непосредственно в zip-программу или что-то еще? Не знаю достаточно о unix, чтобы объяснить,как вы это сделаете. Кроме того, вам понадобится источник нулей и поместите их в молнию, которая читается из stdin или что-то в этом роде...

все алгоритмы сжатия файлов полагаются на энтропия информации, подлежащей сжатию. Теоретически вы можете сжать поток 0 или 1, и если он достаточно длинный, он будет сжиматься очень хорошо.

Это часть теории. На практическую часть уже указывали другие.

пробовал. размер выходного zip-файла был небольшим 84-КБ файлом.

шаги, которые я сделал до сих пор:

1. создать 1.4-GB .txt файл, полный '0'
2. сжать его.
3. переименовать .застегнись .txt затем сделать 16 копий
4. сжать все это в a .zip-файл,
5. переименовать переименовали .txt файлы внутри .zip-файл в .снова молния
6. повторите шаги с 3 по 5 восемь раз.
7. наслаждайтесь :)

хотя я не знаю, как объяснить ту часть, где сжатие переименованного zip-файла все еще сжимает его в меньший размер, но он работает. Может, мне просто не хватает технических терминов.

Я не знаю, использует ли ZIP кодировку длины выполнения, но если бы это было так, такой сжатый файл содержал бы небольшой фрагмент данных и очень большое значение длины выполнения. Значение длины выполнения указывает, сколько раз повторяется небольшой фрагмент данных. Когда у вас очень большое значение, результирующие данные пропорционально велики.

недавние (после 1995 года) алгоритмы сжатия, такие как bz2, lzma (7-zip) и rar, дают впечатляющее сжатие монотонных файлов, а одного слоя сжатия достаточно для обертывания негабаритного контента до управляемого размера.

другой подход может заключаться в создании разреженного файла экстремального размера (exabytes) , а затем сжать его с чем-то мирским, что понимает разреженные файлы (например, tar), теперь, если экзаменатор передает файл, экзаменатору нужно будет прочитать все эти нули это существует только для заполнения между фактическим содержимым файла, если экзаменатор записывает его на диск, однако очень мало места будет использоваться (при условии, что хорошо себя ведет unarchiver и современная файловая система).

Силиконовая долина сезон 3 эпизод 7 привел меня сюда. Шаги для создания zip-бомбы будут.

1. создайте фиктивный файл с нулями (или те, Если вы думаете, что они тощие) размера (скажем, 1 ГБ).
2. сжать этот файл в zip-файл сказать 1.zip.
3. сделать n (скажем 10) копии этого файла и добавить эти 10 файлов в сжатый архив (скажем 2.zip).
4. повторите шаг 3 k количество раз.
5. вы получите zip бомба.

для реализации Python, проверьте этой.