john-users - Re: several problems with JtR + jumbo 9 and/or omp-des-7

Openwall GNU/*/Linux 3.0 - a small security-enhanced Linux distro for servers

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Fri, 17 Dec 2010 18:01:39 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: several problems with JtR + jumbo 9 and/or omp-des-7

bartavelle -

I managed to reproduce the problem by generating what I think are
equivalents of your lmcracked and ntdump files - with the exact same
password that you used in your test.  With the correct password on line
16 of the output of "john -w:lmcracked -rules:nt -stdout", the NT hash
does not get cracked.  With the correct password moved to line 8, it
does.  This confirms your analysis.

On Fri, Dec 17, 2010 at 11:05:12AM +0100, bartavelle wrote:
> The comparison code was :
> 
> for(;i<(NT_NUM_KEYS/2);i+=4)
> if(b==output8x[i] || b==output8x[i+1] || b==output8x[i+2] ||
> b==output8x[i+3] || b==output8x[i+4] || b==output8x[i+5] ||
> b==output8x[i+6] || b==output8x[i+7])
>                         return 1;
> 
> It looks like it compares the A's B's C's and D's of the first row,
> while it should compare the B's of all four rows. I don't know how that
> could work for you.

cmp_all() is only used when there's no hash table - that is, when
cracking too few hashes for the use of a hash table to be worthwhile.

> This seems to work for me :
> 
> for(;i<(NT_NUM_KEYS/8);i++)
> 		if(b==output8x[i*32+8] || b==output8x[i*32+9] || b==output8x[i*32+10]
> || b==output8x[i*32+11] || b==output8x[i*32+12] || b==output8x[i*32+13]
> || b==output8x[i*32+14] || b==output8x[i*32+15])

I'll give this a try.

Clearly, we need more test cases - not only large files, but also small
and tiny ones.

Thank you!

Alexander