[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 Sep 2020 18:02:57 +0100
From: Jasper Jones <jazjones9292@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: cracking encrypted zip file
Correction - I just realised that the john.rec error message I recalled was
for JtR, not zip2John. I've now tried zip2john with the zip file I just
sent (attached again), and the result (test3.txt) is attached.
I also got the following error message: ver 5.1 test.zip/Test.dat is not
encrypted, or stored with a non-handled compression type".
I can't test whether the password can be cracked until the current run
finishes.
Jasper
On Thu, 17 Sep 2020 at 17:53, Jasper Jones <jazjones9292@...il.com> wrote:
> Before starting to try cracking the actual password, I did try zip2john
> and then JtR with a small zip file I created with the same program (7zip)
> and encryption settings, and it worked. It looks like I need to let the
> current process finish before I can run a new one (something about john.rec
> file being in use), but I'll certainly make a note to run it again with a
> similarly sized file and give you all the info I can.
>
> In case anyone wants to have a quick go in the meantime, I attach a zipped
> file I just generated with the same version of 7zip as was used on the file
> I'm trying to crack. It contains a dummy .dat file filled with random text
> and is AES-256 encrypted with password: testforjohn2txt
>
> Thanks
> Jasper
>
> On Thu, 17 Sep 2020 at 17:25, Solar Designer <solar@...nwall.com> wrote:
>
>> On Thu, Sep 17, 2020 at 04:20:30PM +0100, Jasper Jones wrote:
>> > On Wed, 16 Sep 2020 at 20:51, Solar Designer <solar@...nwall.com>
>> wrote:
>> > > On Wed, Sep 16, 2020 at 06:47:10AM +0100, Jasper Jones wrote:
>> > > > Loaded 1 password hash (ZIP, WinZip, [PKDF2-SHA1 128/128 AVX 4x1)"
>> > > >
>> > > > Does that look right? The reference to PKDF2-SHA1 instead of AES
>> concerns
>> > > > me, but I appreciate that could just be my ignorance showing.
>> > >
>> > > You've already figured this out (great!), but we might want to revise
>> > > this algorithm name string to also include AES.
>> >
>> > Cool.
>>
>> I just looked into this, and no - that algorithm name string is correct
>> as-is, and adding AES in there would be wrong. We're able to
>> distinguish correct vs. wrong passwords without ever using AES in there.
>>
>> > > As to the error you were getting originally:
>> > >
>> > > > > That said, I'm still getting an error as well: "ver 5.1
>> > > > > wallet.zip/wallet.dat is not encrypted, or stored with non-handled
>> > > > > compression type".
>> > >
>> > > It certainly looks like you have more than one file, or one file more
>> > > than once, in that archive. It might even be that you have the
>> > > wallet.dat file in there in both encrypted and non-encrypted form.
>> >
>> > I'm pretty sure there's just the one file in there. I definitely
>> wouldn't
>> > have encrypted it first and then zipped it. It was just zipped (using
>> 7Zip)
>> > with a password and AES256 encryption selected. There's also just the
>> one
>> > file - wallet.dat - listed when you open the archive.
>>
>> OK.
>>
>> > > Alternatively, we have a bug resulting in that spurious message.
>> >
>> > I'll leave that to you to decide! :)
>>
>> We'd need to reproduce the problem for that. It would be great if you
>> manage to generate another encrypted WinZip archive, with dummy content
>> and a known password, yet trigger the same behavior from zip2john. This
>> will serve two purposes: (1) you'll know whether or not the password is
>> crackable with our current code despite of this error, and (2) we'll be
>> able to look into the issue on our end (assuming that you'll share that
>> archive with us).
>>
>> > > > > I don't have zipinfo (I'm on Windows), but I could download a
>> bootable
>> > > > > Linux distribution if that would help.
>> > >
>> > > I guess you can get zipinfo on Windows if you install Cygwin.
>> >
>> > Do you think it would help at this stage?
>>
>> It wouldn't help as much as generating a suitable dummy archive would,
>> but it might provide us with some extra clue.
>>
>> > Perhaps if the current run
>> > doesn't work I can look into that and see whether it gives more info
>> than
>> > I've found so far.
>>
>> OK.
>>
>> Alexander
>>
>
Content of type "text/html" skipped
View attachment "test3.txt" of type "text/plain" (633 bytes)
Download attachment "Test.zip" of type "application/x-zip-compressed" (452 bytes)
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.
