[john-users] "No password hashes loaded" for zip2john output, pkzip

Hi Nick,

Post by Nick Shaw
Hi - running john-1.7.9-jumbo-5 on linux and john keeps telling me "No
password hashes loaded" for a pkzip hash.

Please upgrade to current bleeding-jumbo and try again (both zip2john
and john). There's no point in troubleshooting whatever went wrong with
the obsolete version.

Alexander

Nick Shaw

2018-03-26 13:36:15 UTC

I have upgraded to the latest on another VM. Same thing.
1.8.0.6-jumbo-1-bleeding

Sent from my Google Pixel 2 XL

Post by Solar Designer
Hi Nick,

Post by Nick Shaw
Hi - running john-1.7.9-jumbo-5 on linux and john keeps telling me "No
password hashes loaded" for a pkzip hash.

Please upgrade to current bleeding-jumbo and try again (both zip2john
and john). There's no point in troubleshooting whatever went wrong with
the obsolete version.
Alexander

Solar Designer

2018-03-26 14:56:08 UTC

Post by Nick Shaw
I have upgraded to the latest on another VM. Same thing.
1.8.0.6-jumbo-1-bleeding

That's still not the latest (by far). Please get the latest off GitHub.
It should call itself 1.8.0.13-jumbo-... (notice the 13 instead of 6).
Don't forget to rerun zip2john (there have been many relevant fixes to
it between 6 and 13).

Alexander

Nick Shaw

2018-03-26 15:36:37 UTC

Updates to 1.8.0.13-jumbo as Solar suggested, re-ran zip2john, and now it's
giving me this:

Alice.zip->Users/Daniel/Desktop/Alice/ is not encrypted!
ver 1.0 Scanning for EOD... FOUND Extended local header
Alice.zip->Users/Daniel/Desktop/Alice/ is not encrypted, or stored with
non-handled compression type

Is this being caused by the folder structure within the zip? Again, in that
folder is a mp3 with a password on it.

Post by Nick Shaw
I have upgraded to the latest on another VM. Same thing.
1.8.0.6-jumbo-1-bleeding
Sent from my Google Pixel 2 XL

Post by Solar Designer
Hi Nick,

Post by Nick Shaw
Hi - running john-1.7.9-jumbo-5 on linux and john keeps telling me "No
password hashes loaded" for a pkzip hash.

Please upgrade to current bleeding-jumbo and try again (both zip2john
and john). There's no point in troubleshooting whatever went wrong with
the obsolete version.
Alexander

Solar Designer

2018-03-26 17:58:39 UTC

Post by Nick Shaw
Updates to 1.8.0.13-jumbo as Solar suggested, re-ran zip2john, and now it's
Alice.zip->Users/Daniel/Desktop/Alice/ is not encrypted!
ver 1.0 Scanning for EOD... FOUND Extended local header
Alice.zip->Users/Daniel/Desktop/Alice/ is not encrypted, or stored with
non-handled compression type
Is this being caused by the folder structure within the zip? Again, in that
folder is a mp3 with a password on it.

