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