[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <90229bd0ad59c3ce5b26d14e76060b5b@smtp.hushmail.com>
Date: Fri, 08 Jun 2012 21:07:17 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: JtR to process the LinkedIn hash dump
On 06/08/2012 05:45 PM, jfoug wrote:
> I believe this version (patches into magnum-jumbo), fixes the problem.
You mean bleeding-jumbo. It won't work with magnum-jumbo.
While I was offline I played with this too and it's amazing how we ended
up almost exactly the same.
Instead of adding that key_count, I just used max_keys_per_crypt from
the format struct. That should be faster ;-)
The other difference is that for some reason I totally overlooked that
we had the missing bits already calculated in crypt_key[] so I actually
re-created the whole hash using OpenSSL. Sometimes I'm a moron :)
Lastly, I check all available bits in cmp_one, trying to minimize false
positives due to partial hash collisions. But that might be totally
overkill.
-// if( ((ARCH_WORD_32*)binary)[0] != crypt_key[x+y*MMX_COEF*5] )
-// return 0;
+ if( (((ARCH_WORD_32*)binary)[0] & 0x00000fff) !=
(crypt_key[x+y*MMX_COEF*5] & 0x00000fff) )
+ return 0;
The above is fixed endianness. For the non-MMX code I had similar things
with #if ARCH_LITTLE_ENDIAN .. #else ...
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.
