Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 13 May 2006 15:17:44 +0400
From: Solar Designer <>
Subject: Re: John seems to exit without error

On Fri, May 12, 2006 at 02:06:35PM -0700, Arvind Sood wrote:
> [sooda@...alhost run]$ ./john --format=nt
> --wordlist=../pwdfiles/lm_cracked.txt --rules --session=ntcrack_1
> ../pwdfiles/pwoutput.txt
> Loaded 13 password hashes with no different salts (NT MD4 [TridgeMD4])
> gr8hack          (Administrator)
> password         (DCuser)
> guesses: 2  time: 0:00:00:00 100%  c/s: 17666  trying: Passwording

> 1- why did john exit after cracking two passwords only? there were many more
> entries in the lm_cracked.txt file.

This suggests that you did not activate the [List.Rules:NT] section in
john.conf.  You should have renamed [List.Rules:Wordlist] to some other
name (e.g., [List.Rules:Wordlist-disabled]) and renamed [List.Rules:NT]
to [List.Rules:Wordlist].  Yes, this is a hack.  (You also need to not
forget to rename the sections back before you proceed with actual
cracking again - or you may swap entire john.conf files or you may even
use two different run directories.)

> Should john not have cracked the password set to PA55WORD! for instance?

It would report the proper case for this password with [List.Rules:NT].

> 2- Since there was nothing in the .pot file this time - why did john
> exit/finish so early?

The answer is the same as the last time - determining the case of
characters is a trivial task, even if you do in fact setup
[List.Rules:Wordlist] to be [List.Rules:NT].  It is normal for these
runs to complete almost instantly.

> 3- Does john --rules, check for only upper vs. lowercase? or even a
> combination of cases? for example if we have
> a password set as "BenTLeY" -
> will --rules try only "bentley" or "BENTLEY"
> conclude the password is neither "BENTLEY" nor "bentley" and exit
> or
> will it continue to try various combinations of cases for each character
> (Bentley, BENtley etc.)?

With [List.Rules:NT], the latter - that's why you need to use that
special ruleset for this purpose.

With the default ruleset, it will only try a few common combinations
such as "bentley", "Bentley", and "BENTLEY".  But this time you actually
want all possible case combinations tried, so use [List.Rules:NT].

> 4- I never noticed it till now, but John loads only unique hashes. I had 25
> user accounts only  13 unique passwords (hence 13 unique hashes). when
> parsing the file john loaded only the 13 unique entities .... that is so
> cool !!

This is an optimization, but it is automatically deactivated in "single
crack" mode (as well as when you don't request a specific cracking mode,
letting John use "single crack" among other modes).  The reason to
deactivate it with "single crack" is to let John derive candidate
passwords from all usernames, not just from those with unique hashes.

The optimization doesn't save as much time as it might seem to.  In
order for John to be able to not load duplicate hashes, they either have
to be not salted (like those of Windows passwords) or the salts have to
match as well.  Since John computes a hash of each candidate password
only once per salt anyway (or just once with no salts), not loading
duplicate hashes does not save any hash computations.  At best, it saves
comparisons of the computed and loaded hashes.  Those comparisons are
rather quick given that John rarely does them directly.  Instead, either
a special multi-hash matching algorithm or hash table lookups are used.

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

Was I helpful?  Please give your feedback here:

Powered by blists - more mailing lists

Your e-mail address:

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