[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1181319944.10021.91.camel@localhost>
Date: Fri, 08 Jun 2007 11:25:44 -0500
From: jmk <jmk@...fus.net>
To: john-users@...ts.openwall.com
Subject: Re: LM/NTLMv1 challenge/response cracking
On Wed, 2007-06-06 at 20:12 +0400, Solar Designer wrote:
> Joe - please consider the BENCHMARK_LENGTH and mdfour() changes for your
> patch. Also, I think that it would help to have comments at the start
> of both *_fmt.c files explaining the expected input file format and/or
> providing references to tools that can be used to dump C/R exchanges in
> a supported format.
I've made the BENCHMARK_LENGTH and mdfour() modifications to the 1.7.0.2
version of the patch. I've also added a few notes regarding the
challenge/response file format and the gathering of such pairs. Let me
know if you had something else in mind. The patches are posted here:
http://www.foofus.net/jmk/tools/jtr/john-1.7.0.2-netlm-netntlm-jmk-3.diff
http://www.foofus.net/jmk/tools/jtr/john-1.7.2-all-6-netlm-netntlm-jmk-1.diff
> Some questions, just out of curiosity (and in case it helps someone
> browsing the archives):
>
> > * Capture the LM/NTLM challenge/response exchange. I've posted[1] a
> > modification to Samba to assist with this effort.
> > [1] http://www.foofus.net/jmk/smbchallenge.html
> >
> > * Use RainbowCrack to lookup first 7 characters of the password using
> > the LM response hash (half LM response tables).
> >
> > * Use JtR to crack the remaining characters.
>
> Is there a reason to not generate and use rainbow tables for this step
> as well? I don't immediately see one. The key for second block of
> responses crosses DES block boundary in LM hashes, but that shouldn't be
> a problem (just a bit more computation to do when building the tables).
> It is entirely possible that I am missing something as I haven't looked
> into this before.
The quick answer is that I'm using this "half" approach because those
are the tables we have access to. The "Free Rainbow Tables" guys built
them and that's where we acquired them from.
http://freerainbowtables.com/index-rainbowtables-tables-halflmchall.html
We are internally working on building NTLM response tables.
Unfortunately, finding enough machines and available CPU time is tricky.
Once we have those complete and we have available resources, we may
tackle the full LM response.
With respect to the Rainbow Tables, I'm not really sure how much benefit
there is to using this "half" method rather than just computing the full
response tables. IIRC, the half method only generates 8 bytes of the 24
byte LM response. This reduces the number of DES encryptions necessary
during table computation and maybe the final table size. However, the
DES encryption to generate the first 8 bytes of the response uses only 7
of the 8 bytes of the first half of the LM hash. I would think that if
we ignore that final byte that it would leave (2^8) possible passwords
which could match those first 7 bytes. Maybe because of the other LM
limitations (upper-casing, character space, etc.) this number is
drastically smaller... The tables seem to work just fine, though, so my
understanding of this is probably just wrong.
Joe
--
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.
