Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 19 Jan 2006 22:09:07 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Custom .chr files w/o .pot

On Wed, Jan 18, 2006 at 02:36:54PM -0600, Mark Shaw wrote:
> Is it possible to create a custom .chr file without first having any
> cracked passwords?

As others have explained, yes, you can generate a fake john.pot file
from a wordlist by prefixing each word with a colon.

> For a rather involved reason, I'm trying to crack my own password.
> I know the length, and some characters that are defnitely present,
> and some that are definitely not.  I'd like to exploit this knowledge
> to run an incremental crack using a reduced character set.

Invoke these commands:

	echo :your_possible_password > john.pot
	john --make-charset=custom.chr

Then in john.conf define:

	[Incremental:Custom]
	File = custom.chr
	MinLen = 1
	MaxLen = 8
	Extra = any_other_characters_to_try

That is, use "Extra" if there are any other characters which you think
might be present, but which are not already a part of the string which
you had entered into john.pot.  Alternatively, for even better results,
you can enter multiple guesses to your password into the fake john.pot.

> Alternately, can I just use all.chr and somehow tell john not to
> use certain characters?

You can define an external filter() and use that along with all.chr,
filtering out candidate passwords which you know won't match yours.
Unfortunately, this is not very efficient since all of those candidate
passwords would be generated anyway, then filtered out.  You only save
on the actual hashing, replacing it with some filtering.

> Would this have any real effect on run time?

When running against just one salt, you might not save a lot of
processing time with the filtering I've explained above.  In fact, the
reported c/s rate will be lower because only those candidate passwords
which are actually hashed are accounted for when calculating the rate.

You're going to have better luck with a custom .chr file.

The wordlist rules abuse trick that Radim has suggested would work, too,
but you need to be careful to not create too many rules with
preprocessor commands.  With too many (e.g., millions) of wordlist rules
(after preprocessor expansion), John startup might be too slow as the
expanded rules are checked for valid syntax.

Another alternative is to specify a new external mode which would only
generate the desired candidate passwords.

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments

Was I helpful?  Please give your feedback here: http://rate.affero.net/solar

Powered by blists - more mailing lists

Your e-mail address:

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