Date: Sat, 9 Sep 2006 11:10:48 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Re: "Extra" in incremental mode not fully working Radim, On Tue, Aug 29, 2006 at 12:45:40PM +0000, Radim wrote: > Were you able to crack the md5-hash example I've included? I've just tried that - just to make sure there's no bug in the code that I might be missing. Yes, I was able to crack both of the hashes you had posted, by using these params.h settings: > > #define CHARSET_MIN ' ' > > #define CHARSET_MAX 0xFF > > #define CHARSET_SIZE (CHARSET_MAX - CHARSET_MIN + 1) > > #define CHARSET_LENGTH 8 > > #define CHARSET_SCALE 0x10 To generate a new .chr file, I first ran: ./john -i=alpha -stdout | sed 's/^/:/; 1000000q' > john.pot with the unpatched JtR (such that it would still accept the supplied alpha.chr file). Then I patched the CHARSET_* settings in params.h as indicated above, rebuilt (not forgetting to "make clean" first), and generated a new .chr file: ./john -make=new.chr In john.conf, I've defined a new "incremental" mode as follows: [Incremental:New] File = $JOHN/new.chr MinLen = 0 MaxLen = 5 Extra = ... where the Extra line was taken verbatim from your JOHN.INI.cz: > begin 644 JOHN.INI.cz > M6TEN8W)E;65N=&%L.D%L<&AA8WHU70T*1FEL92`]("1*3TA.+V%L<&AA+F-H > M<@...6EN3&5N(#T@...*36%X3&5N(#T@...*17AT<F$@...LFNCXGOWA[>GZ > 6^>^=\_+,BLC8CMW!S<G:V<^-T](-"@`` > ` > end Finally, I ran: ./john -i=new -fo=raw-md5 pw-md5 where pw-md5 contained: testcz:65775a4b0631c2b88117153163b921a0 testcz2:1826e74f4ab2a9c728b2f53445e0af6c Both hashes got cracked at about the same time: 0:00:00:00 Starting a new session 0:00:00:00 Loaded a total of 2 password hashes with no different salts 0:00:00:00 Remaining 2 password hashes with no different salts 0:00:00:00 - Hash type: Raw MD5 (lengths up to 32) 0:00:00:00 - Algorithm: raw-md5 MMX 0:00:00:00 - Candidate passwords will be buffered and tried in chunks of 2 0:00:00:00 - Configured to use otherwise idle processor cycles only 0:00:00:00 Proceeding with "incremental" mode: new 0:00:00:00 - Lengths 0 to 5, up to 224 different characters 0:00:00:00 ! Only 56 characters available ... 0:00:00:38 - Trying length 4, fixed @4, character count 34 0:00:00:38 + Cracked testcz2 0:00:00:38 + Cracked testcz 0:00:00:38 Session completed > Note compiling warnings: > charset.c: In function `charset_filter_plaintexts': > charset.c:46: warning: comparison is always false due to limited range of data type It is safe to ignore this one. It is referring to the fact that an "unsigned char" variable can't possibly have a value greater than 0xFF - our new setting for CHARSET_MAX - so one of the two comparisons on that line of charset.c becomes redundant. If this warning bothers you, then you can set CHARSET_MAX to 0xFE instead. > When I try it with the above code I can't still crack the hash. > > I've analyzed the output of the incremental mode with the Extra option using the > stdout option and there were all kinds of other 8-bit characters on top of the > intended 56 + 0x0A. Like: from 0x01 all upto 0x0F, then 0x11, 0x12, 0x14, 0x15, > 0x19, 0x1C,... occasionally upto 0xDF. That's very wrong. Perhaps you were doing something different from what I've described above? Also, what do you mean by the "intended 56 + 0x0A"? There should be just 56 different characters tried with your desired settings, no more. The linefeed character should not be tried - there's nowhere it could legitimately appear from, it is below CHARSET_MIN, and it is not a part of the passwords you're trying to crack. -- 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 Was I helpful? Please give your feedback here: http://rate.affero.net/solar -- 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