|
Message-ID: <CABwuPXf9gJ64-xn8VoKDffPuZEQVdbfVtoQj+nqD+v=K3fGwWQ@mail.gmail.com> 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.