Date: Tue, 9 Jan 2007 13:15:30 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: pwdump2 and JtR - problem with syntax in running JtR and displaying passwords On Tue, Jan 02, 2007 at 11:06:39PM -0800, Hviti/Spaki wrote: > I'm having problems using pwdump2 and JtR on an account with admin rights on a WinXP computer and would appreciate it if anyone could help. Chris McGinley has pointed out the primary problem already, except that he did not mention that you need an unofficial build of JtR. > saw a list like - > Admin:500:aad3b435b...:12ed...::: > Account:1010:aad3b435...:d76...::: The strings "aad3b435b..." correspond to LM hashes of empty passwords. Most likely the actual passwords are not in fact empty, but your system is configured to not use LM hashes. The strings "12ed..." and others in the fourth field must be NTLM (MD4-based) hashes of the actual passwords. These are not officially supported by JtR yet, but they are supported with contributed patches. You may, for example, use the "1.7 + jumbo patch build for Win32" from the "contributed resources" list on the JtR homepage. You need to pass it the "--format=nt" option in order to have it crack your NTLM rather than the LM hashes. I will also point out some other (minor) issues: > at C:\john1701\run> typed in "john-386.exe passwords.txt" The john-386.exe executable is for truly ancient computers (10+ years old). You should have been using john-mmx.exe instead (but that would not make a difference in your case). > saw a list like- > Loaded 8 password hashes with no different salts (NT LM DES [32/32 BS]) > <Admin> > <Account> > guesses: 8 time: 0:00:00:00:00 100% (2) c/s 1127K trying 12345 - MUSTANG Here we see that JtR has correctly cracked the empty passwords for the LM hashes. > Since this didn't display any passwords, I tried deleting > the files and starting over again, but after: > > went back to the command prompt and typed in "cd C:\john1701\run" > at C:\john1701\run> typed in "john-386.exe -i:all passwords.txt" Using "-i:all" with LM hashes is non-optimal. This results in the warning messages that you've quoted below: > and got- > Loaded 1 password hash (NT LM DES [32/32 BS]) > Warning: MaxLen = 8 is too large for the current hash type, reduced to 7 > Warning: mixed-case charset, but the current hash type is case-insensitive; > some candidate passwords may be unnecessarily tried more than once. > <Admin> > guesses: 1 time: 0:00:00:00:00 c/s 3276 trying: 2100 - SPACY This is also the correct behavior given your password file and the command line syntax above. The reason why it only loaded 1 password hash this time is that you've restricted it to "incremental mode" only, which did not require loading of duplicate hashes (the empty password hashes are all the same, but they were getting loaded with default option-less JtR invocations anyway for a subtle reason that's been discussed on this mailing list before). > I then tried repeating the process with: > "john-386.exe -i passwords.txt" That's a little bit better - you're not forcing JtR to use all.chr (which is unoptimal for LM hashes), so you do not get the warnings. I'm not sure why you want to be restricting it to "incremental mode", though. There's probably no valid reason for that. I hope this helps, and sorry for the delayed response. -- 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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