Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <003001cd4588$b565f840$2031e8c0$@net>
Date: Fri, 8 Jun 2012 10:09:31 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Was: RE: [john-users] JtR to process the LinkedIn hash dump

I think I have this, BUT it will only be on jumbo-bleeding edge.  This fix
requires the get_source.

Here is what I did.  I still need to FULLY test, to make sure I did not bung
up any format self test, because I made  a code change there.  (NOPE,
getting cores, so  I need to still address this).

1. did this to fmt_self_test.  NOTE, I will probably do this, but check to
see if we are running sha1-LI

+		format->methods.set_key(current->plaintext, 0);
		if (strcmp(format->methods.get_source(&pw, Buf),
ciphertext)) 
			return "get_source";

2. I changed the split for raw-sha1_LI to jam 0000 to all ciphertext values.
So internally within JtR, ALL hashes now have 00000
3. within set_key, I track how many keys are valid (store the index into a
static var, so I know the 'max').
4. Within get_source(), I loop through all crypt values.  I do this ONLY if
that max_key is > 0.
5. in fmt_self_test, when get_source is called in raw-sha1_LI, that max_key
is always 0, so the replacement is not done during self test.

This should work.  It DOES cause this input file:

0000003ced2802e237e597f6a9d14e963206d6c3
aaaaaaaaaaaaaaaaaae597f6a9d14e963206d6c3
122b603ced2802e237e597f6a9d14e963206d6c3

To say there are only 2 hashes, and it properly finds the hash, but my code
at this time stores the wrong value (the 00000 one).  However, upon re-run,
it does say 2 loaded, only 1 left, which is correct.

I simply think I have to work around some issues to get it right.

BUT THIS will only work with a get_source.  I am only targeting bleeding at
this time. Once I get that fully working, I will change it into the
get_source patch for magnum-jumbo.

Note, the above 5 items (the >0) will cause self_test fails for non-sse
builds.  I may simply work around this by not putting the 00000's out into
the self test strings.    Without those 00000's then the self tests work,
because the breakage of the equation get_source() == split(prepare(orig)) is
not broken.

Jim.



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.