search

openwall / john

John the Ripper jumbo - advanced offline password cracker, which supports hundreds of hash and cipher types, and runs on many operating systems, CPUs, GPUs, and even some FPGAs
https://www.openwall.com/john/
Other
10.31k stars 2.1k forks source link

batch hashes cracking issue #2535

Closed watanuoli closed 7 years ago

watanuoli commented 7 years ago

I came across the situation as follows: Adding two oldoffice type of files and extract the hashes into the a.enc file(2 lines). 6digits.doc:............. 8digits.doc:............ Then I run 2 commands with the separate rules against them. e.g. 6-digits and 8-digits If I run the 8-digits rules first and cracked 8-digits.doc, then the following command for 6-digits rules report there's no hash left to crack. If I run the 6-digits command first and then 8-digits commands, all the hashes can be cracked. Does it caused be the issue of the mechanism of checking the batch hashes crack status?

magnumripper commented 7 years ago

I haven't seen that before. Perhaps your two hashes are "too similar" for JtR to see the difference in all cases - but that would be a bug of course. Would it be possible for you to share the a.enc file? I believe that file is totally free from actual document contents, it's only meta data.

watanuoli commented 7 years ago 
6.doc:$oldoffice$1*f6391b03f90cf0d10b66b4116463ac20*1d0e3dd64b92265e6907ccf50c1b10bc*e0ce0f57ba306386294b634c9e099c66:::::/home/jim/rc/tmp/2/origin/20170509172828116.doc

8.doc:$oldoffice$1*70744b12ffe9f9956638a28f17a4d9c4*60d9a9c5b462395be03b20c3ce52f38c*6e4e29c224b5a8137296b6d2490feba8:::::/home/jim/rc/tmp/2/origin/20170509172828141.doc
watanuoli commented 7 years ago

8.doc password: 56547313 6.doc password: 954124

watanuoli commented 7 years ago

reproduce step: The first command using 6-digits rules, The second command use 8-digits rules but can not find the hash left to be cracked.

magnumripper commented 7 years ago

Thanks, I can reproduce the problem. Will look into it.

magnumripper commented 7 years ago

@jfoug I'm pretty sure the problem is I got some detail wrong when switching to dyna salt in oldoffice. That's the very commit when this problem was introduced. I just can't see the dang bug. I was always very very confused by the pointer-to-pointer-to-now-you-lost-me involved with dyna salt.

And it's awfully strange: If no hashes are cracked, I can either crack both in one session, in any order. Or I can crack the length-6 one first, then in another session crack the length-8 one. But if cracking just the length-8 hash in a session, subsequent sessions say both are cracked.

And to add further to the weirdness, here's what a --show left looks like after cracking only the length-6 hash:

$ cat 2535.in 
6.doc:$oldoffice$1*f6391b03f90cf0d10b66b4116463ac20*1d0e3dd64b92265e6907ccf50c1b10bc*e0ce0f57ba306386294b634c9e099c66:::::/home/jim/rc/tmp/2/origin/20170509172828116.doc
8.doc:$oldoffice$1*70744b12ffe9f9956638a28f17a4d9c4*60d9a9c5b462395be03b20c3ce52f38c*6e4e29c224b5a8137296b6d2490feba8:::::/home/jim/rc/tmp/2/origin/20170509172828141.doc

$ ../run/john 2535.in -form:oldoffice -show      
6.doc:954124:::::/home/jim/rc/tmp/2/origin/20170509172828116.doc

1 password hash cracked, 1 left

$ ../run/john 2535.in -form:oldoffice -show=left 
8.doc:$oldoffice$1*70744b12ffe9f9956638a28f17a4d9c4*60d9a9c5b462395be03b20c3ce52f38c*6e4e29c224b5a8137296b6d2490feba8
6.doc:$oldoffice$1*70744b12ffe9f9956638a28f17a4d9c4*60d9a9c5b462395be03b20c3ce52f38c*6e4e29c224b5a8137296b6d2490feba8
0 password hashes cracked, 2 left

In the last case, both entries show the salt of the length-8 hash.

magnumripper commented 7 years ago

Fixed now. It had nothing to do with dyna salt, it was the use of source() in a salted format. That simply doesn't work.

@watanuoli kudos for a perfect example so we could reproduce the problem.

watanuoli commented 7 years ago

@magnumripper It works! Thanks for your fix.

solardiz commented 7 years ago

On Thu, May 11, 2017 at 12:27:29PM -0700, magnum wrote:

it was the use of source() in a salted format. That simply doesn't work.

Maybe we can and should have that detected by self-tests? Is this as simple as "source && salt_size"?

magnumripper commented 7 years ago

it was the use of source() in a salted format. That simply doesn't work.

Maybe we can and should have that detected by self-tests? Is this as simple as "source && salt_size"?

Did so in same fix ;-)

+       if (format->methods.source != fmt_default_source &&
+           format->params.salt_size != 0)
+               return "source method only allowed for unsalted formats";