Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 13 Mar 2007 03:06:51 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: LM an NTLM combination

Alain,

On Mon, Mar 12, 2007 at 11:47:09PM +0100, Alain Espinosa wrote:
> I think (-4 version) that before enter to cmp_one john need to enter to
> cmp_all ...

Not always.  With a large number of hashes for a given salt (or just with
a large number of hashes as NTLM ones are saltless), John uses hash
table lookups instead of cmp_all().  That's what those binary_hash_*()
and get_hash_*() functions are for.

> But forget about cmp_all. Insert the lines in -4 patch. Eliminate this lines
> (344,345) now could make that at least more or equal hashes pass the test of
> cmp_one and the bug (if existed) need to be accept password that dont have
> the current hash. But what happens its the opposite. And i dont understand
> why in 2 pass john find passwords. Maybe Solar, who know the intrinsics of
> john, can explain. I dont undestand.

This was tricky, but I think I figured it out - in cmp_one(), you're
modifying global variables.  However, cmp_one() may be called more than
once per hash computation as there may be multiple loaded hashes in a
given hash bucket.  Please see the second pair of nested loops in
cracker.c: crk_password_loop().

In -5, you've declared the proper local variables in cmp_one(), thereby
solving the problem.

Now that you know that cmp_one() may be called more than once per hash
computation when large numbers of hashes are loaded, you should be able
to optimize it further for such cases.

Thanks,

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15  fp: B3FB 63F4 D7A3 BCCC 6F6E  FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments

-- 
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