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 18.104.22.168 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-22.214.171.124-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 a > > modification to Samba to assist with this effort. > >  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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