Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100901233903.GB5427@openwall.com>
Date: Thu, 2 Sep 2010 03:39:03 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Noob question: how to feed 10 alphanum char min&max incremental to aircrack when "MaxLen = 10 exceeds the compile-time limit of 8"

On Wed, Sep 01, 2010 at 06:52:03PM -0400, brad@...ystems.com wrote:
> I'm not sure any other CPU based program would be significantly faster
> than JTR.

I think Joshua's point was that I made it so difficult to do simple/dumb
things (e.g., shoot oneself in the foot, which sometimes even makes
sense) that coding a separate program would be easier than figuring out
how to modify params.h to go beyond length 8 with incremental mode or
how to modify the DumbForce example in john.conf to specify the desired
lengths range and charset.  I fully agree with this criticism - I got to
make doing this sort of things a lot simpler, maybe by introducing a
builtin dumb cracking mode into the very next development version.  I am
going to consider doing this when I switch back to JtR development from
many other tasks and projects that I switched to after the contest...

> Here is how quickly my program enumerates 6 - 10 (numbers only)
[...]
> real    67m6.326s

Yeah, it should be possible to do a lot faster than that, although you
haven't mentioned the number of NTLM hashes being cracked (with a truly
large number, the hash table lookups and collisions would be taking
significant time).

> I've never tried doing this with JTR, so I don't know how it would
> compare.

For a single NTLM hash and using a variation of DumbForce with:

	minlength = 6;
	maxlength = 10;

	i = 0;
	c = '0';
	while (c <= '9')
		charset[i++] = c++;

(that's in john.conf)

I am getting on a single core in a Core i7 920 (2.67 GHz, but there
might be turbo boost and on the other hand there might be other load):

owl!solar:~/john/contest/john-1.7.6-jumbo-6/run$ ./john -e=dumbforce -fo=nt -u=aabdelhamid ~/john/contest/pw-contest
Loaded 1 password hash (NT MD4 [128/128 X2 SSE2-16])
guesses: 0  time: 0:00:00:03  c/s: 14275K  trying: 45816704 - 45816735
guesses: 0  time: 0:00:00:07  c/s: 14492K  trying: 004654112 - 004654143
guesses: 0  time: 0:00:06:49  c/s: 14042K  trying: 4632509280 - 4632509311
guesses: 0  time: 0:00:09:55  c/s: 14017K  trying: 7229499904 - 7229499935
guesses: 0  time: 0:00:11:31  c/s: 14011K  trying: 8571090624 - 8571090655
guesses: 0  time: 0:00:12:31  c/s: 14010K  trying: 9411052608 - 9411052639
guesses: 0  time: 0:00:13:14  c/s: 13993K  trying: 9999999968 - 9999999999

A builtin (non-external) dumb exhaustive search mode should be a bit
faster.  Incremental mode might be faster too (but I'd need to edit
params.h, recompile, and generate a custom .chr to go past length 8).

For comparison, here's a raw hashing speed benchmark:

owl!solar:~/john/contest/john-1.7.6-jumbo-6/run$ ./john -te -fo=nt
Benchmarking: NT MD4 [128/128 X2 SSE2-16]... DONE
Raw:    25493K c/s real, 25493K c/s virtual

This benchmark uses a lower average password length, though, which might
contribute to the speed difference.

Alexander

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.