[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <00d901cd1fd1$65982c70$30c88550$@net>
Date: Sat, 21 Apr 2012 10:14:06 -0500
From: "jfoug" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: RE: Re: Extract the cracked pass from John.pot
>-----Original Message-----
>From: Frank Dittrich [mailto:frank_dittrich@...mail.com]
>
>On 04/20/2012 11:39 PM, donovan wrote:
>> & find an lot of :
>>
>> ( so the "hashes" come into the file )
>>
>> *************
>>
>> md5_gen(7)17c8dddfbf16fe4b14b1a8b368ad3977$8-4;undertaker01160
>> md5_gen(7)f0398de8070bd35c8b4ebeccdef6e2d3$#>G;blue123ocean456
>> md5_gen(7)d141c417ae1e12c9b4816870b94b6f47$&l5;onceuponaforest
>> md5_gen(7)a023c92847d791488fb2179ace167dea$voc;mahalnamahalkita
>> md5_gen(7)e6eefdbb86b77aefc18029d17493140f$~S=;franciscoalejandro
>>
>> .....
>>
>> ************
>>
>> So seem that one's escape to the pasted CMD.
>
>For some reason you do have lines in your pot file where a semicolon
>instead of a colon separated the hash and the password.
>May be you invoked john with --sep=";"
This brings up a point, on the 'proper' usage of JtR, that I would like to
continue forward with. The -sep=X (and dynamic_7/md5_gen(7) ) were put into
place, due to any colon ( : ) char located in the salt (or anywhere else)
being a REAL problem within JtR, since the colon. There are several hashes
which salt 95 chars (from space to ~ chars, i.e. the same as JtR's inc-all).
Since that time, I have added the $HEX$ flag within the salt field. Thus, a
user can easily (well relatively easily) encode the salt's within his input
file in the $HEX$ format, and totally avoid any file IO problems with john.
It really would only require $HEX$ if a salt contains a ':' char, and other
'bad' character ($ can be bad, NULL certainly is bad, as is carriage return
or line feed).
Thus, I would strongly recommend, to NOT use dynamic_7 (with the -sep=) or
use the -sep=X flag at all any more. Yes, it works, but there are better
ways to proceed. Dynamic_7 and dynamic_6 are exactly the same, except
dynamic_7 FORCES you to use the -sep= (dyna 7 may be forced at 3 byte salt
also, where 6 is not limited).
The $HEX$ format is only part of the dynamic_X formats, but it allows this
very variable format to handle salts which normal JtR would not properly
handle. It may require some pre-processing of the hashes, to get the ones
that need to be HEX'd into the format, but once that is done, JtR should
find the password just fine.
Symptoms of this problem would be if you knew you had 1000 'proper' hashes,
and they are salted 'dynamic' hashes, but when running JtR, it says it can
only find 963 of them. The other 27 hashes were not found because JtR cut
the salt. A worse symptom would be a salted format, that did not have a
specific 'length' salt (dynamic format). In that case, JtR may tell you
that all 1000 were loaded, but if there were 27 with ':' chars in them, the
salts would be broken (short), and JtR would never find a password for them,
EVEN if the password was something simple like 12345. Converting to $HEX$
within the salt will eliminate any problems like this.
Jim.
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.
