Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 4 Mar 2008 09:31:31 +0300
From: Solar Designer <>
Subject: Re: Password to guess with a lot of information

On Mon, Mar 03, 2008 at 02:13:43PM +0100, L B wrote:
>  - the password is 9 letters long
>  - the password has 7 letters alphanum and 2 digit at the end
> I modified params.h to support 9 characters and recompiled john.
> I defined a new "profile" in john.conf :
> [Incremental:myinc]
> File = /tmp/john/run/alnum.chr
> MinLen = 9
> MaxLen = 9
> CharCount = 36
> I wanted to use the alnum.chr charset but it doesn't look valid anymore to
> john (because of the 9 digits stuff ?) : Incompatible charset file:
> /tmp/john/alnum.chr

Correct.  You need to generate a new .chr file after the recompile.

> I tried to --make-charset but I don't understand which kind of source files
> it wants (I just want alpha+num!)

It does not require any input files other than your john.pot.  If you
do not already have a large number of cracked passwords in your john.pot
(preferably of length 9), then you may use a fake john.pot based on a
wordlist to generate your .chr file.  You may also reuse some
information from an existing .chr file by having JtR generate many
candidate passwords based on the .chr file and saving them into the fake
john.pot (this won't work very well in your specific case because none
of the .chr files supplied with JtR will produce 9-character strings).
Some examples of these approaches can be found on these older postings:

> How can I do to find this password ? By defining rules ?

Probably not.

Use a custom "incremental" mode and/or an external mode.  Yes, it may
make sense to use a combination of both modes, in one of two ways:

1. Define a 9-character alpha-numeric "incremental" mode (requires a JtR
recompile and a custom .chr file).  Define an external filter() that
will only let candidate passwords ending in two digits pass.  That is,
when the "word" is unsuitable, set "word = 0".  Use both modes at once.

2. Define and use "incremental" for the first 7 characters (does not
require a recompile, nor a custom .chr file).  Define and use an
external filter() that will modify "word" by adding two digits to it.
You'd have to do up to 100 invocations of JtR with different filter()
functions - separately for each two-digit combination.

Obviously, the second way is much more efficient in terms of the c/s
rate.  As a bonus, you get a very efficient way to distribute the work
across up to 100 CPU cores in any number of machines.

For a pure external mode solution, that is not as good as "incremental"
mode in terms of the order in which candidate passwords are tried, you
may use a variation of the "DumbForce" mode seen on this recent posting:

You'd need to enhance it to use different character sets for different
character positions.

> I guess with the information I have it should be quite quick.

It is perfectly realistic to crack that password, but I would not expect
it to necessarily be very quick.

Good luck!

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

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

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.