Artikel ini menunjukkan cara membuat bom zip non - rekursif yang memberikan tingkat kompresi tinggi dengan tumpang tindih file di dalam wadah zip. "Non-rekursif" berarti bahwa itu tidak bergantung pada dekompresi file dekompresi yang tertanam dalam arsip zip: hanya ada satu putaran. Ukuran output meningkat secara kuadrat dari input, mencapai rasio kompresi lebih dari 28 juta (10 MB → 281 TB) dalam format zip. Perluasan lebih lanjut dimungkinkan dengan ekstensi 64-bit. Desain hanya menggunakan algoritma kompresi DEFLATE paling umum dan kompatibel dengan sebagian besar parser zip.

• zbsm.zip 42 kB → 5,5 GB
  
• zblg.zip 10 MB → 281 TB
  
• zbxl.zip 46 MB → 4,5 PB (Zip64, kurang kompatibel dengan parser)

Kode Sumber:

  git clone https://www.bamsoftware.com/git/zipbomb.git 

zipbomb-20190702.zip

Data dan sumber ilustrasi:

  git clone https://www.bamsoftware.com/git/zipbomb-paper.git 

<sub>* Ada dua versi 42.zip: yang lama 42 374 byte, dan yang lebih baru 42 428 byte. Perbedaannya adalah bahwa yang baru memerlukan kata sandi sebelum membongkar. Kami membandingkan hanya dengan versi lama. Berikut adalah salinan file jika Anda memerlukannya: 42.zip .

** Saya ingin tahu dan menunjukkan penulis 42.zip, tetapi tidak dapat menemukannya - beri tahu saya jika Anda memiliki informasi.</sub>

Zip bom harus mengatasi kenyataan bahwa algoritma kompresi DEFLATE paling sering didukung oleh parser tidak dapat melebihi rasio kompresi 1032 ke 1. Untuk alasan ini, bom ritsleting biasanya mengandalkan dekompresi rekursif dengan memasukkan file zip ke dalam file zip untuk mendapatkan rasio tambahan 1032 dengan setiap lapisan. Tetapi trik ini hanya berfungsi dalam implementasi yang mendekompresi secara rekursif, dan sebagian besar tidak. Bom 42.zip yang paling terkenal berkembang menjadi 4,5 PB yang tangguh jika keenam lapisannya dibongkar secara rekursif, tetapi pada lapisan atas ia memiliki ukuran 0,6 MB. Zip quines, seperti milik Cox dan Ellingsen , mengeluarkan salinannya sendiri dan dengan demikian meluas tanpa batas waktu ketika dibongkar secara rekursif. Tetapi mereka juga benar-benar aman saat membongkar sekali.

Artikel ini menunjukkan cara membuat bom pos non-rekursif, rasio kompresi yang melebihi batas DEFLATE 1032. Ia bekerja dengan tumpang tindih file di dalam wadah zip untuk referensi "inti" dari data yang sangat terkompresi dalam beberapa file tanpa membuat banyak salinan. Ukuran output bom ritsleting tumbuh secara kuadrat dari ukuran input; yaitu, rasio kompresi meningkat dengan meningkatnya ukuran bom. Desainnya tergantung pada fitur zip dan DEFLATE: itu tidak dapat ditransfer langsung ke format file lain atau algoritma kompresi. Bom ini kompatibel dengan sebagian besar parser zip, kecuali untuk "streaming", yang menganalisis file dalam satu pass tanpa memeriksa direktori pusat file zip. Kami mencoba menyeimbangkan dua tujuan yang saling bertentangan:

• Tingkatkan rasio kompresi. Kami mendefinisikan rasio kompresi sebagai jumlah dari semua file dalam arsip dibagi dengan ukuran file zip itu sendiri. Itu tidak memperhitungkan nama file akun atau metadata sistem file lainnya, tetapi hanya isinya.
  
• Jaga kompatibilitas. Zip adalah format yang kompleks, dan parser berbeda, terutama dalam situasi garis batas, dan fungsi tambahan. Jangan gunakan teknik yang hanya bekerja dengan parser tertentu. Kami akan mencatat beberapa cara untuk meningkatkan efisiensi bom ritsleting dengan hilangnya kompatibilitas tertentu.

Struktur file zip

File zip terdiri dari direktori utama tautan file.



Direktori pusat ada di akhir file zip. Ini adalah daftar tajuk direktori pusat . Setiap header direktori pusat berisi metadata untuk satu file, seperti nama file dan CRC-32 checksum, serta pointer kembali ke header file lokal. Header direktori pusat memiliki panjang 46 byte plus panjang nama file.

File terdiri dari header file lokal, diikuti oleh data file terkompresi. Panjang header file lokal adalah 30 byte plus panjang nama file. Ini berisi salinan berlebihan metadata dari header direktori pusat, serta ukuran file data terkompresi dan tidak terkompresi di belakangnya. Zip adalah format wadah, bukan algoritma kompresi. Setiap data file dikompresi menggunakan algoritma yang ditentukan dalam metadata - biasanya DEFLATE .

Deskripsi format zip ini menghilangkan banyak detail yang tidak diperlukan untuk memahami bom zip. Untuk informasi lengkap, lihat bagian 4.3 APPNOTE.TXT atau "Struktur File PKZip" oleh Florian Buchholz, atau lihat kode sumber .

Redundansi yang signifikan dan banyak ambiguitas dalam format zip membuka peluang untuk kerusakan dari berbagai jenis. Sebuah bom ritsleting hanyalah puncak gunung es. Tautan untuk bacaan lebih lanjut:

• "Sepuluh Ribu Perangkap Keamanan: Format ZIP," oleh Ginwael Coldwind
  
• Penguraian zip yang ambigu memungkinkan Anda untuk menyembunyikan file add-on Firefox dari linter dan orang-orang : kerentanan saya di addons.mozilla.org

Penemuan pertama: tumpang tindih file

Dengan mengompresi string panjang byte berulang, kita dapat membuat inti dari data yang sangat terkompresi. Rasio kompresi kernel itu sendiri tidak dapat melebihi batas DEFLATE 1032, jadi kita perlu cara untuk menggunakan kembali kernel di banyak file, tanpa membuat salinan terpisah dari itu di setiap file. Kita dapat melakukan ini dengan tumpang tindih file: buat sedemikian sehingga banyak header dari direktori pusat menunjuk ke satu file yang datanya adalah inti.



Pertimbangkan contoh bagaimana desain ini memengaruhi rasio kompresi. Misalkan inti 1000 byte dibongkar dalam 1 MB. Kemudian megabita pertama dari output "biaya" 1078 byte data input:

