[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <025301cbd5d9$bcf9fb30$36edf190$@net>
Date: Sat, 26 Feb 2011 11:22:26 -0600
From: "jfoug" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: RE: md5_gen(0) broken for ages?
This is actually a very good suggestion, and I 'think' it will be pretty
easy to do.
I will handle this much like is done in a 'thin' client. Where in the
valid() function
in md5-gen, it will fixup the hash, by adding the md5_gen(#) if it is
running in
this specific mode.
There are several caveats (and I have not yet dug into any unintended
consequences).
1. This will ONLY be used, if you fully specify the md5-gen format and a
subformat.
2. This will likely only work for non-salted hashes, due to how md5_gen
requires the salt to be placed.
3. There 'could' be hashes not checked, because they are in the john.pot
file, and are things like 1/2 of an LM, etc. Also when getting into
multi-pass MD5, there may be cases where there are some hashes not checked,
due to situations like this. This 'should' be a pretty rare case. This is
due to the subformat now picking up hashes out of john.pot that are NOT of
the proper format. This is already seen today, where a .pot file with LM
and a .pot file with 'raw-md5' will use each other's cracked hashes as their
own, and not test them.
4. Any found hashes will be stored in the john.pot file as the raw hex
number. They will not list that the found format was md5_gen(0), or
whatever subformat found it. This is because john 'owns' the hash string.
All that I am doing in md5-gen is fixing up a local string, so that that it
will load properly.
The salted hashes have been laid out in a specific way (salt appended to end
preceded by a $ char, and 2nd salt, pretended to that preceded by a $$2
signature). Thus, simply appending md5_gen(12) to the front, will likely
NOT get it into a 'valid' format. Also, I will not be able to add code to
try to 'find' the salt. There simply is no way. It may be the first 8
characters, the last 8, the last 16, have a $1$ signature, then 8 chars,
then a $. There simply is no 'generic' way to auto load salted hashes that
are in 'native' format.
However, even with the above caveats (and likely more), I do think this is a
valid change, and I was surprised that it really was not that hard. Note, I
do not have it fully working yet, but do have the 'valid' function working.
I will have to make a few additional changes, but I do believe this is a
doable function.
Thus, -format=raw-md5 or -format=md5-gen -subf=md5_gen(0) 'should' be
able to work over the same raw hash file, using the same pot file.
Jim.
-----Original Message-----
From: magnum [mailto:rawsmooth@...dband.net]
Sent: Saturday, February 26, 2011 4:59 AM
To: john-users@...ts.openwall.com
Subject: Re: [john-users] md5_gen(0) broken for ages?
On 02/26/2011 02:20 AM, jfoug wrote:
> It is no different than taking a line like
>
> User:abcdef0123456789abcdef0123456789
>
> And calling john with john -format=md5a inputfile.in
>
> and expecting the above line in the input file to be 'used'.
> It will not be used, because md5a has a specific format, and
> That hash does not match it. If a hash does not start with the
> $1$ when md5a will never choose that line. Same for md5_gen(0)
OK, that makes sense. But there is a difference: You will never find
hashes "in the wild" prepended with md5gen(n).
Sometimes you have to guess format just based on hash length and hope
that a weak password will reveal what it is. Unless you can iterate over
the --subformat option, you have to modify the hash file for each try.
So let me re-phrase it as a low-prio enhancement request. Would it be
possible to have it accept bare hashes [of correct length etc] if
--subformat was given, or could this introduce other problems?
thanks
magnum
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.
