Bagaimana cara membuat bom Zip?

131

Pertanyaan tentang bom ritsleting ini secara alami mengarahkan saya ke halaman Wikipedia tentang topik itu. Artikel tersebut menyebutkan contoh file zip 45,1 kb yang terekompresi menjadi 1,3 exabytes.

Apa prinsip / teknik yang akan digunakan untuk membuat file seperti itu di tempat pertama? Saya tidak ingin benar-benar melakukan ini, lebih tertarik pada penjelasan "cara kerja" yang disederhanakan dari konsep yang terlibat.

ps

Artikel ini menyebutkan 9 lapisan file zip, jadi ini bukan kasus sederhana untuk zip sekelompok nol. Mengapa 9, mengapa 10 file di masing-masing?

algorithm compression

— ikan buntal
sumber

5

@ Michael keluhan Anda tidak valid. OP tidak hanya bertanya bagaimana cara kerjanya, tidak ada dalam artikel yang diposting mengatakan itu untuk tujuan tegas menonaktifkan anti-virus. Justru sebaliknya, tampaknya dorongan artikel ini adalah serangan gaya DOS dengan hanya menyebutkan anti-virus menonaktifkan.

— San Jacinto

2

Intinya adalah bahwa OP merujuk ke file tertentu, yang terdiri dari arsip bersarang, bukan satu file besar terkompresi.

— Michael Borgwardt

1

Saya pikir Michael benar, dia menjelaskan cara membuat file yang dijelaskan dalam "PS", dan semua orang tidak. Namun, "PS" telah ditambahkan sebagai edit, sehingga jawaban itu mungkin tidak salah secara terang-terangan pada saat mereka diberikan. Mereka hanya berpikir "file seperti itu" berarti "file apa pun yang didekompresi menjadi 1,3 exabytes", ketika ternyata itu dimaksudkan untuk berarti "file yang terstruktur seperti yang dijelaskan dalam artikel yang saya tautkan ke".

— Steve Jessop

1

@ sendirian saya setuju sepenuhnya. Saya hanya tidak berpikir downvote sesuai dalam keadaan seperti itu.

— San Jacinto

4

Saya kira itu tergantung apakah Anda menganggap downvote berarti "ini bukan jawaban terbaik untuk pertanyaan", atau "Anda bodoh dan tidak layak untuk hidup", atau di antaranya. Secara pribadi, saya mengambil downvote berarti saya harus membaca kembali jawaban saya dan melihat apakah ada sesuatu yang salah dengan itu yang harus saya perbaiki. Tapi kemudian, saya cukup senang sekarang untuk tidak setuju dan tidak mengubah jawaban saya, jika saya pikir jawaban saya berkontribusi sesuatu. Dan saya menjadi agak tidak peduli tentang seluruh proses pemungutan suara, sekarang sudah jelas saya tidak akan pernah menangkap Jon Skeet ;-)

— Steve Jessop

92

Mengutip dari halaman Wikipedia:

Salah satu contoh bom Zip adalah file 45.1.zip yang merupakan 45,1 kilobyte data terkompresi, berisi sembilan lapisan file zip bersarang dalam set 10, setiap arsip lapisan bawah berisi file 1,30 gigabyte dengan total 1,30 exabyte data terkompresi .

Jadi yang Anda butuhkan hanyalah satu file 1.3GB penuh angka nol, kompres itu menjadi file ZIP, buat 10 salinan, kemas dalam file ZIP, dan ulangi proses ini 9 kali.

Dengan cara ini, Anda mendapatkan file yang, ketika tidak terkompresi sepenuhnya, menghasilkan jumlah data yang absurd tanpa mengharuskan Anda untuk memulai dengan jumlah itu.

Selain itu, arsip yang bersarang membuat program seperti pemindai virus (target utama "bom") jauh lebih sulit untuk menjadi pintar dan menolak membongkar arsip yang "terlalu besar", karena hingga tingkat terakhir jumlah total data adalah tidak sebanyak itu, Anda tidak "melihat" seberapa besar file di level terendah sampai Anda telah mencapai level itu, dan setiap file individual tidak "terlalu besar" - hanya sejumlah besar yang bermasalah.

