Zip 폭탄은 어떻게 만드나요?

Zip 폭탄은 어떻게 만드나요?

---

우편 폭탄에 대한 이 질문 은 당연히 주제에 관한 Wikipedia 페이지로 연결 되었습니다. 이 기사에서는 1.3 엑사 바이트로 압축 해제되는 45.1 kb zip 파일의 예를 언급합니다.

처음에 그러한 파일을 만드는 데 사용될 원칙 / 기술은 무엇입니까? 나는 실제로 이것을하고 싶지 않다. 관련된 개념에 대한 단순화 된 "어떻게 작동 하는가"설명에 더 관심이있다.

추신

이 기사에서는 9 개의 zip 파일 레이어를 언급하므로 여러 개의 0을 압축하는 단순한 사례는 아닙니다. 왜 9, 왜 각각에 10 개의 파일이 있습니까?

---

Wikipedia 페이지에서 인용 :

Zip 폭탄의 한 예는 45.1.zip 파일로, 45.1 킬로바이트의 압축 된 데이터로, 10 세트의 중첩 된 zip 파일 9 개 레이어를 포함하고, 각 맨 아래 레이어 아카이브 에는 총 1.30 엑사 바이트의 압축되지 않은 데이터에 대해 1.30 기가 바이트 파일이 포함 됩니다. .

따라서 하나의 1.3GB 파일이 0으로 가득 차면 ZIP 파일로 압축하고 10 부를 복사하여 ZIP 파일로 압축 한 다음이 과정을 9 번 반복하면됩니다.

이 방법으로, 당신은 완전히 압축이 풀릴 때 그 양으로 시작하지 않고도 터무니없는 양의 데이터를 생성하는 파일을 얻습니다.

또한 중첩 된 아카이브는 바이러스 스캐너 (이러한 "폭탄"의 주요 대상)와 같은 프로그램이 현명하고 "너무 큰"아카이브의 압축을 푸는 것을 거부합니다. 마지막 레벨까지 총 데이터 양이 그다지 중요하지는 않지만 가장 낮은 수준의 파일이 해당 수준에 도달 할 때까지 얼마나 큰지 "보지"않으며 각 개별 파일이 "너무 크지"않습니다. 큰 숫자 만 문제가됩니다.

---

0의 1.3 엑사 바이트 파일을 작성하십시오.

마우스 오른쪽 버튼으로 클릭> 압축 (zip) 폴더로 보내기.

---

Linux에서 다음 명령을 사용하여 쉽게 수행 할 수 있습니다.

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

count를 압축하려는 KB 수로 바꾸십시오. 위의 예제는 10MiB zip 폭탄을 생성합니다 (폭탄은 많지 않지만 프로세스를 보여줍니다).

압축되지 않은 모든 데이터를 저장하기 위해 하드 디스크 공간이 필요하지 않습니다.

---

아래는 Windows 용입니다.

로부터 개념의 보안 초점 증거 (! NSFW)는, 그것은 (42 zip 파일 이름)과 같이 간다 16 개 폴더 16 개 폴더, 각이있는 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,294,967,296) 디렉토리를 생성합니다. 각 디렉토리에는 N 바이트의 할당 공간이 필요하기 때문에 결국 용량이 큽니다. 끝에있는 dll 파일은 0 바이트입니다.

첫 번째 디렉토리 만 압축 해제하면 \42\lib 0\book 0\chapter 0\doc 0\0.dll4GB의 할당 공간이 생성됩니다.

---

심각한 답변 :

압축은 반복되는 패턴을 발견하는 데 의존하므로 zip 파일에는 다음과 같은 것을 나타내는 데이터가 포함됩니다.

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

매우 짧은 zip 파일이지만 확장하면 크기가 큽니다.

---

실제 설정에서 파일을 만들려면 (예 : 엄청난 하드 드라이브에 1.3 엑사 바이트 파일을 만들지 않고) 파일 형식을 이진 수준에서 배우고 원하는 파일 모양으로 변환하는 내용을 작성해야합니다. 압축.

---