• 31 byte untuk header file lokal (termasuk nama file 1 byte)
  
• 47 byte untuk header direktori pusat (termasuk nama file 1-byte)
  
• 1000 byte per inti

Tetapi setiap 1 MB output setelah biaya pertama hanya 47 byte - kita tidak perlu lagi header file lokal atau salinan kernel lain, hanya header tambahan dari direktori pusat. Dengan demikian, sementara tautan pertama dari inti memiliki rasio kompresi 1.000 000/1078 ≈ 928, setiap tautan tambahan memindahkan koefisien lebih dekat ke 1 000 000/47 ≈ 21 277, dan sebuah inti besar menaikkan langit-langit.

Masalah dengan ide ini adalah kurangnya kompatibilitas. Karena banyak tajuk dari direktori pusat mengarah ke satu tajuk dari file lokal, metadata (khususnya, nama file) tidak boleh sama untuk setiap file. Beberapa parser bersumpah akan hal ini . Misalnya, Info-ZIP UnZip (program unzip standar pada Unix) mengambil file, tetapi dengan peringatan:

  $ unzip overlap.zip
   menggembungkan: A
 B: ketidakcocokan nama file "lokal" (A),
          melanjutkan dengan nama file "central"
   menggembungkan: B
 ... 

Python zipfile juga melempar pengecualian :

  $ python3 -m zipfile -e overlap.zip.
 Traceback (panggilan terakhir terakhir):
 ...
 __main __. BadZipFile: Nama file di direktori 'B' dan header b'A 'berbeda. 

Selanjutnya, kita akan melihat bagaimana mendesain ulang konsistensi nama file, sambil mempertahankan sebagian besar manfaat dari file yang tumpang tindih.

Penemuan kedua: mengutip header file lokal

Kita perlu memisahkan header file lokal untuk setiap file, sambil menggunakan kembali satu inti. Menggabungkan semua header saja tidak berfungsi, karena parser zip akan menemukan header file lokal di mana ia mengharapkan dimulainya aliran DEFLATE. Tapi idenya akan berhasil, dengan perubahan kecil. Kami akan menggunakan fungsi DEFLATE dari blok yang tidak terkompresi untuk "mengutip" header file lokal sehingga mereka tampaknya menjadi bagian dari aliran DEFLATE yang sama yang berakhir di kernel. Setiap header file lokal (kecuali yang pertama) akan ditafsirkan dalam dua cara: sebagai kode (bagian dari struktur file zip) dan sebagai data (bagian dari konten file).



Aliran DEFLATE adalah urutan blok di mana setiap blok dapat dikompresi atau tidak terkompresi. Kami biasanya hanya berpikir tentang blok terkompresi, misalnya, kernel adalah salah satu blok terkompresi besar. Tetapi ada juga yang tidak terkompresi yang dimulai dengan header 5-byte dengan bidang panjang, yang berarti: "cetak n byte berikutnya kata demi kata." Membongkar blok yang tidak terkompresi berarti hanya menghapus header 5-byte. Blok terkompresi dan tidak terkompresi dapat bercampur secara bebas dalam aliran DEFLATE. Outputnya adalah gabungan dari hasil unpacking semua blok secara berurutan. Konsep "tidak terkompresi" hanya penting di tingkat DEFLATE; data file masih dianggap "dikompresi" di tingkat zip, terlepas dari blok mana yang digunakan.

Cara termudah untuk membayangkan desain ini adalah sebagai tumpang tindih internal, dari file terakhir ke yang pertama. Kami mulai dengan memasukkan kernel yang akan membentuk akhir file data untuk setiap file. Tambahkan tajuk file LFH _N lokal dan tajuk direktori pusat CDH _N yang menunjuk ke sana. Setel bidang metadata "ukuran terkompresi" dalam LFH _N dan CDH _N ke ukuran inti terkompresi. Sekarang tambahkan header 5-byte dari blok terkompresi (berwarna hijau pada diagram), bidang panjangnya sama dengan ukuran LFH _N. Tambahkan header kedua dari file LFH lokal _{N −1} dan judul direktori pusat CDH _{N −1} , yang mengarah ke sana. Setel bidang metadata "ukuran terkompresi" sebagai header baru untuk ukuran kernel terkompresi plus ukuran header blok tidak terkompresi (5 byte) plus ukuran LFH _N.

Saat ini, file zip berisi dua file dengan nama Y dan Z. Mari kita lihat apa yang akan dilihat parser ketika parsing. Misalkan ukuran kernel yang dikompresi adalah 1000 byte dan ukuran LFH _N adalah 31 byte. Kita mulai dengan CDH _{N −1} dan ikuti tanda untuk LFH _{N −1} . Nama file pertama adalah Y, dan ukuran file datanya yang dikompresi adalah 1036 byte. Menafsirkan 1036 byte berikutnya sebagai aliran DEFLATE, pertama-tama kita akan menemukan header 5-byte dari blok terkompresi yang mengatakan untuk menyalin 31 byte berikutnya. Kami menuliskan 31 byte berikutnya, yaitu LFH _N , yang kami ekstrak dan tambahkan ke file Y. Bergerak lebih jauh dalam aliran DEFLATE, kami menemukan blok terkompresi (kernel) yang kami ekstrak ke dalam file Y. Sekarang kami telah mencapai akhir data terkompresi dan selesai dengan file Y.

Pindah ke file berikutnya, kita mengikuti pointer dari CDH _N ke LFH _N dan menemukan file bernama Z dengan ukuran terkompresi 1000 byte. Menafsirkan 1000 byte ini sebagai aliran DEFLATE, kami segera menemukan blok terkompresi (inti lagi) dan membongkar itu menjadi file Z. Sekarang kami telah mencapai akhir file terakhir dan selesai. File keluaran Z berisi kernel yang belum dibongkar; file keluaran Y adalah sama, tetapi secara opsional dengan awalan 31 byte LFH _N.

Kami menyelesaikan konstruksi dengan mengulangi prosedur kutipan hingga arsip zip menyertakan jumlah file yang diperlukan. Setiap file baru menambahkan header direktori pusat, header file lokal, dan blok terkompresi untuk mengutip langsung dari header file lokal berikutnya. Data file terkompresi biasanya merupakan rantai blok DEFLATE yang tidak terkompresi (dikutip file header lokal) diikuti oleh inti terkompresi. Setiap byte dalam kernel berkontribusi sekitar 1032 N ke ukuran output, karena setiap byte adalah bagian dari semua file N. File-file output juga dari ukuran yang berbeda: yang sebelumnya lebih besar daripada yang kemudian karena mereka mengutip lebih banyak header dari file lokal. Isi file output tidak masuk akal, tetapi tidak ada yang mengatakan bahwa itu masuk akal.