Probably not by the folder structure, but by other properties of this
archive. Can you try to create a test zip archive (with a known
password and non-sensitive content) using the same software that was
used to create the target one? Try to get that one cracked. If you run
into problems with that one as well, then provide it to JtR jumbo
developers for testing and possibly adding support (if it's missing).

I guess the MP3 file might not be compressible, and thus might not be
stored in compressed form. Maybe there's some issue with handling of
non-compressed data in zip2john and john. But that's just a guess.

Maybe you can also run Info-ZIP's zipinfo on the original archive, and
show us its output? On Linux, zipinfo is typically in unzip package.

Thanks,

Alexander

Nick Shaw

2018-03-26 18:12:53 UTC

I can try, but I would have to get the user to make it which isn't likely.
I can assume they just archived and passworded the file on OS X.

I can also send the zip file as there isn't anything sensitive in it. This
was provided as a challenge (that I am failing miserably at) from a band to
get someone to "decrypt" the file holding a new song.

Here's the zipinfo:
Archive: Alice.zip
There is no zipfile comment.

End-of-central-directory record:
-------------------------------

Zip archive file size: 5345529 (00000000005190F9h)
Actual end-cent-dir record offset: 5345507 (00000000005190E3h)
Expected end-cent-dir record offset: 5345507 (00000000005190E3h)
(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 2 entries.
The central directory is 203 (00000000000000CBh) bytes long,
and its (expected) offset in bytes from the beginning of the zipfile
is 5345304 (0000000000519018h).

Central directory entry #1:
---------------------------

Users/Daniel/Desktop/Alice/

offset of local header from start of archive: 0
(0000000000000000h) bytes
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 1.0
compression method: none (stored)
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2018 Jan 22 18:50:06
file last modified on (UT extra field modtime): 2018 Jan 22 18:50:05 local
file last modified on (UT extra field modtime): 2018 Jan 22 23:50:05 UTC
32-bit CRC value (hex): 00000000
compressed size: 0 bytes
uncompressed size: 0 bytes
length of filename: 27 characters
length of extra field: 24 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (040755 octal): drwxr-xr-x
MS-DOS file attributes (10 hex): dir

The central-directory extra field contains:
- A subfield with ID 0x5455 (universal time) and 5 data bytes.
The local extra field has UTC/GMT modification/access times.
- A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
01 04 f5 01 00 00 04 14 00 00 00.

There is no file comment.

Central directory entry #2:
---------------------------

Users/Daniel/Desktop/Alice/Alice.mp3

offset of local header from start of archive: 85
(0000000000000055h) bytes
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: deflated
compression sub-type (deflation): normal
file security status: encrypted
extended local header: yes
file last modified on (DOS date/time): 2017 Jul 18 19:44:06
file last modified on (UT extra field modtime): 2017 Jul 18 19:44:05 local
file last modified on (UT extra field modtime): 2017 Jul 18 23:44:05 UTC
32-bit CRC value (hex): d0e01601
compressed size: 5345109 bytes
uncompressed size: 5389429 bytes
length of filename: 36 characters
length of extra field: 24 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (100644 octal): -rw-r--r--
MS-DOS file attributes (00 hex): none

The central-directory extra field contains:
- A subfield with ID 0x5455 (universal time) and 5 data bytes.
The local extra field has UTC/GMT modification/access times.
- A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
01 04 f5 01 00 00 04 14 00 00 00.

There is no file comment.

Post by Solar Designer

Post by Nick Shaw
Updates to 1.8.0.13-jumbo as Solar suggested, re-ran zip2john, and now

it's

Post by Nick Shaw
Alice.zip->Users/Daniel/Desktop/Alice/ is not encrypted!
ver 1.0 Scanning for EOD... FOUND Extended local header
Alice.zip->Users/Daniel/Desktop/Alice/ is not encrypted, or stored with
non-handled compression type
Is this being caused by the folder structure within the zip? Again, in

that

Post by Nick Shaw
folder is a mp3 with a password on it.

Probably not by the folder structure, but by other properties of this
archive. Can you try to create a test zip archive (with a known
password and non-sensitive content) using the same software that was
used to create the target one? Try to get that one cracked. If you run
into problems with that one as well, then provide it to JtR jumbo
developers for testing and possibly adding support (if it's missing).
I guess the MP3 file might not be compressible, and thus might not be
stored in compressed form. Maybe there's some issue with handling of
non-compressed data in zip2john and john. But that's just a guess.
Maybe you can also run Info-ZIP's zipinfo on the original archive, and
show us its output? On Linux, zipinfo is typically in unzip package.
Thanks,
Alexander

magnum

2018-03-26 20:36:40 UTC

Yet zipinfo shows us there is a compressed file in there. Off the top of
my head, the "scanning...found" implies we may be down to some
less-than-100%-defined code path of zip2john that I might have added
within the last year or so. A good way to help improving that code is to
feed us with samples that fail.

Feel free to send my a/the sample zip in private, or right here.

magnum

Nick Shaw

2018-03-26 21:22:15 UTC

Zip is nothing that needs to be private, heres a link:
http://anonfile.com/r0U5U0d8b7/Alice.zip

Thanks!

Yet zipinfo shows us there is a compressed file in there. Off the top of
my head, the "scanning...found" implies we may be down to some
less-than-100%-defined code path of zip2john that I might have added within
the last year or so. A good way to help improving that code is to feed us
with samples that fail.
Feel free to send my a/the sample zip in private, or right here.
magnum

magnum

2018-03-27 14:22:34 UTC

Post by Nick Shaw
http://anonfile.com/r0U5U0d8b7/Alice.zip

Great, with that file I could reproduce the problem and fix it. Please
pull latest code from GitHub and you should be set.

magnum

Yet zipinfo shows us there is a compressed file in there. Off the top of
my head, the "scanning...found" implies we may be down to some
less-than-100%-defined code path of zip2john that I might have added within
the last year or so. A good way to help improving that code is to feed us
with samples that fail.
Feel free to send my a/the sample zip in private, or right here.
magnum

Nick Shaw

2018-03-27 14:33:11 UTC

Just pulled and got a MUCH larger hash than previous. Will try with this

Post by Nick Shaw
http://anonfile.com/r0U5U0d8b7/Alice.zip

Great, with that file I could reproduce the problem and fix it. Please
pull latest code from GitHub and you should be set.
magnum

Post by Nick Shaw
Updates to 1.8.0.13-jumbo as Solar suggested, re-ran zip2john, and now

Post by Nick Shaw
it's
Alice.zip->Users/Daniel/Desktop/Alice/ is not encrypted!
ver 1.0 Scanning for EOD... FOUND Extended local header
Alice.zip->Users/Daniel/Desktop/Alice/ is not encrypted, or stored with
non-handled compression type

Yet zipinfo shows us there is a compressed file in there. Off the top of
my head, the "scanning...found" implies we may be down to some
less-than-100%-defined code path of zip2john that I might have added within
the last year or so. A good way to help improving that code is to feed us
with samples that fail.
Feel free to send my a/the sample zip in private, or right here.
magnum

Nick Shaw

2018-03-28 16:38:28 UTC

Is it right that the new hash file I would've got from that zip is about
10mb?

John loaded 1 password hash (PKZIP [32/64]), Loaded 9 hashes with 9
different salts to test db from test vectors

Post by Nick Shaw
Just pulled and got a MUCH larger hash than previous. Will try with this

Post by Nick Shaw
http://anonfile.com/r0U5U0d8b7/Alice.zip

Great, with that file I could reproduce the problem and fix it. Please
pull latest code from GitHub and you should be set.
magnum

Post by Nick Shaw
Updates to 1.8.0.13-jumbo as Solar suggested, re-ran zip2john, and now

Yet zipinfo shows us there is a compressed file in there. Off the top of
my head, the "scanning...found" implies we may be down to some
less-than-100%-defined code path of zip2john that I might have added within
the last year or so. A good way to help improving that code is to feed us
with samples that fail.
Feel free to send my a/the sample zip in private, or right here.
magnum

magnum

2018-03-28 16:54:38 UTC

This post might be inappropriate. Click to display it.

Nick Shaw

2018-03-28 16:58:01 UTC

Excellent, thanks for the clarification/confirmation!

Post by Nick Shaw
Is it right that the new hash file I would've got from that zip is about
10mb?

Yes. The generated file will include a chunk of data from the zip file, of
whatever size is required for cracking. Unfortunately it's hex-encoded
which means a 5 MB data chunk will end up as 10 MB worth of hex digits. Had
there been some smaller encrypted file in the archive as well, zip2john
would have picked it instead.
ver 2.0 efh 5455 efh 7875 Alice.zip->Users/Daniel/Desktop/Alice/Alice.mp3
PKZIP Encr: 2b chk, TS_chk, cmplen=5345109, decmplen=5389429, crc=D0E01601
You can see that "crc" is the same as reported by zipinfo, which is a good
sign all is correct. The compressed/uncompressed sizes are too. Your output
file will be a bittle larger than 2*5345109 in this case, or about 10 MB.
magnum
John loaded 1 password hash (PKZIP [32/64]), Loaded 9 hashes with 9

Post by Nick Shaw
different salts to test db from test vectors
Just pulled and got a MUCH larger hash than previous. Will try with this

Post by Nick Shaw
http://anonfile.com/r0U5U0d8b7/Alice.zip

Great, with that file I could reproduce the problem and fix it. Please
pull latest code from GitHub and you should be set.
magnum