openwall
zip2john fails to get hash from Deflate64 (d64N) compressed pkzip files
Hi
I've recently obtained few pkzip archives, which are not password protected from the zip2john point of view, but they actually are.
All those archives are pkzip compressed with deflate64:
zip2john test.zip
test.zip is not encrypted, or stored with non-handled compression type
7z x test.zip
Enter password (will not be echoed):
zipinfo test.zip
Archive: test.zip
Zip file size: 2635255 bytes, number of entries: 1
-rw-a-- 6.3 fat 3829171 Bx d64N 25-Jun-03 11:23 xxx.bin
1 file, 3829171 bytes uncompressed, 2634973 bytes compressed: 31.2%
zipinfo -vv test.zip
Archive: test.zip
There is no zipfile comment.
End-of-central-directory record:
-------------------------------
Zip archive file size: 2635255 (00000000002835F7h)
Actual end-cent-dir record offset: 2635233 (00000000002835E1h)
Expected end-cent-dir record offset: 2635233 (00000000002835E1h)
(based on the length of the central directory and its expected offset)
This zipfile constitutes the sole disk of a single-part archive; its
central directory contains 1 entry.
The central directory is 150 (0000000000000096h) bytes long,
and its (expected) offset in bytes from the beginning of the zipfile
is 2635083 (000000000028354Bh).
Central directory entry #1:
---------------------------
xxx.bin
offset of local header from start of archive: 0
(0000000000000000h) bytes
file system or operating system of origin: MS-DOS, OS/2 or NT FAT
version of encoding software: 6.3
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.1
compression method: deflated (enhanced-64k)
compression sub-type (deflation): normal
file security status: encrypted
extended local header: no
file last modified on (DOS date/time): 25-Jun-03 11:23
32-bit CRC value (hex): 60a7deee
compressed size: 2634985 bytes
uncompressed size: 3829171 bytes
length of filename: 25 characters
length of extra field: 79 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
non-MSDOS external file attributes: 000000 hex
MS-DOS file attributes (20 hex): arc
The central-directory extra field contains:
- A subfield with ID 0x000a (PKWARE Win32) and 32 data bytes. The first
20 are: 00 00 00 00 01 00 18 00 a8 f1 47 a3 e9 ec db 01 00 00 00 00.
- A subfield with ID 0x7075 (UTF8 path name) and 39 data bytes. The first
24 UTF8 bytes in the extra field (V1, ASCII name CRC `a7c88f5a') are:
d0 97 d0 b0 d0 b4 d0 b0 d0 bd d0 b8 d0 b5 20 d0 9a d0 a0 5f 30 34 2e 30.
There is no file comment.
Thanks @banderlog!
Are you testing this with the latest zip2john you built from source code in this repo, or with some other version/build?
Can you please provide a sample zip archive like this (with no sensitive data in it, and a known password)? Perhaps add it to https://github.com/openwall/john-samples/tree/main/ZIP via a pull request against that repo.
@solardiz My bad, I've just pulled the latest changes from this JtR repo and retried -- same result
john
John the Ripper 1.9.0-jumbo-1+bleeding-b27f951a8e 2025-07-02 22:39:41 +0200 OMP [linux-gnu 64-bit x86_64 AVX2 AC]
Copyright (c) 1996-2025 by Solar Designer and others
Homepage: https://www.openwall.com/john/
Usage: john [OPTIONS] [PASSWORD-FILES]
Use --help to list all available options.
As for the archive, I'll try to build one, according to your demands.
@solardiz
Can you please provide a sample zip archive like this (with no sensitive data in it, and a known password)? Perhaps add it to https://github.com/openwall/john-samples/tree/main/ZIP via a pull request against that repo.
done, zip2john behaves with this sample archive in the same way as described above