[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTinUuqP7ppm=1z9PFfP82Y2S-XGX5fJcxz7Pinfi@mail.gmail.com>
Date: Fri, 10 Sep 2010 12:47:02 -0400
From: Charles Weir <cweir@...edu>
To: john-users@...ts.openwall.com
Subject: Re: Attacking Windows-ALT chars in LM Hashes
Hey thanks Solar! I have a couple more comments inline:
> Here's a relevant thread with some hash samples that I found when
> LM-hashing single 8-bit character strings with Perl's
> Authen::Passphrase::LANManager and Googling for the resulting hashes:
>
> http://www.freerainbowtables.com/phpBB3/topic387-120.html
Wow, that thread was exactly what I was looking for. I'm still digging
through it and I need to run some sanity tests myself, but it implies
that we can really speed up Dumbforce mode against LM hashes, (at
least when CodePage 437 - the default one for English - is used). It
also seems to imply that the current Dumbforce mode might miss several
password hashes. That is because some of the characters are mapped
back to control characters when they are run through the LM hashing
algorithm. For example, the character with the value 149 is mapped
back to 7, (which is the ASCII value for a BELL). Think of it like how
lowercase characters are mapped to uppercase charactes. At the same
time, since many of the upper value characters are mapped to other
values, we can safely skip them, (once again I'm only tallking about
CP 437).
> This was requested before and it is on my to-do list. Your request for
> this feature has just raised its priority.
Hey thanks! It's a pretty rare issue to be dealing with so there's no
real hurry. I'm probably just going to write an external program to do
that and just pipe the results into JtR. The -stdin option is still
the best feature I've seen in any password cracking program, and is
one of the main reasons I use JtR.
>> Also, if they are using a different
>> codepage encoding, (instead of using ALT characters), that opens up a
>> whole new can of worms.
>
> If you try the entire 8-bit range rather than individual characters, it
> probably does not. If the non-ASCII characters are getting converted to
> uppercase, then this is likely affected by the current codepage, though.
I agree, if you search through the entire 8-bit range it doesn't
matter. It looks like any optimizations though will
be highly dependend on the codepage being attacked.
> Here you are:
>
> http://dir.gmane.org/gmane.comp.security.openwall.john.user
> http://marc.info/?l=john-users
>
> These are linked from the JtR homepage.
>
Dough, didn't see that, and thanks once again!
Matt
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.
