openwall / openwall/john

zip2john fails to get hash from Deflate64 (d64N) compressed pkzip files

Open
#5,801 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
C
Stars
13.6k
Forks
2.6k
PR merge metrics
No merged PRs in 30d

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the zip2john entry point and trace how PKZIP compression methods are recognized, using the reported Deflate64 (d64N) archive details as the reproduction case. Determine where encrypted Deflate64 files are rejected, then verify that zip2john extracts a usable hash from the sample archive without regressing other PKZIP methods.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
cli, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.