— Michael Borgwardt
sumber

2

Tidak bisa ... setelah Anda zip file nol di bagian bawah, file zip yang dihasilkan tidak akan hampir sama kompresibel untuk lapisan berikutnya.

— ikan buntal

16

Ah, tetapi di setiap level, Anda memiliki sepuluh file identik - yang sekali lagi kompres dengan baik. Meskipun ZIP tidak mengeksploitasi redundansi file-silang, arsip yang berisi sepuluh file identik yang dikompresi secara individual mungkin memiliki banyak redundansi itu sendiri untuk dieksploitasi oleh lapisan berikutnya.

— Michael Borgwardt

10

Intinya BUKAN cara menghasilkan jumlah maksimum data dari file sekecil mungkin - intinya mengalahkan upaya pemindai virus untuk menjaga terhadap arsip yang terlalu besar.

— Michael Borgwardt

2

Itu bukan dorongan artikel di wikipedia. Tampaknya mendorong serangan gaya DOS.

— San Jacinto

2

Tetapi file-file tersebut tidak diekstraksi secara rekursif ... korban harus terus mengekstraksi file sub zip untuk membuatnya berfungsi ... Apa saja yang bisa dilakukan untuk mendapatkannya.

— Manoj

46

Buat file 1,3 exabyte nol.

Klik kanan> Kirim ke folder terkompresi (zip).

— wefwfwefwe
sumber

22

Anda lupa sarkasme "smiley."

— tvanfosson

1

Itu kemungkinan besar tidak mungkin terjadi pada kebanyakan sistem file dan algoritma kompresi karena batas ukuran file. Namun, file bersarang di arsip terkompresi (dan menempatkan lebih banyak arsip bersarang di arsip, jika algoritma kompresi memiliki batasan ukuran total) memungkinkan Anda untuk melewati batas ini.

— Blixt

133

harus membuat file 1,3 exabyte 1's. Mereka jauh lebih kurus dari 0 ini :)

— Quinn Wilson

33

@ Quinn - itu sebabnya mengompresi nol (lebih gemuk) jauh lebih efektif

— wefwfwefwe

1

Ini memberi Anda file zip> 1gb kecuali jika saya salah

— Chris S

36

Ini mudah dilakukan di Linux menggunakan perintah berikut:

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

Ganti hitungan dengan jumlah KB yang ingin Anda kompres. Contoh di atas membuat bom pos 10MiB (tidak banyak bom sama sekali, tetapi menunjukkan prosesnya).

Anda TIDAK membutuhkan ruang hard disk untuk menyimpan semua data yang tidak terkompresi.

— Thomi
sumber

8

Tetapi Anda membutuhkan daya komputasi untuk mengompresi data yang tidak terkompresi, itu masih O (n) dalam ukuran data yang tidak terkompresi .

— tonfa

2

Ya, seperti semua jawaban lainnya di sini.

— Thomi

6

Jawaban Michael Borgwardt adalah O (log N) dalam ukuran data yang tidak terkompresi.

— Steve Jessop

1

Bagaimanapun, kira-kira. Setiap pengulangan dari proses "menanggalkan header arsip, menduplikasi entri file terkompresi 10 kali, mengganti header arsip, kompres" meningkatkan tingkat penumpukan zip dengan 1, membutuhkan waktu sebanding dengan ukuran data terkompresi dari langkah sebelumnya. , mengalikan ukuran data yang tidak terkompresi dengan 10, dan jika itu meningkatkan ukuran data terkompresi sama sekali, tentu saja tidak melakukannya dengan faktor linear.

— Steve Jessop

3

