Comment fabriquer une bombe Zip?

Cette question sur les bombes zip m'a naturellement conduit à la page Wikipédia sur le sujet. L'article mentionne un exemple de fichier zip de 45,1 ko qui se décompresse à 1,3 exaoctet.

Quels sont les principes / techniques qui seraient utilisés pour créer un tel fichier en premier lieu? Je ne veux pas vraiment faire cela, plus intéressé par une explication simplifiée «comment ça marche» des concepts impliqués.

ps

L'article mentionne 9 couches de fichiers zip, il ne s'agit donc pas simplement de compresser un tas de zéros. Pourquoi 9, pourquoi 10 fichiers dans chacun?

Citant de la page Wikipédia:

Un exemple de bombe Zip est le fichier 45.1.zip qui était de 45,1 kilo-octets de données compressées, contenant neuf couches de fichiers zip imbriqués par ensembles de 10, chaque archive de couche inférieure contenant un fichier de 1,30 gigaoctet pour un total de 1,30 exaoctets de données non compressées .

Donc, tout ce dont vous avez besoin est un seul fichier de 1,3 Go rempli de zéros, compressez-le dans un fichier ZIP, faites 10 copies, mettez-les dans un fichier ZIP et répétez ce processus 9 fois.

De cette façon, vous obtenez un fichier qui, lorsqu'il est complètement décompressé, produit une quantité absurde de données sans vous obliger à commencer avec cette quantité.

De plus, les archives imbriquées font qu'il est beaucoup plus difficile pour les programmes comme les antivirus (la principale cible de ces «bombes») d'être intelligents et de refuser de décompresser des archives «trop volumineuses», car jusqu'au dernier niveau, la quantité totale de données est pas tant que ça, vous ne "voyez" pas la taille des fichiers au niveau le plus bas tant que vous n'avez pas atteint ce niveau, et chaque fichier individuel n'est pas "trop ​​grand" - seul le nombre énorme est problématique.

Créez un fichier de 1,3 exaoctet de zéros.

Faites un clic droit> Envoyer vers un dossier compressé (zippé).

Cela se fait facilement sous Linux en utilisant la commande suivante:

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

Remplacez count par le nombre de Ko que vous souhaitez compresser. L'exemple ci-dessus crée une bombe zip 10MiB (pas vraiment une bombe, mais il montre le processus).

Vous n'avez PAS besoin d'espace sur le disque dur pour stocker toutes les données non compressées.

Ci-dessous est pour Windows:

De la preuve de concept de Security Focus (NSFW!), Il s'agit d'un fichier ZIP avec 16 dossiers, chacun avec 16 dossiers, qui continue comme ça (42 est le nom du fichier zip):

\ 42 \ lib 0 \ livre 0 \ chapitre 0 \ doc 0 \ 0.dll
...
\ 42 \ lib F \ livre F \ chapitre F \ doc F \ 0.dll

Je me trompe probablement avec ce chiffre, mais il produit 4 ^ 16 (4 294 967 296) répertoires. Parce que chaque répertoire a besoin d'un espace d'allocation de N octets, il finit par être énorme. Le fichier dll à la fin est de 0 octet.

La décompression du premier répertoire à lui seul \42\lib 0\book 0\chapter 0\doc 0\0.dllgénère 4 Go d'espace d'allocation.

Réponse sérieuse:

(Très fondamentalement) La compression repose sur la détection de motifs répétitifs, de sorte que le fichier zip contiendrait des données représentant quelque chose comme

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

Fichier zip très court, mais énorme lorsque vous le développez.

