Comment fabriquer une bombe Zip?


131

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?


5
@Michael votre plainte n'est pas valide. Non seulement OP a demandé comment cela fonctionne, mais rien dans l'article publié ne dit que c'est dans le but exprès de désactiver l'antivirus. Bien au contraire, il semble que l'idée maîtresse de l'article soit une attaque de type DOS avec seulement une mention passagère de la désactivation de l'antivirus.
San Jacinto

2
Le fait est que l'OP faisait référence à un fichier spécifique, qui se compose d'archives imbriquées, et non à un énorme fichier compressé.
Michael Borgwardt le

1
Je pense que Michael a raison, il explique comment créer le fichier décrit dans le "PS", et tout le monde ne le fait pas. Cependant, le «PS» a été ajouté en tant que modification, de sorte que ces réponses n'ont peut-être pas été manifestement erronées au moment où elles ont été données. Ils pensaient simplement que "un tel fichier" signifiait "tout fichier qui se décompresse à 1,3 exaoctet", alors qu'il s'est avéré qu'il était destiné à signifier "un fichier structuré comme celui décrit dans l'article auquel je renvoie".
Steve Jessop du

1
@onebyone Je suis entièrement d'accord. Je ne pense tout simplement pas qu'un vote défavorable soit approprié dans de telles circonstances.
San Jacinto

4
Je suppose que cela dépend si vous considérez qu'un vote défavorable signifie "ce n'est pas la meilleure réponse à la question", ou "vous êtes un imbécile et pas digne de vivre", ou où vous vous trouvez entre les deux. Personnellement, je prends un vote défavorable pour signifier que je devrais relire ma réponse et voir s'il y a quelque chose de manifestement mal à ce sujet que je devrais corriger. Mais alors, je suis assez heureux maintenant d'être en désaccord et de ne pas changer ma réponse, si je pense que ma réponse apporte quelque chose. Et je suis devenu assez peu préoccupé par l'ensemble du processus de vote de toute façon, maintenant qu'il est clair que je n'attraperai jamais Jon Skeet ;-)
Steve Jessop

Réponses:


92

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.


2
Impossible ... une fois que vous avez compressé le fichier de zéros en bas, le fichier compressé résultant ne sera pas aussi compressible pour la couche suivante.
pufferfish

16
Ah, mais à chaque niveau, vous avez dix fichiers identiques - qui se compresse encore une fois bien. Bien que ZIP n'exploite pas la redondance entre fichiers, une archive contenant dix fichiers identiques compressés individuellement a probablement beaucoup de redondance pour la couche suivante à exploiter.
Michael Borgwardt

10
Le but n'est PAS de savoir comment générer le maximum de données à partir du fichier le plus petit possible - le but est de faire échouer les tentatives des antivirus pour se prémunir contre les archives trop volumineuses.
Michael Borgwardt

2
Ce n'est pas l'idée maîtresse de l'article sur wikipedia. Il semble pousser une attaque de style DOS.
San Jacinto du

2
Mais les fichiers ne sont pas extraits de manière récursive ... la victime doit continuer à extraire les fichiers sub zip pour que cela fonctionne ... Toute solution pour cela.
Manoj le

46

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

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


22
Vous avez oublié le sarcasme "smiley".
tvanfosson le

1
Cela serait probablement impossible avec la plupart des systèmes de fichiers et des algorithmes de compression en raison des limites de taille de fichier. Cependant, imbriquer des fichiers dans l'archive compressée (et placer davantage d'archives imbriquées dans l'archive, si l'algorithme de compression a une limite de taille totale) vous permet de contourner ces limites.
Blixt

133
devrait créer un fichier de 1,3 exaoctet de 1. Ils sont beaucoup plus maigres que les 0 :)
Quinn Wilson

33
@quinn - c'est pourquoi la compression des zéros (initialement plus gros) est beaucoup plus efficace
wefwfwefwe

1
Cela vous donne un fichier zip> 1 Go sauf si je me trompe
Chris S

36

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.


8
Mais vous avez besoin de la puissance de calcul pour compresser les données non compressées, c'est toujours O (n) dans la taille des données non compressées .
tonfa le

