Come si fa a creare una bomba Zip?

Questa domanda sulle bombe con zip mi ha portato naturalmente alla pagina di Wikipedia sull'argomento. L'articolo menziona un esempio di un file zip 45,1 kb che si decomprime a 1,3 exabyte.

Quali sono i principi / le tecniche che verrebbero utilizzati per creare un tale file in primo luogo? In realtà non voglio farlo, più interessato a una spiegazione "how-stuff-works" semplificata dei concetti coinvolti.

ps

L'articolo menziona 9 strati di file zip, quindi non è un semplice caso di zippare un mucchio di zeri. Perché 9, perché 10 file in ciascuno?

Citando dalla pagina di Wikipedia:

Un esempio di bomba Zip è il file 45.1.zip che era 45,1 kilobyte di dati compressi, contenente nove strati di file zip nidificati in set di 10, ogni archivio di livello inferiore contenente un file da 1,30 gigabyte per un totale di 1,30 exabyte di dati non compressi .

Quindi tutto ciò di cui hai bisogno è un singolo file da 1,3 GB pieno di zero, comprimilo in un file ZIP, crea 10 copie, impacchettalo in un file ZIP e ripeti questo processo 9 volte.

In questo modo, si ottiene un file che, una volta decompresso completamente, produce una quantità assurda di dati senza che sia necessario iniziare con tale quantità.

Inoltre, gli archivi nidificati rendono molto più difficile per programmi come gli scanner di virus (l'obiettivo principale di queste "bombe") essere intelligenti e rifiutarsi di decomprimere archivi "troppo grandi", perché fino all'ultimo livello la quantità totale di dati è non tanto, non "vedi" quanto sono grandi i file al livello più basso fino a quando non hai raggiunto quel livello, e ogni singolo file non è "troppo grande" - solo il numero enorme è problematico.

Creare un file exabyte 1.3 di zeri.

Fare clic con il tasto destro del mouse> Invia a cartella compressa (zippata).

Questo è facilmente eseguibile su Linux usando il seguente comando:

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

Sostituisci conteggio con il numero di KB che vuoi comprimere. L'esempio sopra crea una bomba con cerniera da 10 MiB (non molto di una bomba, ma mostra il processo).

NON è necessario spazio sul disco rigido per memorizzare tutti i dati non compressi.

Di seguito è per Windows:

Dal concetto di sicurezza Focus concept (NSFW!), È un file ZIP con 16 cartelle, ognuna con 16 cartelle, che va avanti così (42 è il nome del file zip):

\ 42 \ lib 0 \ book 0 \ capitolo 0 \ doc 0 \ 0.dll
...
\ 42 \ lib F \ book F \ capitolo F \ doc F \ 0.dll

Probabilmente mi sbaglio con questa cifra, ma produce 4 ^ 16 (4.294.967.296) directory. Poiché ogni directory ha bisogno di spazio di allocazione di N byte, finisce per essere enorme. Il file dll alla fine è 0 byte.

La decompressione della prima directory da sola \42\lib 0\book 0\chapter 0\doc 0\0.dllprovoca 4 GB di spazio di allocazione.

Risposta seria:

(Fondamentalmente) La compressione si basa sull'individuazione di schemi ripetitivi, quindi il file zip conterrebbe dati che rappresentano qualcosa di simile

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

File zip molto breve, ma enorme quando lo si espande.

Per crearne uno in un'impostazione pratica (ovvero senza creare un file exabyte 1.3 sul tuo enorme hard disk), probabilmente dovresti imparare il formato del file a livello binario e scrivere qualcosa che si traduca in come sarebbe il tuo file desiderato, post- compressione.

L'articolo menziona 9 strati di file zip, quindi non è un semplice caso di zippare un mucchio di zeri. Perché 9, perché 10 file in ciascuno?

Prima di tutto, l'articolo di Wikipedia attualmente dice 5 livelli con 16 file ciascuno. Non sono sicuro da dove provenga la discrepanza, ma non è poi così rilevante. La vera domanda è perché usare la nidificazione in primo luogo.

DEFLATE, l'unico metodo di compressione comunemente supportato per i file zip *, ha un rapporto di compressione massimo di 1032. Ciò può essere ottenuto asintoticamente per qualsiasi sequenza ripetuta di 1-3 byte. Indipendentemente da ciò che fai in un file zip, purché utilizzi solo DEFLATE, la dimensione decompressa sarà al massimo 1032 volte la dimensione del file zip originale.

Pertanto, è necessario utilizzare file zip nidificati per ottenere rapporti di compressione davvero oltraggiosi. Se hai 2 livelli di compressione, il rapporto massimo diventa 1032 ^ 2 = 1065024. Per 3, è 1099104768 e così via. Per i 5 strati utilizzati in 42.zip, il rapporto di compressione massimo teorico è 1170572956434432. Come puoi vedere, il 42.zip effettivo è lontano da quel livello. Parte di questo è il sovraccarico del formato zip, e parte di esso è che a loro non importava.

Se dovessi indovinare, direi che 42.zip è stato creato semplicemente creando un grande file vuoto e ripetutamente zippandolo e copiandolo. Non c'è alcun tentativo di spingere i limiti del formato o massimizzare la compressione o altro: hanno scelto arbitrariamente 16 copie per livello. Il punto era creare un grande carico utile senza troppi sforzi.

Nota: altri formati di compressione, come bzip2, offrono rapporti di compressione massima molto, molto, molto più grandi. Tuttavia, la maggior parte dei parser zip non li accetta.

PS È possibile creare un file zip che verrà decompresso in una copia di se stesso (un quine). Puoi anche crearne uno che decomprime su più copie di se stesso. Pertanto, se si decomprime in modo ricorsivo un file per sempre, la dimensione massima possibile è infinita. L'unica limitazione è che può aumentare al massimo di 1032 su ogni iterazione.

PPS La figura 1032 presuppone che i dati del file nella zip siano disgiunti. Una stranezza del formato di file zip è che ha una directory centrale che elenca i file nell'archivio e esegue l'offset ai dati dei file. Se si creano più voci di file che puntano agli stessi dati, è possibile ottenere rapporti di compressione molto più elevati anche senza annidamento, ma è probabile che tale file zip venga rifiutato dai parser.

Un buon modo per creare una zipbomb (o gzbomb) è conoscere il formato binario che stai prendendo di mira. Altrimenti, anche se si utilizza un file di streaming (ad esempio utilizzando/dev/zero ) sarai comunque limitato dalla potenza di calcolo necessaria per comprimere il flusso.

Un bell'esempio di bomba gzip: http://selenic.com/googolplex.gz57 (c'è un messaggio incorporato nel file dopo diversi livelli di compressione che danno luogo a file enormi)

