Extraction et décompression ZIP

L’extraction ZIP ouvre une archive et restaure les fichiers qu’elle contient. Elle est utile lorsqu’on reçoit un paquet compressé, qu’on veut inspecter son contenu avant de tout télécharger, récupérer seulement un fichier ou vérifier noms et tailles avant de faire confiance à l’archive. Pour des fichiers ordinaires, ZIP est sans perte et le contenu extrait doit correspondre à l’original. Mais extraire ne rend pas un contenu inconnu sûr. Une archive peut contenir des noms trompeurs, des dossiers inattendus, des données énormes après extraction ou des exécutables à ne pas ouvrir sans analyse. Cet outil lit l’archive localement et permet de télécharger les fichiers choisis, pratique pour de petits contrôles. Il ne remplace pas une vérification de sécurité des archives suspectes.

La lecture d'une archive ZIP s'effectue dans l'ordre inverse de l'écriture. Le navigateur reçoit le fichier sous forme d'`ArrayBuffer` via l'API File (`file.arrayBuffer()`) et le lecteur parcourt le fichier en partant de la fin à la recherche de la signature End of Central Directory `0x06054b50` (PK\x05\x06). L'EOCD occupe au maximum 22 octets plus un commentaire optionnel de 65 535 octets au plus, ce qui borne la fenêtre de recherche. L'EOCD indique la position et la taille du répertoire central, qui contient un en-tête de fichier (`0x02014b50`) par entrée. Chaque en-tête de fichier porte les tailles compressée et décompressée, le CRC-32, la méthode de compression, le nom de fichier et la position de l'en-tête local correspondant (`0x04034b50`). Le lecteur peut alors accéder directement à n'importe quelle entrée sans parcourir les entrées précédentes — d'où la rapidité de l'extraction d'un seul fichier à partir d'une sauvegarde de plusieurs gigaoctets. La décompression dépend de l'octet de méthode : `0x00` est le stockage (aucune compression, simple memcpy), `0x08` est le DEFLATE conformément à la RFC 1951 (~99 % des archives dans la nature), `0x0C` est le BZIP2, `0x0E` est le LZMA et `0x5D` est le PPMd plus ancien. Cet outil utilise JSZip (ou fflate pour un débit plus élevé — `unzipSync` de fflate décode une archive DEFLATE typique de 10 Mo en quelques dizaines de millisecondes, plusieurs fois plus vite que JSZip). Après la décompression, le CRC-32 des octets bruts est recalculé et comparé à la valeur du répertoire central ; une différence indique une corruption ou une altération. Deux aspects de sécurité sont importants pour tout chemin de code d'extraction. Le premier est la vulnérabilité Zip Slip (Snyk, 2018) : une archive malveillante peut contenir des entrées avec des séquences de traversée de chemin comme `../../etc/passwd`, et un extracteur naïf qui concatène le nom de l'entrée à un répertoire cible écrira en dehors du bac à sable prévu. La solution consiste à normaliser le chemin concaténé avec `path.resolve()` et à vérifier qu'il commence toujours par le répertoire cible avant toute écriture. Cet outil propose chaque entrée comme un téléchargement navigateur distinct via `URL.createObjectURL(new Blob([bytes]))` et le navigateur isole la destination, de sorte que la traversée de répertoire ne peut pas sortir du dossier Téléchargements de l'utilisateur, mais la même archive sur un extracteur côté serveur serait exploitable. Ensuite, les archives chiffrées ne sont pas gérées : le ZipCrypto traditionnel est un chiffrement par flux de 32 bits qui peut être cassé trivialement avec une attaque en texte clair connu de trois octets, et le WinZip AES-256 moderne (PKWARE APPNOTE 7.0) nécessite le champ supplémentaire AE-2 avec authentification HMAC-SHA1 — aucun de ces deux chemins n'est implémenté ici. Les archives dépassant 4 Gio s'appuient sur les champs supplémentaires de l'extension ZIP64 pour les tailles et positions sur 64 bits, que le lecteur doit lire à la place des champs 32 bits du répertoire central.

• Ordre d'analyse : parcours en partant de la fin du fichier à la recherche de la signature EOCD `0x06054b50` (max 22 + 65535 octets depuis la fin) → accès au répertoire central → accès à chaque en-tête local.
• Méthodes de compression : `0x00` stocké, `0x08` DEFLATE (RFC 1951, ~99 % des archives), `0x0C` BZIP2, `0x0E` LZMA, `0x5D` PPMd.
• Intégrité : CRC-32 avec le polynôme `0xEDB88320` (IEEE 802.3 inversé) recalculé sur les octets extraits et comparé à la valeur du répertoire central.
• Zip Slip (Snyk 2018) : les entrées contenant des séquences de traversée `../` peuvent écrire en dehors du répertoire d'extraction ; la solution consiste à normaliser et valider le chemin résolu avant l'écriture.
• Implémentation navigateur : `File.arrayBuffer()` → JSZip / fflate `unzipSync()` → `URL.createObjectURL(new Blob([bytes]))` par entrée pour les téléchargements, sans aller-retour serveur.
• Le chiffrement n'est pas géré : ZipCrypto est cassé en 3 octets de texte clair connu ; WinZip AES-256 (APPNOTE 7.0, champ supplémentaire AE-2 avec HMAC-SHA1) n'est pas implémenté ici.
• ZIP64 (APPNOTE 4.5+) étend les champs de taille/position 32 bits à 64 bits via des champs supplémentaires ; requis pour les archives ou entrées individuelles dépassant 4 Gio (2³² − 1 octets).