Этот вопрос об zip-бомбах, естественно, привел меня к странице Wikipedia тема. В статье упоминается пример zip файла 45,1 кб, который распаковывается до 1,3 экзабайта.
Каковы принципы/методы, которые будут использоваться для создания такого файла в первую очередь? Я не хочу этого делать, больше заинтересован в упрощенном объяснении понятий "how-stuff-works".
p.s.
В статье упоминаются 9 слоев zip файлов, поэтому это не простой случай скрепления кучей нулей. Почему 9, почему 10 файлов в каждом?
Цитирование со страницы Википедии:
Одним из примеров Zip-бомбы является файл 45.1.zip, что составило 45,1 килобайта сжатых данных, , содержащих девять слоев вложенных zip файлов в наборах 10, каждый архив нижнего слоя содержащий файл 1.30 гигабайт для всего 1,30 экзабайта несжатого данных.
Итак, все, что вам нужно - это один файл размером 1,3 ГБ с нулями, сжимать его в ZIP файл, делать 10 копий, вставлять их в ZIP файл и повторять этот процесс 9 раз.
Таким образом, вы получаете файл, который при несжатом сжатии создает абсурдный объем данных, не требуя, чтобы вы начали с этой суммы.
Кроме того, вложенные архивы значительно усложняют работу таких программ, как антивирусные сканеры (главная цель этих "бомб" ) и отказываются распаковывать архивы "слишком велики", поскольку до последнего уровня общая сумма данных не так много, вы не видите "насколько велики файлы на самом низком уровне, пока вы не достигли этого уровня, и каждый отдельный файл не" слишком велик "- только огромное количество проблем.
Создайте файл с наименьшим количеством файлов, равный 1.3.
Щелкните правой кнопкой мыши > Отправить в сжатую (сжатую) папку.
Это легко сделать в Linux с помощью следующей команды:
dd if=/dev/zero bs=1024 count=10000 | zip zipbomb.zip -
Замените счетчик количеством КБ, которое вы хотите сжать. В приведенном выше примере создается 10-мегабайтная молния (не большая часть бомбы вообще, но она показывает процесс).
Вам НЕ нужно место на жестком диске для хранения всех несжатых данных.
Ниже для Windows:
Из Security Focus доказательство концепции (NSFW!), это ZIP файл с 16 папками, каждый с 16 папками, который продолжается (42 - это имя zip файла):
\ 42\lib 0\book 0\chapter 0\doc 0\0.dll
...
\ 42\lib F\book F\chapter F\doc F\0.dll
Вероятно, я ошибаюсь с этой цифрой, но она создает 4 ^ 16 (4 299 967 296) каталогов. Поскольку каждому каталогу требуется пространство для размещения N байтов, оно становится огромным. Файл dll в конце - 0 байт.
Распакованный только первый каталог \42\lib 0\book 0\chapter 0\doc 0\0.dll приводит к 4 гб пространства для размещения.
Серьезный ответ:
(В основном, в основном) Сжатие зависит от определения повторяющихся шаблонов, поэтому 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 файл, который будет распаковывать копию самого себя (quine). Вы также можете сделать тот, который распаковывает несколько копий. Поэтому, если вы рекурсивно распаковываете файл навсегда, максимально возможный размер бесконечен. Единственное ограничение состоит в том, что он может увеличиться не более чем на 1032 на каждой итерации.
P.P.S. Значение 1032 предполагает, что данные файла в zip не пересекаются. Одна из особенностей формата zip файла состоит в том, что он имеет центральный каталог, в котором перечислены файлы в архиве и смещения данных файла. Если вы создаете несколько записей в файлах, указывающих на одни и те же данные, вы можете достичь гораздо более высоких коэффициентов сжатия даже при отсутствии вложенности, но такой zip файл, скорее всего, будет отклонен парсерами.
Хорошим способом создания zipbomb (или gzbomb) является знание бинарного формата, на который вы нацеливаетесь. В противном случае, даже если вы используете потоковый файл (например, используя /dev/zero), вы все равно будете ограничены вычислительной мощностью, необходимой для сжатия потока.
Хороший пример бомбы gzip: http://selenic.com/googolplex.gz57 (там есть сообщение, встроенное в файл после нескольких уровней сжатия, приводящих к огромному файлы)
Удачи, найдя это сообщение:)
Возможно, в unix вы могли бы передать определенное количество нулей непосредственно в zip-программу или что-то еще? Не знаю достаточно о unix, чтобы объяснить, как вы это сделаете. Помимо этого вам понадобится источник нулей, и вытащите их в застежку-молнию, которая читается из stdin или что-то в этом роде.
Все алгоритмы сжатия файлов полагаются на entropy информации, подлежащей сжатию. Теоретически вы можете сжимать поток 0 или 1, и если он достаточно длинный, он будет очень хорошо сжиматься.
Это часть теории. Практическая часть уже была указана другими.
Пробовал. размер файла zip файла был небольшим 84-килобайтным файлом.
Шаги, которые я сделал до сих пор:
хотя я не знаю, как объяснить, где сжатие переименованного zip файла все еще сжимает его в меньшем размере, но он работает. Может быть, мне просто не хватает технических терминов.
Я не знаю, использует ли ZIP Encoding Run Length Encoding, но если это так, такой сжатый файл будет содержать небольшую часть данных и очень большое значение длины строки. Величина длины пробега указывает, сколько раз повторяется небольшая часть данных. Когда у вас очень большое значение, результирующие данные пропорционально большие.
Недавние (пост-1995) алгоритмы сжатия, такие как bz2, lzma (7-zip) и rar, дают эффектное сжатие однообразных файлов, и одного слоя сжатия достаточно, чтобы обернуть негабаритный контент в управляемый размер.
Другой подход может заключаться в создании разреженного файла с экстремальным размером (exabytes), а затем сжимать его чем-то обыденным, который понимает разреженные файлы (например, tar), теперь, если экзаменатор передает файл, который экзаменатору нужно будет прочитать за всеми этими нули, которые существуют только для прокладки между фактическим содержимым файла, если экзаменатор записывает его на диск, однако очень мало места будет использовано (при условии, что у него есть хорошо сохранившийся unarchiver и современная файловая система).
Сезон кремниевой долины 3 Эпизод 7 привел меня сюда. Шаги по созданию молнии будут.
1.zip.n (скажем, 10) копии этого файла и добавьте эти 10 файлов в сжатый архив (скажем 2.zip).k несколько раз.Для реализации Python отметьте this.