[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1179513507.9952.83.camel@localhost>
Date: Fri, 18 May 2007 13:38:27 -0500
From: jmk <jmk@...fus.net>
To: john-users <john-users@...ts.openwall.com>
Subject: Re: LM/NTLMv1 challenge/response cracking
Finally have some time to revisit this...
On Fri, 2007-04-13 at 08:55 +0400, Solar Designer wrote:
> Well, the first difficulty that a user of this patch will face is that
> it looks like it should be applied on top of another patch, but it is
> not immediately obvious what that other patch is. Perhaps it's either
> john-1.7-all-4.diff or john-1.7.2-all-3.diff, but somehow your patch is
> against patched 1.7.0.2. One way to make this more obvious is to
> include the previous patch filename in the old directory name, but then
> you'd need to generate the diff manually rather than with SVN.
Yeah, the patch is against something that started life as 1.7.0.2.
Unfortunately, I've made so many hacks to it that describing the
patching order would be nearly impossible.
> A better approach could be to make this patch against a JtR release with
> no other patches. Erik might merge it into the jumbo patch later. A
> proper filename for your patch would be john-1.7.2-lm-ntlm-cr-jmk-1.diff
> (if you make it against 1.7.2) or maybe john-1.7.2-netlm-ntlm1-jmk-1.diff.
When I undertake the project of migrating to 1.7.2, I'll attempt to make
a clean patch of just this work and post it.
> Another observation is that you seem to be confused by the issue with
> case sensitivity of hex-encoded hashes. You've set FMT_SPLIT_UNIFIES_CASE
> for one of two "formats" added by your patch, although it is needed for
> both, and you're not providing an appropriate split() function for either
> (so your setting FMT_SPLIT_UNIFIES_CASE is a lie). I understand that
> this stuff is confusing; I should address it within the JtR core when I
> get around to re-working it.
Yup, I'm certainly confused. I believe I originally thought that
FMT_SPLIT_UNIFIES_CASE had something to do with password case
sensitively, rather than hash character case.
Looking at this again, I can't figure out why I should necessarily use
split() and FMT_SPLIT_UNIFIES_CASE for either format. The way I read
things is that these items serve two purposes. The first being to split
hashes, such as LM, which can be cracked as independent chunks. IIRC,
neither the LM nor the NTLM challenge/response hashes work this way.
The second benefit I see is that hashes will be stored in files (e.g.
john.pot) in a consistent form. Specifically, all hex alpha characters
could be upper-cased. I'm confused as to whether this would actually
affect JtR or is it just for good style? Mixing case within the hashes
doesn't seem to affect my tests.
Please correct me if I'm completely missing the boat here.
> You should move your conversion to uppercase from netlm_crypt_all() to
> netlm_set_key(), such that netlm_get_key() will return the converted
> string.
I can move the upper-case conversion to set_key(), but that causes the
self test to fail. The self test appears to compare the original
password and the response from get_key, which would be the upper-cased
version of the password. I'm sure there's a step I'm missing here, but
I'm not seeing it.
Thanks!
Joe
--
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
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.
