Date: Fri, 08 Jun 2012 09:11:15 +0200 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: rawSHA1_LI internals (was: JtR to process the LinkedIn hash dump) On 06/08/2012 07:22 AM, Frank Dittrich wrote: > The other solution is similar, but involves you new get_source. > It should be trivial to restore the correct sha1 hex string, even if you > loaded the one with '00000'. > This could make the cracked LinkedIn hashes stored in john.pot valid for > the normal raw-sha1 format. > (Assuming that the '00000' don't cause false positives, but that should > be a valid assumption.) I had a similar thought. I think this is a cool idea. Could we do it without hacking core? We need to do this: 1. Always load hashes (binaries) with first 20 bits cleared. 2. Always store complete hashes. 3. Always compare hashes without regarding first 20 bits. #3 is easy when cracking (already done in cmp_*) but how about when loading and comparing to john.pot entries? Could prepare() be used? BTW Jim, I'm just now comparing rawSHA1_fmt_plug.c and rawSHA1_LinkedIn_fmt_plug.c using meld. I notice cmp_all() is unchanged. I must be missing something, how can this work? We should only look at binary but as far as I can see this is not the case. I know the code works, but how!? Also, I really think half of the self-tests should have the zeroed bits. 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.