[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAZfsyyVqeTjiVvr5-TkMSHVsVZd_VkJX5hXMMYRQ1NMysF1+w@mail.gmail.com>
Date: Tue, 27 Mar 2018 10:33:11 -0400
From: Nick Shaw <nick.shaw@...blk.net>
To: john-users@...ts.openwall.com
Subject: Re: "No password hashes loaded" for zip2john output, pkzip
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.
