[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7e7173293fcf5d000c440035ff996474@smtp.hushmail.com>
Date: Wed, 28 Mar 2018 18:54:38 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: "No password hashes loaded" for zip2john output,
pkzip
On 2018-03-28 18:38, Nick Shaw wrote:
> 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.
The stderr output from zip2john should be:
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
> different salts to test db from test vectors
>
> On Tue, Mar 27, 2018 at 10:33 AM, Nick Shaw <nick.shaw@...blk.net> wrote:
>
>> Just pulled and got a MUCH larger hash than previous. Will try with this
>>
>>
>> On Tue, Mar 27, 2018 at 10:22 AM, magnum <john.magnum@...hmail.com> wrote:
>>
>>> On 2018-03-26 23:22, Nick Shaw wrote:
>>>
>>>> Zip is nothing that needs to be private, heres a link:
>>>> 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
>>>
>>>
>>> On Mon, Mar 26, 2018 at 4:36 PM, magnum <john.magnum@...hmail.com> wrote:
>>>>
>>>> On 2018-03-26 17:36, 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
>>>>>>
>>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
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.