Desain kutipan tumpang tindih ini memiliki kompatibilitas yang lebih baik daripada desain tumpang tindih penuh dari bagian sebelumnya, tetapi kompatibilitas dicapai melalui kompresi. Di sana, setiap file yang ditambahkan hanya biaya judul direktori pusat, di sini harganya judul direktori pusat, header file lokal dan 5 byte lainnya untuk header kutipan.

Optimasi

Setelah menerima desain dasar bom ritsleting, kami akan berusaha membuatnya seefisien mungkin. Kami ingin menjawab dua pertanyaan:

• Berapa rasio kompresi maksimum untuk ukuran file zip yang diberikan?
  
• Berapa rasio kompresi maksimum yang diberikan keterbatasan format zip?

Kompresi Kernel

Hal ini bermanfaat bagi kita untuk mengompresi kernel sebanyak mungkin, karena setiap byte yang dibongkar dikalikan dengan N. Untuk tujuan ini, kami menggunakan kompresor DEFLATE khusus yang disebut bulk_deflate, khusus mengkompresi serangkaian byte yang diulang.

Semua pengarsipan DEFLATE yang layak mendekati rasio kompresi 1032 pada aliran byte berulang yang tak ada habisnya, tetapi kami khawatir tentang ukuran spesifik. Dalam ukuran arsip kami, bulk_deflate menyimpan lebih banyak data daripada arsip tujuan umum: sekitar 26 KB lebih banyak dari zlib dan Info-ZIP, dan sekitar 15 KB lebih banyak dari Zopfli , yang mengorbankan kecepatan demi kualitas kompresi.



Harga bulk_deflate rasio kompresi yang tinggi - kurangnya fleksibilitas. Ia dapat memampatkan hanya garis byte berulang dan hanya panjang tertentu, yaitu 517 + 258 k untuk integer k ≥ 0. Selain kompresi yang baik, bulk_deflate bekerja dengan cepat, melakukan pekerjaan dalam waktu yang hampir sama terlepas dari ukuran data input, menghitung pekerjaan menulis string terkompresi.

Nama file

Untuk tujuan kami, nama file hampir mati berat. Meskipun mereka berkontribusi pada ukuran output dengan menjadi bagian dari tajuk file lokal yang dikutip, byte dalam nama file berkontribusi jauh lebih sedikit daripada byte dalam kernel. Kami ingin nama file sesingkat mungkin, sementara menjadi berbeda, tanpa melupakan kompatibilitas.

Setiap byte yang dihabiskan untuk nama file berarti dua byte yang tidak dihabiskan untuk kernel (dua karena setiap nama file muncul dua kali: di header direktori pusat dan di header file lokal). Byte nama file menghasilkan rata-rata hanya ( N + 1) / 4 byte output, sedangkan byte dalam kernel dihitung sebagai 1032 N. Contoh: 1 , 2 , 3 .

Pertimbangan kompatibilitas pertama adalah penyandian. Spesifikasi format zip menyatakan bahwa nama file harus ditafsirkan sebagai CP 437 atau UTF-8 jika bit flag tertentu diatur ( APPNOTE.TXT, lampiran D ). Ini adalah titik utama ketidakcocokan antara parser zip, yang dapat menafsirkan nama file dalam beberapa pengkodean tetap atau lokal-spesifik. Oleh karena itu, untuk kompatibilitas, lebih baik membatasi diri Anda pada karakter dengan penyandian yang sama di CP 437 dan UTF-8. Yaitu, ini adalah 95 karakter US-ASCII yang dapat dicetak.

Kami juga terikat oleh pembatasan penamaan sistem file. Beberapa sistem file tidak sensitif huruf besar, jadi 'a' dan 'A' tidak dianggap sebagai nama yang berbeda. Sistem file umum, seperti FAT32, melarang karakter tertentu , seperti '*' dan '?'.

Sebagai kompromi yang aman, tetapi belum tentu optimal, bom ritsleting kami akan menggunakan nama file dari alfabet 36 karakter, yang tidak termasuk karakter khusus dan karakter dari berbagai kasus:

  0 1 2 3 4 5 6 7 8 9 ABCDEFGHIJKLMNOPQRSTU VWXYZ 

Nama file dihasilkan dengan cara yang jelas, semua posisi pada gilirannya, dengan penambahan posisi pada akhir loop:

  "0", "1", "2", ..., "Z",
 "00", "01", "02", ..., "0Z",
 ...
 "Z0", "Z1", "Z2", ..., "ZZ",
 "000", "001", "002", ... 

Ada 36 nama file satu karakter, 36² nama dua karakter, dan sebagainya. Empat byte cukup untuk 1.727.604 nama file yang berbeda.

Mengingat bahwa nama file dalam arsip biasanya memiliki panjang yang berbeda, bagaimana saya bisa mengurutkannya: dari yang terpendek ke yang terpanjang atau sebaliknya? Jika Anda berpikir sedikit, lebih baik untuk menempatkan nama terpanjang di belakang. Penyortiran ini menambahkan lebih dari 900 MB output ke zblg.zip , dibandingkan dengan pemesanan terpanjang ke terpendek. Namun, ini adalah optimasi kecil, karena 900 MB hanya 0,0003% dari total ukuran masalah.

Ukuran inti

Desain penawaran yang tumpang tindih memungkinkan Anda menempatkan inti data terkompresi, dan kemudian menyalinnya dengan murah berkali-kali. Untuk ukuran tertentu file zip X , berapa banyak ruang yang optimal untuk dialokasikan untuk menyimpan kernel, dan berapa banyak untuk membuat salinan?

Untuk menemukan keseimbangan optimal, Anda hanya perlu mengoptimalkan satu variabel N , jumlah file dalam arsip zip. Setiap nilai N memerlukan sejumlah overhead tertentu untuk header direktori pusat, header file lokal, header blok kutipan, dan nama file. Sisa ruang akan ditempati oleh inti. Karena N harus berupa bilangan bulat, dan Anda hanya bisa meletakkan sejumlah file tertentu sebelum ukuran kernel turun ke nol, itu sudah cukup untuk memeriksa setiap nilai yang mungkin dari N dan memilih salah satu yang memberikan output terbesar.

