[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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<@T*36EN3&5N(#T@,`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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