이 기사에서는 9 개의 zip 파일 레이어를 언급하므로 여러 개의 0을 압축하는 단순한 사례는 아닙니다. 왜 9, 왜 각각에 10 개의 파일이 있습니까?

우선, Wikipedia 기사는 현재 16 개의 파일이있는 5 개의 레이어를 말합니다. 불일치가 어디에서 왔는지 확실하지 않지만 그게 전부가 아닙니다. 진짜 질문은 왜 처음부터 중첩을 사용 하는가입니다.

압축 파일 *에 대해 유일하게 지원되는 압축 방법 인 DEFLATE는 최대 압축률이 1032입니다. 이는 1-3 바이트의 모든 반복 시퀀스에 대해 무조건 달성 할 수 있습니다. 압축 파일에 대해 수행하는 작업에 관계없이 DEFLATE 만 사용하는 한 압축 해제 된 크기는 원래 압축 파일 크기의 최대 1032 배입니다.

따라서 중첩 된 zip 파일을 사용하여 엄청나게 큰 압축 비율을 달성해야합니다. 압축 레이어가 2 개인 경우 최대 비율은 1032 ^ 2 = 1065024가됩니다. 3의 경우 1099104768 등입니다. 42.zip에 사용 된 5 개 계층의 경우 이론상 최대 압축 비율은 1170572956434432입니다. 실제로 볼 수 있듯이 실제 42.zip은 해당 레벨과는 거리가 멀습니다. 그중 일부는 zip 형식의 오버 헤드이며 일부는 방금 신경 쓰지 않았다는 것입니다.

추측해야한다면 42.zip은 큰 빈 파일을 만들고 반복적으로 압축하여 복사하여 형성되었다고 말할 수 있습니다. 형식의 한계를 뛰어 넘거나 압축 등을 극대화하려는 시도는 없습니다. 레이어 당 16 개의 사본을 임의로 선택했습니다. 요점은 많은 노력없이 큰 페이로드를 만드는 것이 었습니다.

참고 : bzip2와 같은 다른 압축 형식은 훨씬 더 큰 최대 압축 비율을 제공합니다. 그러나 대부분의 zip 파서는 허용하지 않습니다.

추신 : zip 파일을 만들어서 사본 자체의 압축을 풀 수 있습니다 (quiine). 또한 여러 개의 사본을 압축 해제 할 수도 있습니다. 따라서 파일을 영원히 재귀 적으로 압축 해제하면 가능한 최대 크기는 무한대입니다. 유일한 제한 사항은 각 반복마다 최대 1032까지 증가 할 수 있다는 것입니다.

PPS 1032 그림은 zip의 파일 데이터가 분리되어 있다고 가정합니다. zip 파일 형식의 단점 중 하나는 아카이브의 파일을 나열하고 파일 데이터로 오프셋하는 중앙 디렉토리가 있다는 것입니다. 동일한 데이터를 가리키는 파일 항목을 여러 개 만들면 중첩 없이도 압축률이 훨씬 높아지지만 파서는 이러한 zip 파일을 거부 할 수 있습니다.

---

zipbomb (또는 gzbomb)을 작성하는 좋은 방법은 대상으로하는 바이너리 형식을 아는 것입니다. 그렇지 않으면 스트리밍 파일 (예 :)을 사용하더라도 /dev/zero스트림을 압축하는 데 필요한 컴퓨팅 성능이 여전히 제한됩니다.

gzip 폭탄의 좋은 예 : http://selenic.com/googolplex.gz57 (여러 파일을 압축 한 후 여러 수준의 압축 후 파일에 메시지가 포함되어 있음)

Have fun finding that message :)

---

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...

---

All file compression algorithms rely on the entropy 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.

---

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).

---

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

Steps I made so far:

1. create a 1.4-GB .txt file full of '0'
2. compress it.
3. rename the .zip to .txt then make 16 copies
4. compresse all of it into a .zip file,
5. rename the renamed .txt files inside the .zip file into .zip again
6. repeat steps 3 to 5 eight times.
7. Enjoy :)

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.

---

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.

---

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

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

For a Python implementation, check this.

참고URL : https://stackoverflow.com/questions/1459673/how-does-one-make-a-zip-bomb