Menerapkan prosedur optimisasi ke X = 42.374 untuk 42.zip menemukan maksimum pada N = 250. 250 file ini membutuhkan 21.195 byte overhead, meninggalkan 21.179 byte untuk kernel. Kernel dengan ukuran ini diurai menjadi 21.841.249 byte (rasio 1031,3 banding 1). 250 salinan dari kernel yang belum dibongkar ditambah beberapa header file lokal yang dikutip memberikan total keluaran yang tidak dibongkar sebesar 5.461.307.620 byte dan rasio kompresi 129.000.

• zbsm.zip 42 kB → 5,5 GB

  zipbomb --mode = dikutip_overlap --num-files = 250 --compressed-size = 21179> zbsm.zip 

Optimalisasi telah menghasilkan distribusi ruang yang hampir merata antara kernel dan header file. Ini bukan kebetulan. Pertimbangkan model konstruksi kutipan yang disederhanakan dengan tumpang tindih. Dalam model yang disederhanakan, kami mengabaikan nama file, serta sedikit peningkatan dalam ukuran file output karena mengutip header file lokal. Analisis model yang disederhanakan akan menunjukkan bahwa distribusi optimal antara kernel dan file header kira-kira seragam, dan ukuran output dengan distribusi optimal tumbuh secara kuadrat tergantung pada ukuran input.

Definisi beberapa konstanta dan variabel:


Misalkan H (N) menjadi volume overhead untuk header untuk file N. Lihat grafik untuk memahami esensi formula.

$$

$$H (N) = N ⋅ (CDH + LFH) + (N - 1) ⋅ Q$$

Untuk kernel, X - H (N) tetap ada. Total ukuran yang tidak dibongkar S _X (N) sama dengan ukuran N salinan dari kernel yang dibongkar dengan rasio C (dalam model yang disederhanakan ini, kami mengabaikan sedikit ekstensi tambahan dari header file lokal yang disebutkan).

$$$$ menampilkan $$ S_X (N) = (X - H (N)) CN \\ = (X - (N ⋅ (CDH + LFH) + (N - 1) ⋅ Q)) CN \\ = - (CDH + LFH + Q) CN ^ 2 + (X + Q) CN $$ menampilkan $$

S _X (N) adalah polinomial di bagian N, oleh karena itu, maksimum harus di mana turunan S ' _X (N) sama dengan nol. Mengambil turunan dan menemukan nol memberi kita N _OPT , jumlah file yang optimal.

$$$$ menampilkan $$ S′X (N_ {OPT}) = −2 (CDH + LFH + Q) C N_ {OPT} + (X + Q) C \\ 0 = −2 (CDH + LFH + Q) C N_ {OPT} + (X + Q) C \\ N_ {OPT} = (X + Q) / (CDH + LFH + Q) / 2 $$ menampilkan $$

H (N _OPT ) memberikan jumlah ruang yang optimal untuk menempatkan header file. Ini tidak tergantung pada CDH, LFH dan C dan dekat dengan X / 2 .

$$$$ menampilkan $$ H (N_ {OPT}) = N_ {OPT} ⋅ (CDH + LFH) + (N_ {OPT} - 1) ⋅ Q \\ = (X - Q) / 2 $$ menampilkan $$

S _X (N _OPT ) - total ukuran tanpa kemasan pada distribusi optimal. Dari sini kita melihat bahwa ukuran output meningkat kuadratik dengan meningkatnya data input.

$$

$$S_X (N_ {OPT}) = (X + Q) ^ 2C / (CDH + LFH + Q) / 4$$

Meningkatkan ukuran file zip, pada akhirnya kita akan menemui batas format zip: arsip dapat memiliki tidak lebih dari 2 ¹⁶ −1 file dengan ukuran masing-masing tidak lebih dari 2 ³² −1 byte. Lebih buruk lagi, beberapa implementasi mengambil nilai maksimum sebagai indikator keberadaan ekstensi 64-bit , sehingga batas kami sebenarnya adalah 2 ¹⁶ −2 dan 2 ³² −2. Itu terjadi saat pertama kali kami menemukan batas ukuran file yang tidak terkompresi. Dengan ukuran file zip 8 319 377 bytes, optimasi naif akan memberi kita jumlah file 47 837 dan file maksimum 2 ³² +311 bytes.

(Sebenarnya, semuanya sedikit lebih rumit, karena batas yang tepat tergantung pada implementasi. Zipfile Python mengabaikan jumlah file, arsip / zip di Go memungkinkan Anda untuk meningkatkan jumlah file sampai mereka cocok dengan 16 bit yang lebih rendah. Tetapi untuk kompatibilitas umum, kita harus mematuhi batas yang ditetapkan).

Jika kami tidak dapat meningkatkan ukuran N atau kernel tanpa batas, kami ingin menemukan rasio kompresi maksimum dalam format zip. Anda perlu membuat kernel sebesar mungkin dengan jumlah file maksimum. Terlepas dari kenyataan bahwa kita tidak dapat lagi mempertahankan kira-kira pemisahan yang seragam antara kernel dan header file, setiap file yang ditambahkan masih meningkatkan rasio kompresi - hanya saja tidak secepat jika kita dapat terus meningkatkan kernel. Bahkan, ketika file ditambahkan, kita perlu mengurangi ukuran kernel untuk membebaskan ruang untuk ukuran file maksimum, yang tumbuh sedikit dengan setiap file ditambahkan.

Rencananya mengarah ke arsip zip dengan 2 ¹⁶ −2 file dan kernel, yang dibongkar menjadi 2 ³² −2 178 825 byte. File akan lebih besar menjelang awal arsip zip - file pertama dan terbesar dibuka dalam 2 ³² 3256 byte. Ini sedekat kita dapat menggunakan parameter output kasar bulk_deflate - pengkodean 54 byte terakhir akan lebih mahal dari ukurannya (file zip secara keseluruhan memiliki rasio kompresi 28 juta, dan 54 byte terakhir akan menerima maksimum 54 ⋅ 10 ³² ⋅ ( 2 ¹⁶ - 2) ≈ 36? 5 juta byte, jadi ini hanya membantu jika 54 byte dapat dikodekan menjadi satu byte - dan saya tidak dapat mengkodekan kurang dari dua. Oleh karena itu, jika Anda tidak dapat menyandikan 54 byte menjadi 1 byte, ini hanya mengurangi rasio kompresi). Ukuran output bom ritsleting ini adalah 281.395.456.244.934 byte, 99,97% dari maksimum teoritis (2 ³² - 1) × (2 ¹⁶ - 1). Peningkatan rasio kompresi yang signifikan hanya dapat dicapai dengan mengurangi ukuran sinyal input, dan bukan dengan meningkatkan output.