2
Oui, comme toutes les autres réponses ici.
Thomi

6
La réponse de Michael Borgwardt est O (log N) dans la taille des données non compressées.
Steve Jessop du

1
À peu près, en tout cas. Chaque répétition du processus "supprimer les en-têtes de l'archive, dupliquer l'entrée du fichier compressé 10 fois, remplacer les en-têtes de l'archive, compresser" augmente le niveau d'imbrication du zip de 1, prend un temps proportionnel à la taille des données compressées de l'étape précédente , multiplie la taille des données non compressées par 10, et si cela augmente la taille des données compressées du tout, ne le fait certainement pas par quelque chose comme un facteur linéaire.
Steve Jessop du

3
Donc, juste à titre de test, je zip -9 1,3 Go de zéros. Le résultat est un fichier de 1,3 Mo. Je l'ai dupliqué 10 fois (je ne pouvais pas être dérangé de jouer avec les en-têtes zip, donc le résultat ne fonctionnera pas comme une bombe zip, mais illustre le principe) pour donner un fichier 13M, qui se compresse avec zip -9 à 34381 octets. Ainsi, l'étape de duplication rend le fichier plus petit, car deflate ne prend en charge que les jetons d'une certaine taille maximale. La prochaine étape donne 18453, puis 19012, 19312, 19743, 20120, 20531, 20870.
Steve Jessop

10

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.


27
J'ai juste supposé qu'il s'agissait de femmes nues faisant des recherches sur la sécurité.
James McMahon

3
Le zip était nsfw. Une grosse alarme panique rouge se déclenchera et une cage tombera du plafond autour de votre bureau
Chris S

4
Si chaque coup sur un fichier de virus aboutit à un entretien avec les RH, alors soit vous n'avez pas besoin du scanner de virus, soit vous n'avez pas besoin de votre service RH. L'un d'eux ne contribue pas à l'entreprise ;-)
Steve Jessop

2
Peut également être NSFW car un scanner de virus de réseau peut vouloir le vérifier - et l'extraire pour le faire.
Michael Stum

5
L'analyseur de virus doit simplement le marquer comme suspect (ce qui peut entraîner son blocage en toute sécurité ou vous signaler de manière non sécurisée pour avoir tenté d'installer des virus). Si la bombe explose, c'est que votre service informatique a appris quelque chose de précieux: il a besoin d'un meilleur antivirus.
Steve Jessop

8

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.


1
Cela pourrait être compressé encore plus, vraiment: 0x1 (0x35) (c'est-à-dire que le deuxième 0 est répété 35 fois pour qu'il s'étende à votre commentaire)
Michael

5

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.


5

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.


4

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 :)


2

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 ...


Évalué pour ne pas tenir compte de la question réelle, qui mentionne un fichier spécifique qui n'est explicitement pas le résultat de la compression d'un gros flux de zéros.
Michael Borgwardt

Non, vous serez toujours limité par la puissance de calcul. Idéalement, vous ne voulez pas exécuter gzip / zip car il utilisera beaucoup de CPU (ou au moins O (n) n étant la taille du fichier décompressé)
tonfa

@tonfa: Bien sûr, vous serez limité par la puissance de calcul. Mon raisonnement était que vous ne voudriez peut-être pas créer un gros fichier exaoctet sur votre disque, puis compresser ce fichier ...
Svish

2

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.


2

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).


2

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.


Soit dit en passant, n'ayez pas peur qu'il extrait en permanence tous les fichiers zip qu'il contient. Il extrait uniquement le fichier zip qui est imbriqué en dessous, et pas jusqu'en bas.
jaycroll

2

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 .


1

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.


2
ZIP utilise la compression Lempel-Ziv-Welch (ou une version modifiée de) qui tokenise efficacement les données. De longues séries d'`` ensembles '' d'octets entraîneront une bonne compression, d'où la raison pour laquelle GIF (qui utilise également LZW) est bon pour les graphiques et JPEG (qui utilise une compression sinusoïdale complexe) est meilleur pour les photos où les données sont beaucoup plus aléatoires ».
Lazarus
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.