Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 29 Aug 2006 12:45:40 +0000 (UTC)
From:  Radim <>
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.

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

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.


begin 644
sum -r/size 10978/112

To unsubscribe, e-mail and reply
to the automated confirmation request that will be sent to you.

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.