• zblg.zip 10 MB → 281 TB

  zipbomb --mode = dikutip_overlap --num-files = 65534 --max-uncompressed-size = 4292788525> zblg.zip 

Komputasi CRC-32 yang Efisien

Di antara metadata di header direktori pusat dan header file lokal adalah checksum dari data file yang tidak terkompresi - CRC-32 . Ini menimbulkan masalah karena jumlah perhitungan CRC-32 untuk setiap file sebanding dengan ukurannya, yang sangat besar secara default (setelah semua, ini adalah bom ritsleting). Kami lebih suka melakukan pekerjaan yang setidaknya sebanding dengan ukuran arsip. Dua faktor berfungsi untuk kami: semua file memiliki inti yang sama, dan kernel yang tidak terkompresi adalah serangkaian byte yang diulang. Bayangkan CRC-32 sebagai produk matriks - ini akan memungkinkan kita tidak hanya dengan cepat menghitung checksum dari kernel, tetapi juga untuk menggunakan kembali perhitungan antar file. Metode yang dijelaskan dalam bagian ini adalah ekstensi kecil dari fungsi crc32_combine di zlib, yang dijelaskan Mark Adler di sini .

CRC-32 dapat dimodelkan sebagai mesin negara, memperbarui register status 32-bit untuk setiap bit input. Operasi pembaruan dasar untuk bit 0 dan 1 adalah:

 uint32 crc32_update_0(uint32 state) { // Shift out the least significant bit. bit b = state & 1; state = state >> 1; // If the shifted-out bit was 1, XOR with the CRC-32 constant. if (b == 1) state = state ^ 0xedb88320; return state; } uint32 crc32_update_1(uint32 state) { // Do as for a 0 bit, then XOR with the CRC-32 constant. return crc32_update_0(state) ^ 0xedb88320; } 

Jika Anda mewakili register status sebagai vektor biner 32-elemen dan menggunakan XOR untuk penambahan dan perkalian, maka crc32_update_0 adalah pemetaan linear ; yaitu, dapat direpresentasikan sebagai perkalian dengan matriks transisi biner 32 × 32. Untuk memahami alasannya, perhatikan bahwa mengalikan matriks dengan vektor cukup dengan menambahkan kolom dari matriks setelah mengalikan setiap kolom dengan elemen vektor yang sesuai. state >> 1 operasi shift state >> 1 hanya mengambil setiap bit i dari vektor state dan mengalikannya dengan vektor yang nol di mana-mana kecuali bit i - 1 (penomoran bit dari kanan ke kiri). Secara relatif, status XOR akhir state ^ 0xedb88320 terjadi hanya ketika bit b sama dengan satu. Ini dapat direpresentasikan sebagai perkalian b pertama dengan 0xedb88320, dan kemudian XORing ke status ini.

Juga, crc32_update_1 hanyalah crc32_update_0 plus (XOR).Ini membuat crc32_update_1 transformasi affine : perkalian matriks diikuti oleh pemetaan (mis., Penambahan vektor). Kita dapat membayangkan perkalian dan pemetaan matriks dalam satu langkah, jika kita meningkatkan ukuran matriks transformasi menjadi 33 × 33 dan menambahkan elemen tambahan ke vektor state, yang selalu 1 (representasi ini disebut koordinat homogen ).


Matriks transformasi adalah 33 × 33 M ₀ dan M ₁ , yang menghitung perubahan status CRC-32 yang dibuat oleh bit 0 dan 1, masing-masing. Vektor kolom disimpan dengan bit paling signifikan di bawah ini: membaca kolom pertama dari bawah ke atas, Anda melihat konstanta polinomial CRC-32 edb8832016 = 111 0 11 0 110 111 000 1 00000 11 00 1 00000 ₂ . Kedua matriks ini hanya berbeda pada kolom terakhir, yang mewakili vektor terjemahan dalam koordinat homogen. Di M _0, terjemahannya adalah nol, dan di M ₁ adalah edb88320 ₁₆ , konstanta polinomial adalah CRC-32. Unit yang tepat di atas status diagonal operasistate >> 1

Kedua operasicrc32_update_0dancrc32_update_1dapat direpresentasikan oleh matriks transisi dari 33 × 33. Matriks M ₀ dan M ₁ ditampilkan.. Keuntungan dari representasi matriks adalah bahwa matriks dapat dikalikan. Misalkan kita ingin melihat perubahan status yang dibuat dengan memproses karakter ASCII 'a', yang representasi binernya adalah 01100001 ₂ . Kita dapat membayangkan perubahan kumulatif dalam keadaan CRC-32 dari delapan bit ini dalam satu matriks transformasi:

$$

$$M_a = M_0 M_1 M_1 M_0 M_0 M_0 M_0 M_1$$

Dan kita bisa membayangkan perubahan status bar mengulangi 'a' dengan mengalikan banyak salinan M _dan - pembangunan matriks kekuasaan. Kita dapat melakukan ini dengan cepat menggunakan algoritma eksponensial cepat , yang memungkinkan untuk menghitung M ⁿ cukup log ₂ ⁿ langkah. Misalnya, berikut adalah matriks untuk mengubah status string 9 karakter 'a':

$$

$$(M_a)^9 = M_a M_a M_a M_a M_a M_a M_a M_a M_a\\ = (M_a M_a M_a M_a)^2 M_a\\ = ((M_a M_a)^2)^2 M_a\\ = (((M_a)^2)^2)^2 M_a$$

Algoritma multiplikasi cepat matriks berguna untuk menghitung _kernel M , sebuah matriks untuk kernel yang tidak terkompresi, karena kernel adalah serangkaian byte yang diulang. Untuk mendapatkan CRC-32 checksum dari matriks, kalikan matriks dengan vektor nol (vektor nol dalam koordinat seragam, yaitu 32 nol, dan kemudian unit; di sini kita menghilangkan sedikit komplikasi dari pra dan pasca pemrosesan checksum untuk memeriksa kepatuhan). Untuk menghitung checksum untuk setiap file, kami bekerja di arah yang berlawanan. Kita mulai dengan menginisialisasi M: = M _kernel . Kernel checksum juga merupakan checksum dari file final N , jadi kami mengalikan Mvektor nol dan toko checksum yang diterima di CDH _N dan LFH _N . Data file N - 1 sama dengan data file file N , tetapi dengan awalan LFH _N ditambahkan . Karena itu, kami menghitung$$M L F H N , nyatakan matriks perubahan untuk LFH_Ndan perbarui$M_{L{FH_N}}$$$$M := M M_{L{FH_N}}$ .Sekarang M mewakili perubahan kumulatif keadaan dari pemrosesan LFH _{N di} belakang nukleus. Kami menghitung checksum untuk file N - 1 , sekali lagi mengalikan M dengan vektor nol. Kami melanjutkan prosedur dengan mengakumulasi status perubahan matriks dalam M hingga semua file diproses.

Ekstensi: Zip64

Sebelumnya, kami menghadapi masalah ekspansi karena keterbatasan format zip - tidak mungkin untuk menerbitkan lebih dari 281 TB, terlepas dari seberapa pintar file zip itu dikemas. Anda dapat melampaui batas ini menggunakan Zip64, ekstensi format zip yang meningkatkan ukuran beberapa bidang tajuk menjadi 64 bit. Dukungan untuk Zip64 sama sekali tidak universal, tetapi itu adalah salah satu ekstensi yang paling umum diterapkan. Adapun rasio kompresi, efek Zip64 adalah untuk meningkatkan ukuran header dari direktori pusat dari 46 menjadi 58 byte, dan ukuran header dari direktori lokal dari 30 hingga 50 byte. Melihat rumus koefisien ekspansi optimal dalam model yang disederhanakan, kita melihat bahwa bom ritsleting dalam format Zip64 masih tumbuh secara kuadrat, tetapi lebih lambat karena penyebut yang lebih besar - ini dapat dilihat pada diagram di bawah ini. Karena hilangnya kompatibilitas dan retardasi pertumbuhan, kami menghapus hampir semua batasan ukuran file.

Misalkan kita membutuhkan bom ritsleting yang mengembang hingga 4,5 PB, seperti 42.zip. Seberapa besar arsip itu? Menggunakan pencarian biner, kami menemukan bahwa ukuran minimum file tersebut adalah 46 MB.

• zbxl.zip 46 MB → 4,5 PB (Zip64, kurang kompatibel)

 zipbomb --mode = dikutip_overlap --num-files = 190023 - ukuran terkompresi = 22982788 --zip64> zbxl.zip 

4,5 petabyte - jumlah data yang kira-kira sama direkam oleh Teleskop Cakrawala Peristiwa untuk gambar pertama dari lubang hitam : rak dan rak dengan hard drive di pusat data.

Dengan Zip64, hampir tidak menarik untuk mempertimbangkan rasio kompresi maksimum, karena kita dapat terus meningkatkan ukuran file zip dan rasio kompresi bersamanya, hingga bahkan file zip terkompresi menjadi penghalang. Ambang batas yang menarik, bagaimanapun, adalah 2 ⁶⁴ byte (18 EB atau 16 EiB) - begitu banyak data yang tidak sesuai pada kebanyakan sistem file. Pencarian biner menemukan bom ritsleting terkecil yang menghasilkan setidaknya sebanyak output: berisi 12 juta file dan inti terkompresi 1,5 GB. Total ukuran file zip adalah 2,9 GB dan dibongkar dalam 2 ⁶⁴+11 727 895 877 byte dengan rasio kompresi lebih dari 6,2 miliar menjadi satu. Saya tidak mengunggah file ini untuk diunduh, tetapi Anda dapat membuatnya sendiri menggunakan kode sumber . Ia memiliki file dengan ukuran sedemikian rupa sehingga bug pun terungkap di Info-ZIP UnZip 6.0.

 zipbomb --mode = dikutip_overlap --num-files = 12056313 --compressed-size = 1482284040 --zip64> zbxxl.zip 

Ekstensi: bzip2

DEFLATE adalah algoritma kompresi paling umum untuk format zip, tetapi ini hanya satu dari banyak opsi. Mungkin algoritma paling umum kedua adalah bzip2 . Meskipun tidak kompatibel dengan DEFLATE. Secara teoritis, dalam bzip2, rasio kompresi maksimum adalah sekitar 1,4 juta berbanding satu, yang memungkinkan pengemasan inti yang lebih padat.

bzip2 pertama kali mengkodekan “run-length encoding”, mengurangi panjang string byte berulang sebanyak 51 kali. Kemudian data dibagi menjadi 900 KB blok dan setiap blok dikompresi secara terpisah. Secara teoritis, satu blok dapat mengkompres hingga 32 byte. 900 000 × 51/32 = 1 434 375.

Mengabaikan hilangnya kompatibilitas, apakah bzip2 membuat bom yang lebih efektif?

Ya - tetapi hanya untuk file kecil. Masalahnya adalah bahwa dalam bzip2 tidak ada yang seperti blok DEFLATE terkompresi yang kami gunakan untuk mengutip header file lokal. Dengan demikian, tidak mungkin untuk tumpang tindih file dan menggunakan kembali kernel - untuk setiap file Anda perlu menulis salinan Anda sendiri, sehingga rasio kompresi keseluruhan tidak akan lebih baik daripada rasio untuk file tunggal. Pada grafik di bawah ini, kita melihat bahwa tanpa tumpang tindih, bzip2 lebih unggul daripada DEFLATE hanya untuk file berukuran megabyte.

Hanya ada harapan untuk cara alternatif mengutip header di bzip2, yang dibahas di bagian selanjutnya. Selain itu, jika Anda tahu bahwa parser zip tertentu mendukung bzip2 danmemungkinkan untuk nama file yang tidak cocok, Anda dapat menggunakan konstruksi tumpang tindih yang lengkap, yang tidak perlu dikutip.


Perbandingan rasio kompresi bom ritsleting yang berbeda. Perhatikan sumbu logaritmik. Setiap desain ditampilkan dengan dan tanpa Zip64. Struktur tanpa tumpang tindih memiliki tingkat pertumbuhan linier, yang dapat dilihat dari rasio konstan sumbu. Offset vertikal dari grafik bzip2 berarti bahwa rasio kompresi bzip2 sekitar seribu kali lebih besar daripada DEFLATE. Konstruksi DEFLATE yang dikutip memiliki tingkat pertumbuhan kuadrat, sebagaimana dibuktikan dengan kecenderungan sumbu 2: 1. Varian Zip64 sedikit kurang efektif, tetapi memungkinkan untuk lebih dari 281 TB. Grafik untuk bzip2 dengan mengutip melalui bidang tambahan beralih dari kuadrat ke linier saat salah satu ukuran file maksimum tercapai (2 ³² −2 byte), atau jumlah file maksimum yang diizinkan

Ekstensi: mengutip melalui bidang tambahan

Sejauh ini, kami telah menggunakan fungsi DEFLATE untuk mengutip header file lokal, dan kami baru saja melihat bahwa trik ini tidak berfungsi di bzip2. Namun, ada metode kutipan alternatif, agak lebih terbatas, yang hanya menggunakan fungsi format zip dan tidak tergantung pada algoritma kompresi.

Di akhir struktur tajuk file lokal, ada bidang tambahan panjang variabel untuk menyimpan informasi yang tidak sesuai dengan bidang tajuk biasa ( APPNOTE.TXT, bagian 4.3.7) Informasi tambahan dapat mencakup, misalnya, cap waktu atau uid / gid dari Unix. Informasi Zip64 juga disimpan di bidang tambahan. Bidang tambahan direpresentasikan sebagai struktur nilai panjang; jika Anda menambah panjang tanpa menambahkan nilai, bidang tambahan akan menyertakan apa yang ada di belakangnya dalam file zip, yaitu header berikutnya dari file lokal. Dengan menggunakan metode ini, setiap header file lokal dapat "mengutip" header berikut, melampirkannya di bidang tambahan sendiri. Dibandingkan dengan DEFLATE, ada tiga keuntungan:

1. Mengutip melalui bidang tambahan hanya membutuhkan 4 byte, bukan 5, meninggalkan lebih banyak ruang untuk kernel.
   
2. Itu tidak meningkatkan ukuran file, yang berarti kernel yang lebih besar, mengingat keterbatasan format zip.
   
3. Ini memberikan penawaran dalam bzip2.

Terlepas dari keunggulan ini, mengutip melalui bidang tambahan kurang fleksibel. Ini bukan rantai, seperti dalam DEFLATE: setiap judul file lokal harus berisi tidak hanya heading berikut segera, tetapi juga semua heading berikutnya. Bidang tambahan bertambah saat Anda mendekati awal file zip. Karena panjang bidang maksimum adalah 2 ¹⁶ −1 byte, hanya hingga 1808 header file lokal (atau 1170 dalam Zip64) yang dapat dikutip, dengan asumsi nama diberikan seperti yang diharapkan(dalam hal DEFLATE, Anda dapat menggunakan bidang tambahan untuk mengutip header file lokal yang pertama (terpendek), dan kemudian beralih ke mengutip DEFLATE untuk yang lain). Masalah lain: agar sesuai dengan struktur data internal bidang tambahan, perlu untuk memilih tag 16-bit untuk jenis ( APPNOTE.TXT, bagian 4.5.2 ) sebelum data kutipan. Kami ingin memilih tag jenis yang akan menyebabkan parser mengabaikan data dalam tanda kutip, daripada mencoba menafsirkannya sebagai metadata yang bermakna. Pengurai zip harus mengabaikan tag dari jenis yang tidak dikenal, jadi kami dapat memilih tag secara acak, tetapi ada risiko bahwa di masa mendatang beberapa tag akan melanggar kompatibilitas desain.

Diagram sebelumnya menggambarkan kemungkinan menggunakan bidang tambahan di bzip2, c dan tanpa Zip64. Pada kedua grafik ada titik balik, ketika pertumbuhan berubah dari kuadrat ke linier. Tanpa Zip64, ini terjadi di mana ukuran maksimum file yang tidak dikompresi tercapai (2 ³²⁾−2 byte); maka Anda hanya dapat menambah jumlah file, tetapi bukan ukurannya. Grafik benar-benar berakhir ketika jumlah file mencapai 1809, maka kami kehabisan ruang di bidang tambahan untuk mengutip header tambahan. Dengan Zip64, fraktur terjadi pada 1171 file, setelah itu hanya ukuran file yang dapat ditingkatkan, tetapi bukan jumlah mereka. Bidang tambahan membantu dalam kasus DEFLATE, tetapi perbedaannya sangat kecil sehingga tidak terlihat secara visual. Ini meningkatkan rasio kompresi zbsm.zip sebesar 1,2%; zblg.zip sebesar 0,019%; dan zbxl.zip sebesar 0,0025%.

Diskusi

Dalam pekerjaan mereka tentang hal ini, Pletz dan rekannya menggunakan file tumpang tindih untuk membuat arsip zip hampir mereplikasi diri. File tumpang tindih itu sendiri disarankan sebelumnya (slide 47) oleh Ginvael Coldwind.

Kami mengembangkan desain bom ritsleting dengan kutipan tumpang tindih dengan mempertimbangkan kompatibilitas akun - sejumlah perbedaan dalam implementasi, beberapa di antaranya ditunjukkan pada tabel di bawah ini. Desain yang dihasilkan kompatibel dengan parser zip yang bekerja dengan cara biasa, yaitu, pertama memeriksa direktori pusat dan menggunakannya sebagai indeks file. Diantaranya, parser zip unik dari Nailyang secara otomatis dihasilkan dari tata bahasa formal. Namun, desain tidak kompatibel dengan parser "streaming", yang menganalisis file zip dari awal hingga selesai dalam satu pass tanpa terlebih dahulu membaca direktori pusat. Secara alami, streaming parser tidak memungkinkan file tumpang tindih dengan cara apa pun. Kemungkinan besar, mereka hanya akan mengekstrak file pertama. Selain itu, mereka bahkan dapat melempar kesalahan, seperti halnya dengan sunzip , yang mem-parsing direktori pusat di akhir dan memeriksa konsistensi dengan header file lokal yang sudah dilihatnya.

Jika Anda ingin file yang diekstraksi dimulai dengan awalan spesifik yang berbeda dari byte header dari file lokal, Anda bisa menyisipkan blok DEFLATE sebelum blok terkompresi yang dikutip oleh header berikut. Tidak semua file dalam arsip zip harus berpartisipasi dalam pembuatan bom: Anda dapat menyertakan file biasa dalam arsip, jika perlu, agar sesuai dengan beberapa format khusus (ada parameter dalam kode sumber --templateuntuk kasus penggunaan ini). Banyak format menggunakan zip sebagai wadah, seperti dokumen Java JAR, Android APK, dan LibreOffice.

Pdfdalam banyak hal mirip dengan zip. Ini memiliki tabel referensi silang di akhir file yang menunjuk ke objek sebelumnya, dan mendukung kompresi objek melalui filter FlateDecode. Saya belum mencoba, tetapi Anda dapat menggunakan gagasan mengutip dengan tumpang tindih untuk membuat bom PDF. Mungkin Anda bahkan tidak perlu bekerja keras di sini: binaryhax0r menulis dalam posting blog bahwa Anda cukup menentukan beberapa layer FlateDecode pada satu objek, setelah itu membuat bom PDF menjadi sepele.

Mendefinisikan kelas tertentu dari bom ritsleting yang dijelaskan dalam artikel ini mudah: cukup temukan file yang tumpang tindih. Mark Adler menulis tambalanuntuk Unzip Info-ZIP, yang melakukan hal itu. Namun, secara umum, memblokir file yang tumpang tindih tidak melindungi terhadap semua kelas bom ritsleting. Sulit untuk memperkirakan sebelumnya apakah file tersebut adalah bom ritsleting atau tidak jika Anda tidak memiliki pengetahuan yang akurat tentang komponen internal parser yang akan digunakan untuk menganalisisnya. Melihat header dan menjumlahkan bidang "ukuran tidak terkompresi" semua file tidak berfungsi , karena nilai di header mungkin tidak cocok dengan ukuran terkompresi yang sebenarnya (dalam tabel kompatibilitas, lihat baris "memungkinkan file terlalu kecil"). Perlindungan yang andal terhadap bom ritsleting mencakup batasan waktu, memori, dan ruang disk di parser zip selama operasinya. Ambil parsing file zip, seperti operasi kompleks dengan data yang tidak tepercaya, dengan hati-hati.


zip-, , zip-. DEFLATE Zip64, , CRC 32- 16- .

Ucapan Terima Kasih

Terima kasih kepada Mark Adler , Russ Cox , Brandon Enright , Marek Maykovsky , Josh Wolfe dan pengulas USENIX WOOT 2019 untuk komentar pada draft artikel ini. Kaolan McNamara menilai dampak bom ritsleting pada keamanan LibreOffice.

Versi artikel ini telah disiapkan untuk Lokakarya USENIX WOOT 2019 . Kode sumber tersedia. Artefak untuk presentasi di bengkel berada di file zipbomb-woot19.zip .

Apakah Anda menemukan sistem yang menjatuhkan salah satu bom? Apakah bom membantu Anda menemukan bug atau menghasilkan uang dalam program pencarian bug? Beri tahu saya, saya akan coba sebutkan di sini.

LibreOffice 6.1.5.2

Setelah mengganti nama zblg.zip ke zblg.odt atau zblg.docx, LibreOffice membuat dan menghapus serangkaian file sementara sekitar 4 GB, mencoba menentukan format file. Pada akhirnya, dia selesai melakukan ini dan menghapus file-file sementara ketika mereka tiba, jadi bom ritsleting hanya menyebabkan DoS sementara tanpa mengisi disk. Kaolan McNamara menjawab pesan kesalahan saya.

Addons-server Mozilla 2019.06.06

Saya mencoba bom ritsleting terhadap instalasi addons-server lokal, yang merupakan bagian dari perangkat lunak addons.mozilla.org. Sistem ini dengan anggun menangani bom, memaksakan batas waktu 110 detik pada ekstraksi file. Bom zip mengembang dengan cepat, sejauh disk memungkinkan hingga batas waktu ini, tetapi kemudian prosesnya terbunuh dan file yang dibongkar akhirnya secara otomatis dihapus.

UnZip 6.0

Mark Adler menulis tambalan untuk UnZip untuk mendeteksi kelas bom ritsleting ini.

5 Juli 2019: Saya perhatikan bahwa CVE-2019-13232 ditugaskan ke UnZip. Secara pribadi, saya berpendapat bahwa kemampuan / ketidakmampuan UnZip (atau parser zip apa pun) untuk memproses bom ritsleting semacam ini tentu merupakan kerentanan atau bahkan bug. Ini adalah implementasi alami yang tidak melanggar spesifikasi, apa yang bisa saya katakan. Jenis bom dalam artikel ini hanya satu jenis, dan ada banyak cara lain untuk memecahkan parser zip. Seperti disebutkan di atas, jika Anda ingin melindungi diri dari serangan sumber daya yang habis, Anda tidak boleh mencoba membuat daftar, mendeteksi, dan memblokir setiap serangan yang diketahui; melainkan, perlu untuk menetapkan pembatasan eksternal pada waktu dan sumber daya lainnya sehingga parser tidak masuk ke dalam situasi seperti itu, terlepas dari jenis serangan apa yang ditemui. Tidak ada yang salah dengan mencoba mendeteksi dan menolak desain tertentu sebagai optimasi dari pass pertama,tapi kamu tidak bisa berhenti di situ. Kecuali jika Anda akhirnya mengisolasi dan membatasi operasi dengan data yang tidak terpercaya, sistem Anda mungkin masih rentan. Pertimbangkan analogi dengan skrip lintas situs dalam HTML: perlindungan yang tepat bukanlah mencoba memfilter byte tertentu yang dapat ditafsirkan sebagai kode, tetapi untuk menghindari semuanya dengan benar.

Mesin antivirus

Pengguna Twitter @TVqQAAMAAAAEAAA melaporkan : "McAfee antivirus di mesin pengujian saya baru saja meledak." Saya belum mengujinya sendiri dan saya tidak memiliki detail seperti nomor versi.

Tavis Ormandi menunjukkan bahwa VirusTotal memiliki sejumlah batas waktu untuk zblg.zip ( tangkapan layar dari 6 Juni 2019 ): AhnLab-V3, ClamAV, DrWeb, Endgame, F-Secure, GData, K7AntiVirus, K7GW, MaxSecure, McAfee, McAfee-GW -Edisi, Panda, Qihoo-360, Sophos ML, VBA32. Hasil untuk zbsm.zip ( tangkapan layar dari 6 Juni 2019)) serupa, tetapi dengan rangkaian mesin batas waktu yang berbeda: Baido, Bkav, ClamAV, CMC, DrWeb, Endgame, ESET-NOD32, F-Secure, GData, Kingsoft, Edisi McAfee-GW, NANO-Antivirus, Acronis. Menariknya, tidak ada batas waktu dalam hasil zbxl.zip ( tangkapan layar dari 6 Juni 2019 ). Mungkin beberapa antivirus tidak mendukung Zip64? Beberapa mesin mendeteksi file sebagai semacam "bom kompresi". Sangat menarik untuk melihat apakah mereka akan terus melakukannya dengan perubahan kecil, seperti mengubah nama file atau menambahkan awalan ASCII untuk setiap file.

Pernyataan terakhir

Saatnya untuk mengakhiri Facebook. Ini bukan pekerjaan netral untuk Anda: setiap hari ketika Anda datang bekerja, Anda melakukan sesuatu yang salah. Jika Anda memiliki akun Facebook, hapus itu. Jika Anda bekerja di Facebook, PHK.

Dan jangan lupa bahwa Badan Keamanan Nasional harus dihancurkan.