Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 26 Mar 2018 19:58:39 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: "No password hashes loaded" for zip2john output, pkzip

On Mon, Mar 26, 2018 at 11:36:37AM -0400, Nick Shaw wrote:
> 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.

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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.