Comment fabrique-t-on une bombe Zip?
Cette question à propos des bombes Zip m'a naturellement conduit à la page Wikipedia sur le sujet. L'article mentionne un exemple de fichier Zip de 45,1 ko décompressé en 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 du "comment ça marche" des concepts impliqués.
p.s.
L'article mentionne 9 couches de fichiers Zip, il n'est donc pas simple de compresser des zéros. Pourquoi 9, pourquoi 10 fichiers dans chacun?
Citant de la page Wikipedia:
Un exemple de bombe Zip est le fichier 45.1.Zip qui contenait 45,1 kilo-octets de données compressées, contenant neuf couches de fichiers Zip imbriqués dans des ensembles de 10, chaque archive de couche inférieure contenant un fichier de 1,30 gigaoctet pour une total de 1,30 exaoctet de données non compressées.
Donc, tout ce dont vous avez besoin est d’un seul fichier de 1,3 Go rempli de zéros, compressez-le dans un fichier Zip, effectuez 10 copies, regroupez-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 rendent beaucoup plus difficile l’intelligence des programmes comme les antivirus (la cible principale de ces "bombes") et refusent de décompresser les 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 jusqu'à ce que vous ayez atteint ce niveau, et chaque fichier n'est pas "trop volumineux" - seul le grand nombre pose problème.
Créez un fichier de 1,3 exaoctet de zéros.
Faites un clic droit> Envoyer dans un dossier compressé.
Cela se fait facilement sous Linux en utilisant la commande suivante:
dd if=/dev/zero bs=1024 count=10000 | Zip zipbomb.Zip -
Remplacez nombre par le nombre de Ko que vous souhaitez compresser. L'exemple ci-dessus crée une bombe Zip de 10MiB (ce n'est pas vraiment une bombe, mais cela montre le processus).
Vous n'avez PAS besoin d'espace disque pour stocker toutes les données non compressées.
Ci-dessous est pour Windows:
Le preuve de concept de Security Focus (NSFW!) Est un fichier Zip contenant 16 dossiers, chacun contenant 16 dossiers.
\ 42\lib 0\book 0\chapter 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.
Décompressez le premier répertoire seul \42\lib 0\book 0\chapter 0\doc 0\0.dll résulte en 4 Go d'espace d'allocation.
Réponse sérieuse:
(Très fondamentalement) La compression repose sur la détection de motifs répétés, 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 environnement pratique (c’est-à-dire sans créer un fichier exabyte de 1,3 sur votre énorme disque dur), vous devrez probablement apprendre le format de fichier à un niveau binaire et écrire quelque chose qui se traduira par ce que votre fichier souhaité ressemblerait, compression.
L'article mentionne 9 couches de fichiers Zip, il n'est donc pas simple de compresser des zéros. Pourquoi 9, pourquoi 10 fichiers dans chacun?
Tout d'abord, l'article de Wikipedia dit actuellement 5 couches de 16 fichiers chacune. Je ne sais pas d'où vient la différence, mais ce n'est pas tout à fait pertinent. La vraie question est pourquoi utiliser nidification en premier lieu.
DEFLATE, la seule méthode de compression couramment utilisée pour les fichiers Zip *, a un taux de compression maximal de 1032. Ceci peut être obtenu de manière asymptotique pour toute séquence répétée de 1 à 3 octets. Quoi que vous fassiez avec un fichier Zip, dans la mesure où il n’utilise que DEFLATE, la taille décompressée sera au plus 1032 fois celle du fichier Zip original.
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 maximal devient 1032 ^ 2 = 1065024. Pour 3, il s'agit de 1099104768, etc. Pour les 5 couches utilisées dans 42.Zip, le taux de compression maximal théorique est 1170572956434432. Comme vous pouvez le constater, le 42.Zip actuel est loin de ce niveau. Cela tient en partie aux frais généraux du format Zip et en partie au fait qu’ils ne s’en soucient tout simplement pas.
Si je devais deviner, je dirais que 42.Zip a été créé en créant simplement un fichier volumineux, puis en le compressant à plusieurs reprises. Il n’ya aucune tentative de repousser les limites du format, d’optimiser la compression ou autre, mais de choisir arbitrairement 16 copies par couche. Le but était de créer une charge utile importante sans trop d'effort.
Remarque: d'autres formats de compression, tels que bzip2, offrent des taux de compression maximum beaucoup plus élevés. Cependant, la plupart des analyseurs syntaxiques Zip ne les acceptent pas.
P.S. Il est possible de créer un fichier Zip qui décompressera en une copie de lui-même (un fichier 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.
P.P.S. La figure 1032 suppose que les données de fichier dans le fichier Zip sont disjointes. Un inconvénient du format de fichier Zip est qu’il possède un répertoire central qui répertorie les fichiers de l’archive et les décalages par rapport aux 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.
Un bon moyen 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 transmission en continu (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 (un message est intégré au fichier après plusieurs niveaux de compression, ce qui entraîne la création de gros fichiers)
Amusez-vous à trouver ce message :)
Peut-être que, sous unix, vous pourriez insérer une certaine quantité de zéros directement dans un programme Zip ou quelque chose de ce genre? Je ne connais pas suffisamment le système d'exploitation Unix pour expliquer comment procéder. Sinon, vous aurez besoin d'une source de zéros et de les insérer dans une fermeture à glissière lue à partir de stdin ou quelque chose du genre ...
Les algorithmes de compression récents (postérieurs à 1995) tels que bz2, lzma (7-Zip) et rar permettent une compression spectaculaire des fichiers monotones, et une seule couche de compression suffit à envelopper le contenu surdimensionné à une taille raisonnable.
Une autre approche pourrait consister à créer un fichier fragmenté de taille extrême (exaoctets), puis à le compresser avec quelque chose de banal qui comprend les fichiers fragmentés (par exemple, tar). Désormais, si l’examinateur diffuse le fichier, l’examinateur devra lire au-delà des zéros existants. uniquement pour faire le pont entre le contenu réel du fichier, si l’examinateur l’écrit sur le disque, mais très peu d’espace sera utilisé (en supposant qu’un archiveur sage et un système de fichiers moderne).
Essayé. la taille du fichier Zip en sortie était un petit fichier de 84 Ko.
Les étapes que j'ai faites jusqu'à présent:
- créer un fichier .txt de 1,4 Go contenant "0"
- le compresser.
- renommez le .Zip en .txt puis faites 16 copies
- compresse le tout dans un fichier .Zip,
- renommer les fichiers .txt renommés à l'intérieur du fichier .Zip en .Zip à nouveau
- répétez les étapes 3 à 5 huit fois.
- 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 manque juste les termes techniques.
Tous les algorithmes de compression de fichiers reposent sur le entropie des informations à compresser. Théoriquement, vous pouvez compresser un flux de 0 ou de 1, et s'il est assez long, il se compresse très bien.
C'est la partie théorie. La partie pratique a déjà été signalée par d’autres.
Silicon Valley Saison 3 Episode 7 m'a amené ici. Les étapes pour générer une bombe Zip seraient.
- Créez un fichier factice avec des zéros (ou des fichiers si vous pensez qu'ils sont maigres) de taille (disons 1 Go).
- Compressez ce fichier dans un fichier Zip en disant
1.Zip. - Faites des copies
n(disons 10) de ce fichier et ajoutez ces 10 fichiers à une archive compressée (disons2.Zip). - Répétez l'étape 3
knombre de fois. - Vous obtiendrez une bombe Zip.
Pour une implémentation de Python, cochez this .
Je ne sais pas si Zip utilise le codage par longueur, mais s'il le faisait, un tel fichier compressé contiendrait un petit fichier de données et une très grande valeur de longueur. La valeur de la durée d'exécution spécifierait le nombre de répétitions du petit élément de données. Lorsque vous avez une très grande valeur, les données résultantes sont proportionnellement grandes.