Jadi sama seperti tes, saya zip -9 1,3 GB nol. Hasilnya adalah file 1,3 juta. Saya menduplikasi ini 10 kali (tidak bisa dipusingkan mengotak-atik header zip, sehingga hasilnya tidak akan berfungsi sebagai bom ritsleting, tetapi mengilustrasikan prinsipnya) untuk memberikan file 13M, yang kompres dengan zip -9 hingga 34381 byte. Jadi langkah duplikasi sebenarnya membuat file lebih kecil, karena deflate hanya mendukung token dengan ukuran maksimal tertentu. Langkah berikutnya menghasilkan 18453, kemudian 19012, 19312, 19743, 20120, 20531, 20870.

— Steve Jessop

10

Di bawah ini untuk Windows:

Dari bukti konsep Keamanan Fokus (NSFW!), Ini adalah file ZIP dengan 16 folder, masing-masing dengan 16 folder, yang berjalan seperti itu (42 adalah nama file zip):

\ 42 \ lib 0 \ book 0 \ chapter 0 \ doc 0 \ 0.dll
...
\ 42 \ lib F \ book F \ bab F \ doc F \ 0.dll

Saya mungkin salah dengan angka ini, tetapi menghasilkan 4 ^ 16 (4.294.967.296) direktori. Karena setiap direktori membutuhkan ruang alokasi N byte, itu akhirnya menjadi besar. File dll di akhir adalah 0 byte.

Buka ritsleting direktori pertama saja \42\lib 0\book 0\chapter 0\doc 0\0.dllmenghasilkan ruang alokasi 4gb.

— Chris S
sumber

27

Saya hanya berasumsi mereka wanita telanjang yang melakukan penelitian keamanan.

— James McMahon

3

Ritsletingnya adalah nsfw. Alarm merah panik yang besar akan berbunyi dan sangkar akan jatuh dari langit-langit di sekitar meja Anda

— Chris S

4

Jika setiap klik pada file virus menghasilkan wawancara dengan HR, maka Anda tidak perlu pemindai virus, atau Anda tidak perlu departemen SDM Anda. Salah satu dari mereka tidak berkontribusi pada bisnis ;-)

— Steve Jessop

2

Bisa juga NSFW karena Pemindai Virus Jaringan mungkin ingin memeriksanya - dan mengekstraknya untuk melakukannya.

— Michael Stum

5

Pemindai virus harus menandainya mencurigakan (yang dapat menyebabkannya diblokir dengan aman, atau dapat menyebabkan Anda dilaporkan secara tidak aman karena mencoba menginstal virus). Jika bom itu benar-benar meledak, maka departemen TI Anda telah mempelajari sesuatu yang berharga - mereka membutuhkan pemindai virus yang lebih baik.

— Steve Jessop

8

Jawaban serius:

(Pada dasarnya) Kompresi bergantung pada melihat pola yang berulang, sehingga file zip akan berisi data yang mewakili sesuatu seperti

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

File zip sangat pendek, tetapi besar saat Anda mengembangkannya.

— wefwfwefwe
sumber

1

Itu bisa dikompresi lebih jauh, sungguh: 0x1 (0x35) (yaitu, 0 kedua diulang 35 kali sehingga akan meluas ke komentar Anda)

— Michael

5

Untuk membuat satu dalam pengaturan praktis (yaitu tanpa membuat file 1,3 exabyte pada Anda harddisk besar), Anda mungkin harus mempelajari format file di tingkat biner dan menulis sesuatu yang menerjemahkan seperti apa file yang Anda inginkan akan terlihat seperti, pasca- kompresi.

— Andy_Vulhop
sumber

5

Artikel ini menyebutkan 9 lapisan file zip, jadi ini bukan kasus sederhana untuk zip sekelompok nol. Mengapa 9, mengapa 10 file di masing-masing?

Pertama, artikel Wikipedia saat ini mengatakan 5 lapisan dengan 16 file masing-masing. Tidak yakin dari mana perbedaan itu berasal, tetapi tidak semuanya relevan. Pertanyaan sebenarnya adalah mengapa menggunakan bersarang di tempat pertama.

