.I file ZIP sono archivi che memorizzano più file. ZIP permette ai file contenuti di essere compressi usando molti metodi diversi, così come semplicemente memorizzare un file senza comprimerlo. Ogni file è memorizzato separatamente, permettendo ai diversi file nello stesso archivio di essere compressi con metodi diversi. Poiché i file in un archivio ZIP sono compressi individualmente, è possibile estrarli, o aggiungerne di nuovi, senza applicare la compressione o decompressione all’intero archivio. Questo contrasta con il formato dei file tar compressi, per i quali tale elaborazione ad accesso casuale non è facilmente possibile.
Una directory è posta alla fine di un file ZIP. Questo identifica quali file sono nello ZIP e identifica dove nello ZIP si trova quel file. Questo permette ai lettori ZIP di caricare la lista dei file senza leggere l’intero archivio ZIP. Gli archivi ZIP possono anche includere dati extra che non sono collegati all’archivio ZIP. Questo permette ad un archivio ZIP di essere trasformato in un archivio autoestraente (applicazione che decomprime i dati contenuti), aggiungendo il codice del programma ad un archivio ZIP e contrassegnando il file come eseguibile. Memorizzare il catalogo alla fine rende anche possibile nascondere un file zippato aggiungendolo a un file innocuo, come un file immagine GIF.
Il formato .ZIP utilizza un algoritmo CRC a 32 bit e include due copie della struttura di directory dell’archivio per fornire una maggiore protezione contro la perdita di dati.
StructureEdit
Un file ZIP è correttamente identificato dalla presenza di un record di fine directory centrale che si trova alla fine della struttura dell’archivio per consentire la facile aggiunta di nuovi file. Se il record di fine della directory centrale indica un archivio non vuoto, il nome di ogni file o directory all’interno dell’archivio dovrebbe essere specificato in una voce della directory centrale, insieme ad altri metadati sulla voce, e un offset nel file ZIP, che punta ai dati di ingresso effettivi. Questo permette di eseguire un elenco di file dell’archivio in modo relativamente veloce, dato che l’intero archivio non deve essere letto per vedere l’elenco dei file. Le voci all’interno del file ZIP includono anche queste informazioni, per ridondanza, in un’intestazione locale del file. Poiché i file ZIP possono essere aggiunti, solo i file specificati nella directory centrale alla fine del file sono validi. La scansione di un file ZIP per le intestazioni di file locali non è valida (tranne nel caso di archivi corrotti), poiché la directory centrale può dichiarare che alcuni file sono stati cancellati e altri file sono stati aggiornati.
Per esempio, possiamo iniziare con un file ZIP che contiene i file A, B e C. Il file B viene poi cancellato e C aggiornato. Questo può essere ottenuto semplicemente aggiungendo un nuovo file C alla fine del file ZIP originale e aggiungendo una nuova directory centrale che elenca solo il file A e il nuovo file C. Quando lo ZIP fu progettato per la prima volta, il trasferimento di file tramite floppy disk era comune, ma la scrittura sui dischi richiedeva molto tempo. Se avete un grande file zip, possibilmente su più dischi, e avete bisogno di aggiornare solo alcuni file, piuttosto che leggere e riscrivere tutti i file, sarebbe sostanzialmente più veloce leggere la vecchia directory centrale, aggiungere i nuovi file e poi aggiungere una directory centrale aggiornata.
L’ordine delle voci dei file nella directory centrale non deve necessariamente coincidere con l’ordine delle voci dei file nell’archivio.
Ogni voce memorizzata in un archivio ZIP è introdotta da un’intestazione di file locale con informazioni sul file come il commento, la dimensione e il nome del file, seguita da campi di dati “extra” opzionali, e poi i dati del file possibilmente compressi, possibilmente criptati. I campi di dati “extra” sono la chiave per l’estensibilità del formato ZIP. I campi “extra” sono sfruttati per supportare il formato ZIP64, la crittografia AES compatibile con WinZip, gli attributi dei file e i timestamp dei file NTFS o Unix ad alta risoluzione. Altre estensioni sono possibili tramite il campo “Extra”. Gli strumenti ZIP sono tenuti dalle specifiche a ignorare i campi Extra che non riconoscono.
Il formato ZIP usa specifiche “firme” a 4 byte per indicare le varie strutture del file. Ogni voce del file è contrassegnata da una firma specifica. La fine del record della directory centrale è indicata con la sua firma specifica, e ogni voce nella directory centrale inizia con la firma a 4 byte dell’intestazione del file centrale.
Non c’è un marcatore BOF o EOF nella specifica ZIP. Convenzionalmente la prima cosa in un file ZIP è una voce ZIP, che può essere facilmente identificata dalla sua firma di intestazione di file locale. Tuttavia, questo non è necessariamente il caso, poiché ciò non è richiesto dalla specifica ZIP – in particolare, un archivio autoestraente inizierà con un’intestazione di file eseguibile.
Gli strumenti che leggono correttamente gli archivi ZIP devono eseguire la scansione per la firma del record di fine directory centrale, e poi, come appropriato, gli altri record di directory centrale indicati. Non devono eseguire la scansione delle voci dall’inizio del file ZIP, perché (come già detto in questa sezione) solo la directory centrale specifica dove inizia un chunk di file e che non è stato cancellato. La scansione potrebbe portare a falsi positivi, poiché il formato non proibisce che ci siano altri dati tra i chunk, né che i flussi di dati del file contengano tali firme. Tuttavia, gli strumenti che tentano di recuperare i dati da archivi ZIP danneggiati molto probabilmente scansioneranno l’archivio per le firme di intestazione dei file locali; questo è reso più difficile dal fatto che la dimensione compressa di un chunk di file può essere memorizzata dopo il chunk del file, rendendo difficile l’elaborazione sequenziale.
La maggior parte delle firme termina con il numero intero breve 0x4b50, che è memorizzato in ordine little-endian. Visto come una stringa ASCII si legge “PK”, le iniziali dell’inventore Phil Katz. Così, quando un file ZIP viene visto in un editor di testo i primi due byte del file sono di solito “PK”. (Gli ZIP autoestraenti di DOS, OS/2 e Windows hanno un EXE prima dello ZIP quindi iniziano con “MZ”; gli ZIP autoestraenti per altri sistemi operativi possono analogamente essere preceduti da codice eseguibile per estrarre il contenuto dell’archivio su quella piattaforma. Originariamente inteso per l’archiviazione di grandi file ZIP su più dischi floppy, questa caratteristica è ora usata per inviare archivi ZIP in parti via e-mail, o su altri trasporti o supporti rimovibili.
Il filesystem FAT del DOS ha una risoluzione di timestamp di soli due secondi; i record di file ZIP imitano questo. Di conseguenza, la risoluzione timestamp incorporata dei file in un archivio ZIP è di soli due secondi, anche se si possono usare campi extra per memorizzare timestamp più precisi. Il formato ZIP non ha alcuna nozione di fuso orario, quindi i timestamp sono significativi solo se si sa in quale fuso orario sono stati creati.
Nel settembre 2007, PKWARE ha rilasciato una revisione delle specifiche ZIP che fornisce la memorizzazione dei nomi dei file usando UTF-8, aggiungendo finalmente la compatibilità Unicode a ZIP.
Intestazioni di fileModifica
Tutti i valori multibyte nell’intestazione sono memorizzati in ordine byte little-endian. Tutti i campi di lunghezza contano la lunghezza in byte.
Intestazione file localeModifica
| Offset | Bytes | Descrizione |
|---|---|---|
| 0 | 4 | Firma intestazione file locale = 0x04034b50 (letto come un numero little-endian) |
| 4 | 2 | Versione necessaria per l’estrazione (minimo) |
| 6 | 2 | Bandiera bit per scopi generali |
| 8 | 2 | Metodo di compressione |
| 10 | 2 | File ultimo tempo di modifica |
| 12 | 2 | File ultima data di modifica |
| 14 | 4 | CRC-32 di dati non compressi |
| 18 | 4 | Dimensione compressa (o 0xffffffffff per ZIP64) |
| 22 | 4 | Dimensione non compressa (o 0xffffffff per ZIP64) |
| 26 | 2 | Lunghezza nome file (n) |
| 28 | 2 | Lunghezza campo extra (m) |
| 30 | n | Nome file |
| 30+n | m | Campo extra |
Il campo extra contiene una varietà di dati opzionali come gli attributi specifici del SOattributi specifici del sistema operativo. È diviso in chunks, ognuno con un codice ID a 16 bit e una lunghezza a 16 bit. Per ZIP64, almeno un chunk (con codice ID 0001 e dimensione di 32 byte) esiste sempre, vedi sotto.
Questo è immediatamente seguito dai dati compressi.
Data descriptorEdit
Se il bit all’offset 3 (0x08) del campo general-purpose flags è impostato, allora il CRC-32 e le dimensioni del file non sono note quando l’intestazione è scritta. I campi dell’intestazione locale sono riempiti con zero, e il CRC-32 e la dimensione sono aggiunti in una struttura di 12 byte (opzionalmente preceduta da una firma di 4 byte) immediatamente dopo i dati compressi:
| Offset | Bytes | Descrizione |
|---|---|---|
| 0 | 0/4 | Firma opzionale del descrittore di dati = 0x08074b50 |
| 0/4 | 4 | CRC-32 di dati non compressi |
| 4/8 | 4 | Dimensione compressa |
| 8/12 | 4 | non compressa size |
HeaderEdit
La voce della directory centrale è una forma estesa dell’header locale:
| Offset | Bytes | Descrizione |
|---|---|---|
| 0 | 4 | Central directory file header signature = 0x02014b50 |
| 4 | 2 | Versione fatta da |
| 6 | 2 | Versione necessaria per estrarre (minimo) |
| 8 | 2 | Bandiera bit per scopi generali |
| 10 | 2 | Metodo di compressione |
| 12 | 2 | File ultimo tempo di modifica |
| 14 | 2 | File ultima data di modifica |
| 16 | 4 | CRC-32 di dati non compressi |
| 20 | 4 | Dimensione compressa (o 0xffffffff per ZIP64) |
| 24 | 4 | Dimensione non compressa (o 0xffffffff per ZIP64) |
| 28 | 2 | Lunghezza nome file (n) |
| 30 | 2 | Lunghezza campo extra (m) |
| 32 | 2 | Lunghezza commento file (k) |
| 34 | 2 | Numero disco dove inizia il file |
| 36 | 2 | Attributi interni del file |
| 38 | 4 | Attributi esterni del file |
| 42 | 4 | Intervallo relativo dell’intestazione locale del file. Questo è il numero di byte tra l’inizio del primo disco in cui si trova il file e l’inizio dell’intestazione del file locale. Questo permette al software che legge la directory centrale di localizzare la posizione del file all’interno del file ZIP. |
| 46 | n | Nome del file |
| 46+n | m | Campo extra |
| 46+n+m | k | Commento del file |
Fine del record della directory centrale (EOCD)Edit
Dopo tutte le voci della directory centrale viene il record della fine della directory centrale (EOCD), che segna la fine del file ZIP:
| Offset | Bytes | Descrizione |
|---|---|---|
| 0 | 4 | Fine di firma della directory centrale = 0x06054b50 |
| 4 | 2 | Numero di questo disco |
| 6 | 2 | Disco dove la directory centrale inizia |
| 8 | 2 | Numero di record della directory centrale su questo disco |
| 10 | 2 | Numero totale di record della directory centrale |
| 12 | 4 | Dimensione della directory centrale (byte) |
| 16 | 4 | Offset di inizio della directory centrale, relativo all’inizio dell’archivio |
| 20 | 2 | Lunghezza del commento (n) |
| 22 | n | Commento |
Questo ordinamento permette di creare un file ZIP in un solo passaggio, ma la directory centrale è anche posta alla fine del file per facilitare la rimozione dei file da più parti (ad es.
Metodi di compressioneModifica
La specifica del formato file .ZIP documenta i seguenti metodi di compressione: Store (nessuna compressione), Shrink (LZW), Reduce (livelli 1-4; LZ77 + probabilistico), Implode, Deflate, Deflate64, bzip2, LZMA, WavPack, PPMd, e una variante LZ77 fornita dall’istruzione IBM z/OS CMPSC. Il metodo di compressione più comunemente usato è DEFLATE, che è descritto in IETF RFC 1951.
Altri metodi menzionati, ma non documentati in dettaglio nella specifica includono: PKWARE DCL Implode (vecchio IBM TERSE), nuovo IBM TERSE, IBM LZ77 z Architecture (PFS), e una variante JPEG. Un metodo “Tokenize” era riservato a una terza parte, ma il supporto non fu mai aggiunto.
La parola Implode è abusata da PKWARE: il DCL/TERSE Implode è distinto dal vecchio PKZIP Implode, un predecessore di Deflate. L’Implode DCL non è documentato, in parte a causa della sua natura proprietaria detenuta da IBM, ma Mark Adler ha comunque fornito un decompressore chiamato “blast” insieme a zlib.
EncryptionEdit
ZIP supporta un semplice sistema di crittografia simmetrica basato su password generalmente noto come ZipCrypto. È documentato nella specifica ZIP ed è noto per essere seriamente difettoso. In particolare, è vulnerabile agli attacchi known-plaintext, che in alcuni casi sono peggiorati da implementazioni scadenti dei generatori di numeri casuali.
Nuove caratteristiche, inclusi nuovi metodi di compressione e crittografia (ad esempio AES) sono stati documentati nella specifica ZIP File Format dalla versione 5.2. Uno standard aperto basato su AES sviluppato da WinZip (“AE-x” in APPNOTE) è usato anche da 7-Zip e Xceed, ma alcuni fornitori usano altri formati. PKWARE SecureZIP (SES, proprietario) supporta anche i metodi di crittografia RC2, RC4, DES, Triple DES, la crittografia e l’autenticazione basate su certificati digitali (X.509), e la crittografia dell’intestazione degli archivi. Tuttavia, è brevettato (vedi § Controversia sulla crittografia forte).
La crittografia dei nomi dei file è introdotta nella specifica 6.2 del formato file .ZIP, che crittografa i metadati memorizzati nella porzione Central Directory di un archivio, ma le sezioni Local Header rimangono non crittografate. Un archiviatore conforme può falsificare i dati dell’intestazione locale quando usa la crittografia di Central Directory. A partire dalla versione 6.2 delle specifiche, i campi Compression Method e Compressed Size all’interno della Local Header non sono ancora mascherati.
ZIP64Edit
Il formato .ZIP originale aveva un limite di 4 GiB (232 byte) su varie cose (dimensione non compressa di un file, dimensione compressa di un file, e dimensione totale dell’archivio), così come un limite di 65.535 (216) voci in un archivio ZIP. Nella versione 4.5 della specifica (che non è la stessa della v4.5 di qualsiasi strumento particolare), PKWARE ha introdotto le estensioni del formato “ZIP64” per aggirare queste limitazioni, aumentando i limiti a 16 EiB (264 byte). In sostanza, utilizza una voce di directory centrale “normale” per un file, seguita da una voce di directory “zip64” opzionale, che ha i campi più grandi.
Il formato dell’intestazione del file locale e della voce della directory centrale sono gli stessi in ZIP e ZIP64, ma per le dimensioni sempre 0xffffff memorizzate, e un campo extra esiste sempre:
| Offset | Bytes | Description | |
|---|---|---|---|
| 0 | 2 | Header ID 0x0001 | |
| 2 | 2 | Dimensione del campo extra chunk (16, 24 o 28) | |
| 4 | 8 | Dimensione originale del file non compresso | |
| 12 | 8 | 8 | Dimensione dei dati compressi |
| 20 | 8 | Offset del record di intestazione locale | |
| 28 | 4 | Numero del disco su cui inizia questo file |
D’altra parte, il formato di EOCD per ZIP64 è leggermente diverso dalla versione ZIP normale (vedi nota 4.3.14).
| Offset | Bytes | Descrizione |
|---|---|---|
| 0 | 4 | Fine della firma della directory centrale = 0x06064b50 |
| 4 | 8 | Dimensione della EOCD64 – 8 |
| 12 | 2 | Versione fatta da |
| 14 | 2 | Versione necessaria per estrarre (minimo) |
| 16 | 4 | Numero di questo disco |
| 20 | 4 | Disco dove inizia la directory centrale |
| 24 | 8 | Numero di record della directory centrale su questo disco |
| 32 | 8 | Numero totale di record della directory centrale |
| 40 | 8 | Dimensione della directory centrale (byte) |
| 48 | 8 | Offset di inizio della directory centrale, relativo all’inizio dell’archivio |
| 56 | n | Commento (fino alla dimensione di EOCD64) |
Non è anche necessariamente l’ultimo record nel file, potrebbe seguire un localizzatore opzionale di fine della directory centrale (un ulteriore 20 byte alla fine).
L’esploratore di file in Windows XP non supporta ZIP64, ma l’esploratore in Windows Vista e successivi sì. Allo stesso modo, alcune librerie di estensione supportano ZIP64, come DotNetZip, QuaZIP e IO::Compress::Zip in Perl. Lo zipfile incorporato di Python lo supporta dalla 2.5 e per default dalla 3.4. Il built-in java.util.zip di OpenJDK supporta ZIP64 dalla versione Java 7. Android Java API supporta ZIP64 da Android 6.0. Mac OS Sierra’s Archive Utility in particolare non supporta ZIP64, e può creare archivi corrotti quando sarebbe richiesto ZIP64. Tuttavia, il comando ditto fornito con Mac OS decomprimerà i file ZIP64. Versioni più recenti di Mac OS dispongono degli strumenti a linea di comando zip e unzip di info-zip che supportano Zip64: per verificare esegui zip -v e cerca “ZIP64_SUPPORT”.
Combinazione con altri formati di fileModifica
Il formato di file .ZIP permette un commento contenente fino a 65.535 (216-1) bytes di dati alla fine del file dopo la directory centrale. Inoltre, poiché la directory centrale specifica l’offset di ogni file nell’archivio rispetto all’inizio, è possibile che la prima voce del file inizi con un offset diverso da zero, anche se alcuni strumenti, per esempio gzip, non elaboreranno i file di archivio che non iniziano con una voce di file all’offset zero.
Questo permette ai dati arbitrari di verificarsi nel file sia prima che dopo i dati dell’archivio ZIP, e che l’archivio sia ancora letto da un’applicazione ZIP. Un effetto collaterale di questo è che è possibile creare un file che è sia un archivio ZIP funzionante che un altro formato, a condizione che l’altro formato tolleri dati arbitrari alla fine, all’inizio o nel mezzo. Gli archivi autoestraenti (SFX), della forma supportata da WinZip, traggono vantaggio da questo, in quanto sono file eseguibili (.exe) conformi alla specifica PKZIP AppNote.txt, e possono essere letti da strumenti o librerie zip conformi.
Questa proprietà del formato .ZIP, e del formato JAR che è una variante dello ZIP, può essere sfruttata per nascondere contenuti canaglia (come classi Java dannose) dentro un file apparentemente innocuo, come un’immagine GIF caricata sul web. Questo cosiddetto exploit GIFAR è stato dimostrato come un attacco efficace contro applicazioni web come Facebook.
LimitsEdit
La dimensione minima di un file .ZIP è di 22 byte. Un tale file zip vuoto contiene solo un End of Central Directory Record (EOCD):
La dimensione massima sia per il file di archivio che per i singoli file al suo interno è 4.294.967.295 byte (232-1 byte, o 4 GiB meno 1 byte) per lo ZIP standard. Per ZIP64, la dimensione massima è 18.446.744.073.709.551.615 byte (264-1 byte, o 16 EiB meno 1 byte).
Estensioni proprietarieEdit
Campo extraEdit
.Il formato di file ZIP include una funzione di campo extra all’interno delle intestazioni di file, che può essere usata per memorizzare dati extra non definiti dalle specifiche ZIP esistenti, e che permettono agli archiviatori conformi che non riconoscono i campi di saltarli in sicurezza. Gli ID di intestazione 0-31 sono riservati all’uso di PKWARE. Gli ID rimanenti possono essere usati da fornitori terzi per uso proprietario.
Polemica sulla crittografia forteModifica
Quando WinZip 9.0 beta pubblica fu rilasciato nel 2003, WinZip introdusse la propria crittografia AES-256, usando un diverso formato di file, insieme alla documentazione per la nuova specifica. Gli stessi standard di crittografia non erano proprietari, ma PKWARE non aveva aggiornato APPNOTE.TXT per includere la Strong Encryption Specification (SES) dal 2001, che era stata usata dalle versioni 5.0 e 6.0 di PKZIP. Il consulente tecnico di WinZip Kevin Kearney e il product manager di StuffIt Mathew Covington accusarono PKWARE di aver trattenuto il SES, ma il chief technology officer di PKZIP Jim Peterson sostenne che la crittografia basata sul certificato era ancora incompleta.
In un’altra mossa controversa, il 16 luglio 2003 PKWare fece domanda per un brevetto che descriveva un metodo per combinare ZIP e crittografia forte per creare un file sicuro.
Alla fine, PKWARE e WinZip concordarono di supportare i prodotti dell’altra. Il 21 gennaio 2004, PKWARE ha annunciato il supporto del formato di compressione AES basato su WinZip. In una versione successiva di WinZip beta, fu in grado di supportare i file ZIP basati su SES. PKWARE alla fine rilasciò al pubblico la versione 5.2 della .ZIP File Format Specification, che documentava SES. Il progetto di software libero 7-Zip supporta anche AES, ma non SES nei file ZIP (come fa la sua porta POSIX p7zip).
Quando si usa la crittografia AES sotto WinZip, il metodo di compressione è sempre impostato su 99, con il metodo di compressione effettivo memorizzato in un campo dati extra AES. Al contrario, Strong Encryption Specification memorizza il metodo di compressione nel segmento di intestazione del file di base di Local Header e Central Directory, a meno che Central Directory Encryption non sia usato per mascherare/crittografare i metadati.
.