[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20071215051145.GA28892@openwall.com>
Date: Sat, 15 Dec 2007 08:11:45 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: hash from pwdump and external functions
On Fri, Dec 14, 2007 at 04:41:44PM +0100, madfran wrote:
> I donwload a hash from a Windows 2000 target using pwdump6.
> The first half of the password it will cracked using LC5.
Chances are that JtR with default settings would crack it a bit quicker.
> I wonder in the second half are some special character and I try to use
> the external functions of John.
...
> [List.External:prepend-pims]
> void init()
> {
> int i;
You aren't using that variable in init().
> word[0] = 'A';
> word[1] = '%';
> word[2] = 'D';
> word[3] = 'M';
> word[4] = 'I';
> word[5] = 'N';
> word[6] = '7';
The above sets the known password half. It would make sense, except
that JtR cracks the LM hash halves separately - so you do not need to
provide the first half at all when you're after the second one.
For the same reason, you don't need to go for lengths beyond 7.
> word[7] = 'I';
Why, do you happen to know that the 8th character is 'I'? Even if so,
you'd need to put it in word[0], not word[7].
> word[8] = 0x20;
> word[9] = 0x20 - 1;
> word[10] = 0x20 - 2;
> word[11] = 0x20 - 3;
> word[12] = 0x20 - 4;
> word[13] = 0x20 - 5;
Those "- 1" through "- 5" make no sense. Yes, I had a similar "- 1" in
one of the external modes, but there the "- 1" was to compensate for the
increment of the last character that generate() performs. So you would
need something like:
word[8] = 0x20;
word[9] = 0x20;
word[10] = 0x20;
word[11] = 0x20;
word[12] = 0x20;
word[13] = 0x20 - 1;
Also, you need to NUL-terminate word[], which in your example would be:
word[14] = 0;
although, as explained above, you don't need to be testing passwords
this long.
> void generate()
> {
> int i;
> i = 13;
> while (++word[i] > 0xff)
> if (i > 8)
> word[i--] = 0x20;
> else {
> word=0;
> return;
> }
> }
This comes from the "8bit" mode I had posted previously, but you've made
it work for the last 6 characters of your 14-character password only.
Well, you did not need to do that because the LM hash halves are cracked
separately.
Also, do you somehow happen to know that the second half is exactly 7
characters long and starts with 'I'?
And do you realize that it'd take 2.5 months on average (5 months worst
case) to brute-force those 6 characters from the large set of 224 on a
typical modern CPU doing 10 million LM hashes a second?
It is possible to enhance the code to skip either the lowercase or the
uppercase letters because LM hashes are not case-sensitive with respect
to input passwords. Then the number of characters gets reduced to 198
and the run times to 35 days average and 70 days worst case.
> but when I launch,
> john -session=pims -format=NT -e=prepend-pims hash-pims.txt
> the output if,
> "No password hashes loaded"
You have an LM hash, not an NTLM one. You're lucky that the above
refuses to run for you rather than wastes your time.
The external mode that you have coded (or rather, mixed) would match
NTLM hashes better, though - since they are full length and not split.
But then you wouldn't be able to take advantage of LM hashes being
case-insensitive.
> if I launch,
> john -session=pims-NTLM -e=prepend-pims hash-pims.txt
> the output is
> Loaded 1 password hash (NT LM DES [128/128 BS SSE2])
> guesses: 0 time: 0:00:00:03 c/s: 9502K trying: A%DMIN7 - A%DMIN7
>
> ,... it seem they are not able to see the second half.
This is correct. JtR never tries candidate passwords of longer than 7
characters against LM hashes - because it does not need to. Perhaps
your first half is already in your john.pot, so it is cracking the
second half only here.
> if I launch,
> john -session=pims-NTLM -format=mscash -e=prepend-pims hash-pims.txt
> the output is
> Loaded 1 password hash (M$ Cache Hash [Generic 1x])
> guesses: 0 time: 26:22:05:42 c/s: 2681K trying: A%DMIN7I+,UqO╛ - A%DMIN7I+,UqO√
>
> It try the whole password but the format it is mot mscash !!!
Yes, you have wasted a day here.
> administrator:8ED0A046696658941180BC49698B0D39
Looks like a fine LM hash, and the first half matches what you wrote it
is. My advice is that you start by letting JtR with its default
settings attack this hash. Just run:
john hash-pims.txt
with no options at all, and let it run until it terminates (maybe in
around 10 days worst case - if it fails to crack the hash). Only after
that would it make sense for you to go trying special characters.
Since you've posted this example to the list already, please keep the
list aware of your results (such as whether my suggestion worked or not -
and how long it has taken).
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
Was I helpful? Please give your feedback here: http://rate.affero.net/solar
--
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com 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.