Divertiti a trovare quel messaggio :)

Forse, su unix, potresti reindirizzare una certa quantità di zeri direttamente in un programma zip o qualcosa del genere? Non so abbastanza su Unix per spiegare come lo faresti però. A parte questo, avresti bisogno di una fonte di zeri e inseriscili in una cerniera che legge dallo stdin o qualcosa del genere ...

Tutti gli algoritmi di compressione dei file si basano sull'entropia delle informazioni da comprimere. Teoricamente puoi comprimere un flusso di 0 o 1, e se è abbastanza lungo, si comprimerà molto bene.

Questa è la parte teorica. La parte pratica è già stata sottolineata da altri.

Recenti algoritmi di compressione (post 1995) come bz2, lzma (7-zip) e rar offrono una compressione spettacolare di file monotoni e un singolo livello di compressione è sufficiente per avvolgere il contenuto di grandi dimensioni in dimensioni gestibili.

Un altro approccio potrebbe essere quello di creare un file sparse di dimensioni estreme (exabyte) e quindi comprimerlo con qualcosa di banale che comprenda i file sparsi (ad esempio tar), ora se l'esaminatore esegue il flusso del file l'esaminatore dovrà leggere oltre tutti gli zeri esistenti solo per spostarsi tra il contenuto effettivo del file, se l'esaminatore lo scrive su disco, tuttavia verrà utilizzato pochissimo spazio (presupponendo un unarchiver ben educato e un moderno filesystem).

Provato. la dimensione del file zip di output era un piccolo file da 84 KB.

Passaggi che ho fatto finora:

1. crea un file .txt da 1,4 GB pieno di '0'
2. comprimilo.
3. rinominare .zip in .txt, quindi fare 16 copie
4. compresse tutto in un file .zip,
5. rinominare nuovamente i file .txt rinominati all'interno del file .zip in .zip
6. ripetere i passaggi da 3 a 5 otto volte.
7. Godere :)

anche se non so come spiegare la parte in cui la compressione del file zip rinominato lo comprime ancora in una dimensione più piccola, ma funziona. Forse mi mancano solo i termini tecnici.

L'episodio 7 della Silicon Valley Season 3 mi ha portato qui. I passaggi per generare una bomba zip sarebbe.

1. Crea un file fittizio con zeri (o uno se pensi che siano magri) di dimensioni (ad esempio 1 GB).
2. Comprimi questo file in un file zip dire 1.zip.
3. Crea n(diciamo 10) copie di questo file e aggiungi questi 10 file a un archivio compresso (diciamo2.zip ).
4. Ripetere il passaggio 3 knumero di volte.
5. Riceverai una bomba con zip.

Per un'implementazione di Python, controlla questo .

Non so se ZIP utilizza la codifica della lunghezza di esecuzione, ma se così fosse, un file così compresso conterrebbe una piccola porzione di dati e un valore di lunghezza di esecuzione molto grande. Il valore della lunghezza di esecuzione specifica quante volte viene ripetuta la piccola porzione di dati. Quando hai un valore molto grande, i dati risultanti sono proporzionalmente grandi.