Этот вопрос о zip-бомбах естественным образом привел меня на страницу Википедии соответствующей теме . В статье упоминается пример zip-файла размером 45,1 КБ, который распаковывается до 1,3 эксабайта.
Какие принципы / методы будут использованы в первую очередь для создания такого файла? На самом деле я не хочу этого делать, меня больше интересует упрощенное объяснение задействованных концепций "как все работает".
п.с.
В статье упоминается 9 слоев zip-файлов, так что это непростой случай заархивирования кучи нулей. Почему 9, почему по 10 файлов в каждом?
algorithm
compression
рыба фугу
источник
источник
Ответы:
Цитата со страницы Википедии:
Итак, все, что вам нужно, это один файл размером 1,3 ГБ, полный нулей, сжать его в ZIP-файл, сделать 10 копий, упаковать их в ZIP-файл и повторить этот процесс 9 раз.
Таким образом, вы получаете файл, который после полного распаковки производит абсурдное количество данных, не требуя начинать с этого количества.
Кроме того, вложенные архивы значительно усложняют работу программ, таких как антивирусные сканеры (основная цель этих "бомб"), и отказываются распаковывать "слишком большие" архивы, потому что до последнего уровня общий объем данных не так уж и много, вы не «видите», насколько велики файлы на самом низком уровне, пока не достигнете этого уровня, и каждый отдельный файл не будет «слишком большим» - проблематично только огромное количество.
источник
Создайте файл нулей размером 1,3 эксабайта.
Щелкните правой кнопкой мыши> Отправить в сжатую (заархивированную) папку.
источник
В Linux это легко сделать с помощью следующей команды:
dd if=/dev/zero bs=1024 count=10000 | zip zipbomb.zip -Замените count на количество КБ, которое вы хотите сжать. В приведенном выше примере создается zip-бомба размером 10 МБ (совсем не бомба, но он показывает процесс).
Вам НЕ нужно место на жестком диске для хранения всех несжатых данных.
источник
Ниже для Windows:
Из доказательства концепции Security Focus (NSFW!), Это ZIP-файл с 16 папками, по 16 папок в каждой, что выглядит следующим образом (42 - это имя zip-файла):
Я, вероятно, ошибаюсь с этой цифрой, но она дает 4 ^ 16 (4294967296) каталогов. Поскольку каждому каталогу требуется место в N байтов, он оказывается огромным. Файл dll в конце имеет размер 0 байт.
При распаковке только первого каталога
\42\lib 0\book 0\chapter 0\doc 0\0.dllвыделяется 4 ГБ дискового пространства.источник
Серьезный ответ:
(Очень в основном) Сжатие основано на обнаружении повторяющихся шаблонов, поэтому zip-файл будет содержать данные, представляющие что-то вроде
Очень короткий zip-файл, но огромный при его расширении.
источник
Чтобы создать его в практических условиях (то есть без создания файла размером 1,3 эксабайта на вашем огромном жестком диске), вам, вероятно, придется изучить формат файла на двоичном уровне и написать что-то, что переводит на то, как будет выглядеть ваш желаемый файл, после сжатия.
источник
Во-первых, в статье Википедии сейчас говорится о 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 их не принимают.
PS Можно создать zip-файл, который будет распаковываться в свою копию (квайн). Вы также можете сделать тот, который распаковывается на несколько своих копий. Следовательно, если вы рекурсивно разархивируете файл навсегда, максимально возможный размер будет бесконечным. Единственное ограничение - он может увеличиваться максимум на 1032 на каждой итерации.
PPS Рисунок 1032 предполагает, что данные файла в zip-архиве не пересекаются. Одна из особенностей формата zip-файла заключается в том, что он имеет центральный каталог, в котором перечислены файлы в архиве и смещены данные файла. Если вы создаете несколько файловых записей, указывающих на одни и те же данные, вы можете добиться гораздо более высоких степеней сжатия даже без вложенности, но такой zip-файл, вероятно, будет отклонен синтаксическими анализаторами.
источник
Хороший способ создать zipbomb (или gzbomb) - это знать двоичный формат, на который вы нацеливаетесь. В противном случае, даже если вы используете потоковый файл (например, используя
/dev/zero), вы все равно будете ограничены вычислительной мощностью, необходимой для сжатия потока.Хороший пример gzip-бомбы: http://selenic.com/googolplex.gz57 (в файл встроено сообщение после нескольких уровней сжатия, приводящих к огромным файлам)
Удачи найти это сообщение :)
источник
Возможно, в unix вы могли бы передать определенное количество нулей прямо в zip-программу или что-то в этом роде? Не знаю достаточно о unix, чтобы объяснить, как бы вы это сделали. Помимо этого, вам понадобится источник нулей и вставьте их в застежку-молнию, которая читает из стандартного ввода или чего-то еще ...
источник
Все алгоритмы сжатия файлов полагаются на энтропию сжимаемой информации. Теоретически вы можете сжать поток нулей или единиц, и если он достаточно длинный, он сжимается очень хорошо.
Это часть теории. Практическая часть уже отмечена другими.
источник
Недавние (после 1995 года) алгоритмы сжатия, такие как bz2, lzma (7-zip) и rar, дают впечатляющее сжатие монотонных файлов, и одного уровня сжатия достаточно, чтобы обернуть негабаритный контент до управляемого размера.
Другой подход может заключаться в создании разреженного файла экстремального размера (эксабайт), а затем его сжатие с помощью чего-то обыденного, которое понимает разреженные файлы (например, tar), теперь, если экзаменатор передает файл в потоковом режиме, экзаменатору необходимо будет прочитать все те нули, которые существуют. только для вставки между фактическим содержимым файла, если проверяющий записывает его на диск, однако будет использовано очень мало места (при условии хорошо работающего разархиватора и современной файловой системы).
источник
Попробовал это. Размер выходного zip-файла был небольшим файлом размером 84 КБ.
Шаги, которые я сделал до сих пор:
хотя я не знаю, как объяснить ту часть, где сжатие переименованного zip-файла по-прежнему сжимает его до меньшего размера, но это работает. Может, мне просто не хватает технических терминов.
источник
Силиконовая долина Сезон 3 Эпизод 7 привел меня сюда. Шаги для создания zip-бомбы будут.
1.zip.n(скажем, 10) копий этого файла и добавьте эти 10 файлов в сжатый архив (скажем2.zip).kнесколько раз.Для реализации Python проверьте это .
источник
Я не знаю, использует ли ZIP кодировку длины прогона, но если бы она использовалась, такой сжатый файл содержал бы небольшой фрагмент данных и очень большое значение длины серии. Значение длины серии должно указывать, сколько раз повторяется небольшой фрагмент данных. Когда у вас очень большое значение, результирующие данные будут пропорционально большими.
источник