DEFLATE, satu-satunya metode kompresi yang umum didukung untuk file zip *, memiliki rasio kompresi maksimum 1032. Ini dapat dicapai secara asimptot untuk setiap urutan berulang sebesar 1-3 byte. Apa pun yang Anda lakukan pada file zip, asalkan hanya menggunakan DEFLATE, ukuran yang dibongkar paling banyak 1032 kali dari ukuran file zip asli.

Oleh karena itu, perlu menggunakan file zip bersarang untuk mencapai rasio kompresi yang benar-benar keterlaluan. Jika Anda memiliki 2 lapisan kompresi, rasio maksimum menjadi 1032 ^ 2 = 1065024. Untuk 3, itu 1099104768, dan seterusnya. Untuk 5 lapisan yang digunakan pada 42.zip, rasio kompresi maksimum teoretis adalah 1170572956434432. Seperti yang Anda lihat, 42.zip yang sebenarnya jauh dari level itu. Sebagian dari itu adalah overhead format zip, dan sebagian lagi adalah mereka tidak peduli.

Jika saya harus menebak, saya akan mengatakan bahwa 42.zip dibentuk dengan hanya membuat file kosong yang besar, dan berulang kali zip dan menyalinnya. Tidak ada upaya untuk mendorong batas format atau memaksimalkan kompresi atau apa pun - mereka hanya secara sewenang-wenang mengambil 16 salinan per lapisan. Intinya adalah untuk menciptakan muatan besar tanpa banyak usaha.

Catatan: Format kompresi lainnya, seperti bzip2, menawarkan rasio kompresi maksimum yang jauh lebih banyak. Namun, sebagian besar parser zip tidak menerimanya.

PS Dimungkinkan untuk membuat file zip yang akan di-unzip ke salinannya sendiri (quine). Anda juga dapat membuat satu yang membuka ritsleting ke beberapa salinan itu sendiri. Oleh karena itu, jika Anda secara unzip mengekstrak file selamanya, ukuran maksimum yang mungkin tidak terbatas. Satu-satunya batasan adalah bahwa ia dapat meningkat paling banyak 1032 pada setiap iterasi.

PPS Angka 1032 mengasumsikan bahwa data file di zip terpisah. Satu kekhasan dari format file zip adalah bahwa ia memiliki direktori pusat yang mencantumkan file dalam arsip dan offset ke data file. Jika Anda membuat banyak entri file yang menunjuk ke data yang sama, Anda dapat mencapai rasio kompresi yang jauh lebih tinggi bahkan tanpa bersarang, tetapi file zip seperti itu kemungkinan akan ditolak oleh parser.

— Antimon
sumber

4

Cara yang bagus untuk membuat zipbomb (atau gzbomb) adalah mengetahui format biner yang Anda targetkan. Jika tidak, bahkan jika Anda menggunakan file streaming (misalnya menggunakan /dev/zero) Anda masih akan dibatasi oleh daya komputasi yang diperlukan untuk mengompresi aliran.

Contoh yang bagus dari bom gzip: http://selenic.com/googolplex.gz57 (ada pesan yang tersemat di file setelah beberapa tingkat kompresi yang menghasilkan file besar)

Bersenang-senang menemukan pesan itu :)

— tonfa
sumber

2

Mungkin, di unix, Anda dapat menyalurkan sejumlah nol langsung ke program zip atau sesuatu? Tidak cukup tahu tentang unix untuk menjelaskan bagaimana Anda akan melakukannya. Selain itu Anda akan membutuhkan sumber nol, dan pipa mereka ke ritsleting yang dibaca dari stdin atau sesuatu ...

— Svish
sumber

Diturunkan karena mengabaikan pertanyaan aktual, yang menyebutkan file tertentu yang secara eksplisit bukan hasil zipping satu arus besar nol.

— Michael Borgwardt

Tidak, Anda masih akan dibatasi oleh kekuatan komputasi. Idealnya Anda tidak ingin menjalankan gzip / zip karena akan menggunakan banyak CPU (atau setidaknya O (n) n menjadi ukuran file dekompresi)

