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 188.8.131.52. 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 184.108.40.206. 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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