Date: Tue, 29 Aug 2006 12:45:40 +0000 (UTC) From: Radim <yesbody@...nam.cz> To: john-users@...ts.openwall.com Subject: Re: "Extra" in incremental mode not fully working Solar Designer <solar@...> writes: > > Extra = ... > > Your message has arrived with charset=utf-8. Although you've mentioned > that you've been using "codepage win1250", I am not sure what 8-bit > character values you actually had in your john.conf. Hi, thanks for reply They are certainly win1250 - they've got converted to utf8 with the posting. To be absolutely sure I'm including uuencoded part of john.ini at the end of this post. > What version of John? Sorry - I forgot to include that: John 1.7 (with the jumbo patch to crack (not only) raw-MD5) - windows version. I suspect that maybe the problem could be somewhere in Cygwin. There've been issues with reading files in non-binary mode under cygwin in some other ported programs. I haven't tested this issue on *nix. However, the characters have the same encoding as the dictionary files, that are working well. Were you able to crack the md5-hash example I've included? > Anyway, this should have worked as long as the total number of different > characters (those coming from the .chr file and those you've added with > Extra) doesn't exceed CHARSET_SIZE (95 by default). there were 30 extras + the official alpha.chr = which makes 56 right? The problem shows up even if I include only one problematic character. > #define CHARSET_MIN ' ' > #define CHARSET_MAX 0xFF > #define CHARSET_SIZE (CHARSET_MAX - CHARSET_MIN + 1) > #define CHARSET_LENGTH 8 > #define CHARSET_SCALE 0x10 > > that is, you change CHARSET_MAX from 0x7E to 0xFF and CHARSET_SCALE from > 0x100 to 0x10, leaving the rest at the defaults. Of course, you'll be > forced to generate new .chr files. > > Some john-users might notice that with the above settings we're > actually slightly exceeding 64 bits for ((SIZE ** LENGTH) * SCALE), > which the comment say to not do. However, in reality the requirement is > not so strict; I just picked a simpler description for the comment. The > self-test performed by current versions of JtR makes sure that things > don't go wrong - if there are overflows, JtR will refuse to generate > charset files rather than generate them incorrectly. Note compiling warnings: charset.c: In function `charset_filter_plaintexts': charset.c:46: warning: comparison is always false due to limited range of data t ype 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. Similar output is when I use the custom generated chr file. Thanks -Radim --------- 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 sum -r/size 10978/112 -- 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