Pour en créer un dans un cadre pratique (c'est-à-dire sans créer un fichier de 1,3 exaoctet sur votre énorme disque dur), vous devrez probablement apprendre le format de fichier à un niveau binaire et écrire quelque chose qui se traduit par ce à quoi ressemblerait le fichier souhaité, post- compression.

L'article mentionne 9 couches de fichiers zip, il ne s'agit donc pas simplement de compresser un tas de zéros. Pourquoi 9, pourquoi 10 fichiers dans chacun?

Tout d'abord, l'article de Wikipedia dit actuellement 5 couches avec 16 fichiers chacune. Je ne sais pas d'où vient l'écart, mais ce n'est pas si pertinent. La vraie question est de savoir pourquoi utiliser l'imbrication en premier lieu.

DEFLATE, la seule méthode de compression couramment prise en charge pour les fichiers zip *, a un taux de compression maximal de 1032. Cela peut être réalisé de manière asymptotique pour toute séquence répétitive de 1 à 3 octets. Peu importe ce que vous faites à un fichier zip, tant qu'il n'utilise que DEFLATE, la taille décompressée sera au maximum 1032 fois la taille du fichier zip d'origine.

Par conséquent, il est nécessaire d'utiliser des fichiers zip imbriqués pour obtenir des taux de compression vraiment scandaleux. Si vous avez 2 couches de compression, le rapport maximum devient 1032 ^ 2 = 1065024. Pour 3, c'est 1099104768, et ainsi de suite. Pour les 5 couches utilisées dans 42.zip, le taux de compression maximal théorique est de 1170572956434432. Comme vous pouvez le voir, le 42.zip réel est loin de ce niveau. Une partie de cela est la surcharge du format zip, et une partie de cela est qu'ils s'en moquaient.

Si je devais deviner, je dirais que 42.zip a été formé en créant simplement un gros fichier vide, et en le zippant et en le copiant à plusieurs reprises. Il n'y a aucune tentative de repousser les limites du format ou de maximiser la compression ou quoi que ce soit - ils ont simplement choisi arbitrairement 16 copies par couche. Le but était de créer une grande charge utile sans trop d'effort.

Remarque: d'autres formats de compression, tels que bzip2, offrent des taux de compression maximum beaucoup, beaucoup, beaucoup plus importants. Cependant, la plupart des analyseurs zip ne les acceptent pas.

PS Il est possible de créer un fichier zip qui se décompressera en une copie de lui-même (une quine). Vous pouvez également en créer un qui se décompresse en plusieurs copies. Par conséquent, si vous décompressez un fichier de manière récursive pour toujours, la taille maximale possible est infinie. La seule limitation est qu'il peut augmenter d'au plus 1032 à chaque itération.

PPS La figure 1032 suppose que les données de fichier dans le zip sont disjointes. Une particularité du format de fichier zip est qu'il a un répertoire central qui répertorie les fichiers dans l'archive et les décalages avec les données du fichier. Si vous créez plusieurs entrées de fichier pointant vers les mêmes données, vous pouvez obtenir des taux de compression beaucoup plus élevés même sans imbrication, mais un tel fichier zip est susceptible d'être rejeté par les analyseurs.

Une bonne façon de créer un zipbomb (ou gzbomb) est de connaître le format binaire que vous ciblez. Sinon, même si vous utilisez un fichier de streaming (par exemple en utilisant /dev/zero), vous serez toujours limité par la puissance de calcul nécessaire pour compresser le flux.

Un bel exemple de bombe gzip: http://selenic.com/googolplex.gz57 (il y a un message intégré dans le fichier après plusieurs niveaux de compression entraînant des fichiers énormes)

Amusez-vous à trouver ce message :)

Peut-être, sous Unix, pourriez-vous diriger une certaine quantité de zéros directement dans un programme zip ou quelque chose? Je ne sais pas assez sur Unix pour expliquer comment vous feriez cela. En dehors de cela, vous auriez besoin d'une source de zéros et de les diriger dans une fermeture à glissière qui lit depuis stdin ou quelque chose comme ça ...

Tous les algorithmes de compression de fichiers reposent sur l' entropie des informations à compresser. Théoriquement, vous pouvez compresser un flux de 0 ou de 1, et s'il est assez long, il se compressera très bien.

C'est la partie théorique. La partie pratique a déjà été soulignée par d'autres.

Des algorithmes de compression récents (post 1995) comme bz2, lzma (7-zip) et rar donnent une compression spectaculaire de fichiers monotones, et une seule couche de compression est suffisante pour envelopper un contenu surdimensionné à une taille gérable.

Une autre approche pourrait être de créer un fichier clairsemé de taille extrême (exaoctets), puis de le compresser avec quelque chose de banal qui comprend les fichiers clairsemés (par exemple tar), maintenant si l'examinateur diffuse le fichier, l'examinateur devra lire au-delà de tous ces zéros existants seulement pour passer entre le contenu réel du fichier, si l'examinateur l'écrit sur le disque, cependant très peu d'espace sera utilisé (en supposant un désarchiveur bien comporté et un système de fichiers moderne).

Essayé. la taille du fichier zip de sortie était un petit fichier de 84 Ko.

Étapes que j'ai faites jusqu'à présent:

1. créer un fichier .txt de 1,4 Go rempli de «0»
2. compressez-le.
3. renommez le .zip en .txt puis faites 16 copies
4. compresse le tout dans un fichier .zip,
5. renommez à nouveau les fichiers .txt renommés dans le fichier .zip en .zip
6. répétez les étapes 3 à 5 huit fois.
7. Prendre plaisir :)

bien que je ne sache pas comment expliquer la partie où la compression du fichier zip renommé le compresse toujours dans une taille plus petite, mais cela fonctionne. Peut-être que je n'ai juste pas les termes techniques.

Silicon Valley Saison 3 Episode 7 m'a amené ici. Les étapes pour générer une bombe zip seraient.

1. Créez un fichier factice avec des zéros (ou des uns si vous pensez qu'ils sont maigres) de taille (par exemple 1 Go).
2. Compressez ce fichier en un fichier zip, par exemple 1.zip.
3. Faites n(disons 10) copies de ce fichier et ajoutez ces 10 fichiers à une archive compressée (disons 2.zip).
4. Répétez l'étape 3 kplusieurs fois.
5. Vous aurez une bombe zip.

Pour une implémentation Python, vérifiez ceci .

Je ne sais pas si ZIP utilise l'encodage de longueur d'exécution, mais si c'était le cas, un tel fichier compressé contiendrait un petit morceau de données et une très grande valeur de longueur d'exécution. La valeur de la longueur d'exécution spécifierait combien de fois le petit élément de données est répété. Lorsque vous avez une valeur très élevée, les données résultantes sont proportionnellement importantes.