— Tonfa

@tonfa: Ya, tentu saja Anda akan dibatasi oleh daya komputasi. Alasan saya adalah bahwa Anda mungkin tidak ingin membuat file besar exabyte pada disk Anda dan kemudian zip itu ...

— Svish

2

Semua algoritma kompresi file bergantung pada entropi informasi yang akan dikompresi. Secara teoritis Anda dapat memampatkan aliran 0 atau 1, dan jika cukup lama, itu akan memampatkan dengan sangat baik.

Itulah bagian teorinya. Bagian praktis telah ditunjukkan oleh orang lain.

— Ketenangan
sumber

2

Algoritma kompresi baru-baru ini (pasca 1995) seperti bz2, lzma (7-zip) dan rar memberikan kompresi spektakuler file monoton, dan satu lapisan kompresi cukup untuk membungkus konten yang terlalu besar ke ukuran yang dapat dikelola.

Pendekatan lain bisa dengan membuat file jarang dengan ukuran ekstrim (exabytes) dan kemudian kompres dengan sesuatu yang biasa yang mengerti file jarang (misalnya tar), sekarang jika pemeriksa mengalirkan file, pemeriksa perlu membaca melewati semua nol yang ada hanya untuk menghubungkan antara konten file yang sebenarnya, jika pemeriksa menulisnya ke disk, tetapi sangat sedikit ruang yang akan digunakan (dengan asumsi unarchiver berperilaku baik dan sistem file modern).

— pengguna340140
sumber

2

Sudah mencobanya. ukuran file zip output adalah file 84-KB kecil.

Langkah-langkah yang saya buat sejauh ini:

buat file .txt 1,4 GB yang penuh dengan '0'
kompres itu.
ganti nama .zip menjadi .txt lalu buat 16 salinan
kompres semua itu menjadi file .zip,
ganti nama file .txt yang diubah namanya di dalam file .zip menjadi .zip lagi
ulangi langkah 3 hingga 5 delapan kali.
Nikmati :)

meskipun saya tidak tahu bagaimana menjelaskan bagian di mana kompresi file zip berganti nama masih kompres menjadi ukuran yang lebih kecil, tetapi berfungsi. Mungkin saya hanya kekurangan persyaratan teknis.

— jaycroll
sumber

Omong-omong, jangan takut itu akan terus mengekstrak semua file zip di dalamnya. Itu hanya mengekstrak file zip yang bersarang di bawahnya, dan tidak semua jalan ke bawah.

— jaycroll

2

Silicon Valley Musim 3 Episode 7 membawaku ke sini. Langkah-langkah untuk menghasilkan bom ritsleting akan dilakukan.

Buat file dummy dengan nol (atau yang jika Anda pikir mereka kurus) dari ukuran (katakan 1 GB).
Kompres file ini ke file zip katakan 1.zip.
Buat n(katakan 10) salinan file ini dan tambahkan 10 file ini ke arsip terkompresi (katakanlah 2.zip).
Ulangi langkah 3 kbeberapa kali.
Anda akan mendapatkan bom ritsleting.

Untuk implementasi Python, periksa ini .

— Abdul Fatir
sumber

1

Saya tidak tahu apakah ZIP menggunakan Run Length Encoding, tetapi jika itu terjadi, file terkompresi seperti itu akan berisi sepotong kecil data dan nilai run-length yang sangat besar. Nilai run-length akan menentukan berapa kali potongan kecil data diulang. Ketika Anda memiliki nilai yang sangat besar, data yang dihasilkan proporsional besar.

— Joe
sumber

2

ZIP menggunakan kompresi Lempel-Ziv-Welch (atau versi modifikasi) yang secara efektif merusak data. Jangka panjang 'set' byte akan menghasilkan kompresi yang baik, karenanya mengapa GIF (yang juga menggunakan LZW) bagus untuk grafik dan JPEG (yang menggunakan kompresi gelombang sinus kompleks) lebih baik untuk foto yang datanya jauh lebih acak. '

— Lazarus