[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAAZfsyzYC79RxvD1mWiQX7NpL6b_oRraApNWOCA-V7gEZWHuqg@mail.gmail.com>
Date: Wed, 28 Mar 2018 12:58:01 -0400
From: Nick Shaw <nick.shaw@...blk.net>
To: john-users@...ts.openwall.com
Subject: Re: "No password hashes loaded" for zip2john output, pkzip
Excellent, thanks for the clarification/confirmation!
On Wed, Mar 28, 2018 at 12:54 PM, magnum <john.magnum@...hmail.com> wrote:
> 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.
