42.zip es un archivo zip de 42.374 bytes, contiene 16 archivos zips que a su vez contienen otros 16 zips y así hasta 6 veces. Los 16 últimos zips contienen un archivo de 4,3 Gb cada uno. Si descomprimimos el archivo 42.zip de 42.374 bytes obtendriamos 4.5 Pb de datos descomprimidos.
16 x 4294967295 = 68.719.476.720 (68GB)
16 x 68719476720 = 1.099.511.627.520 (1TB)
16 x 1099511627520 = 17.592.186.040.320 (17TB)
16 x 17592186040320 = 281.474.976.645.120 (281TB)
16 x 281474976645120 = 4.503.599.626.321.920 (4,5PB)
Este tipo de archivos se denominan Zips de la muerte o Zips bomba y suelen usarse como herramienta para ataques DoS.
Fuentes:
http://blogofsysadmins.com/el-archivo-zi...rte-42-zip
http://www.dipler.org/2011/04/zip-de-la-...s-en-42kb/
.... un poco viejo el tema pero recién me entero.
Es posta o es un fake? No me cierra mucho la explicación... me cerraría más si lo pensara un poco desde lo que vimos en Operativos (si lo pensara... a esta hora paso)
Tiene sentido q se los use en ataques DoS xq justamente lo q buscan es sobrecargar el servidor que expone el servicio para voltearlo. Ahora, si existe o no, la verdad me mataste. Nunca lo vi.
puede ser verdad, depende cuanta información se repita en esos 4 pb.
me acuerdo que el KGB Archiver, o algo así te dejaba comprimir como un hdp, después estaba 3 días consumiendo memoria para descomprimir, pero bueno.
Lo que si es verdad sobre compresion eficiente es que mejor algoritmo de compresion-descompresion looseless que se conoce esta implementado en el bz2 (creo que es el burrows-wheeler y que el bzz tambien lo usa). El tema es que el programa le hacía 9 pases de compresión al archivo, una bestialidad.
EDIT: Es cierto lo que dijeron arriba (yo lo estaba viendo como comprimir un archivo ya existente y no generado a mano).
Teoricamente es posible...pero tendría que repetir una bestialidad de informacion. Billones de caracteres cosa que un algoritmo huffman-like (o lo que sea que use el zip/rar) diga "bueno, este caracter se repite 9billones de veces. Me guardo el numero de ocurrencias y el caracte y punto". En la vida real no tenés información tan repetida jamás por lo que no se puede usar como práctica general.
¡Buenas!
Pareciera que sí, che.
La joda debe venir por cómo funciona el zip. Cada zip contiene 16 archivos idénticos, por lo que al comprimirlos se guarda una sola de las 16 copias. Que a su vez genera cada una 16 copias al descomprimirlo, osea, la cosa va exponencial.
¿Cómo comprimen un archivo de 4 GB en 4MB? Fácil: son todos los bytes iguales. 4 GB de 0xAA.
Ahora, ¿con esto tirás un servidor abajo? Se me ocurre que para eso el servidor debería querer descomprimir recursivamente el archivo. Eso me suena raro. Entiendo que existe la compresión gzip, y que el servidor intente descomprimir el stream que recibe, pero no entiendo por qué lo haría recursivamente. En el caso de Google Drive tal vez funcione, que el chabón te quiere mostrar los .zip como archivos individuales y blah. Pero habría que probarlo (con otro zip que no tenga password).
Si alguien lo hace, me cuentan.
Acá la sesión de descompresión en mi máquina:
http://pastebin.com/yu4jWBHe
--------------
EDIT: comprimiendo el archivo de 4GB con 7z, termina pesando 606KB en lugar de 4.2MB. Habría que ver si al comprimir de a grupos sigue mejorando la cosa. Puede que no (que el "costo fijo" sea mayor a 42kb para los archivos 7z), o puede que sí pero los tipos hayan elegido el .zip por "universalidad". Si alguien tiene un script para armar toda esta estructura usando 7z, me chiflan y pruebo.
Salutes!