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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