Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 9 Sep 2006 11:10:48 +0400
From: Solar Designer <>
Subject: Re:  Re: "Extra" in incremental mode not fully working


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

File = $JOHN/new.chr
MinLen = 0
MaxLen = 5
Extra = ...

where the Extra line was taken verbatim from your

> begin 644
> 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:


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>
GPG key ID: 5B341F15  fp: B3FB 63F4 D7A3 BCCC 6F6E  FC55 A2FC 027C 5B34 1F15 - bringing security into open computing environments

Was I helpful?  Please give your feedback here:

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:

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