[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Sep 2009 07:52:31 -0500
From: "JimF" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: Re: OSC_fmt patch now obsolete - will delete unless advised otherwise.
>I wrote a little format file a while ago (on wiki, called OSC_fmt) that
>attempts to crack a variant of an MD5 password that looks like:
> md5(2-byte plaintext salt + plaintext key)
> eg. md5('99' + william1) = 545471039e2daea8d6c337ee6adffcee
>
>As your contribution handles this format effectively (format 4
>md5($p.$s) ), my patch is obsolete AFAIK.
Yes is it format 4, but it is md5($s.$p) and it does handle commerce hashes
well.
>Thanks for the MD5 work too!
You are welcome. I am still working on it, speeding it up and to allow it
to handle more hashes. I am adding more primative functions, and then add
other 'base' hashes, and will get the 'expression parser' code started. I
now actually have raw-md5 working faster in the md5_gen(0) format, than it
does in the md5-raw format (for my core2 system, which does SSE2 fast).
As for the 'other' formats, I am not sure what to do about them. It might
be better to have formats some how 'call into' the generic module, thus
allowing them to continue to work with the files as they were originally
formatted.
For your commerce mode, you have this format listed:
{"$OSC$a2$14f194bdf3a1c50d61e3427d0f77544c","justin"},
{"$OSC$49$372788bad6617f2083f9c07695ee2229","eiffel"},
So, what might happen, is to simply have some way of allowing this format to
pass off the information to the generic format (to actually 'do' the work).
Thus osc could call into gen using: the format of:
md5_gen(4)14f194bdf3a1c50d61e3427d0f77544c$a2
md5_gen(4)372788bad6617f2083f9c07695ee2229$49
for the 2 lines above. But the output in john.pot would still end up being:
$OSC$a2$14f194bdf3a1c50d61e3427d0f77544c:justin
$OSC$49$372788bad6617f2083f9c07695ee2229:eiffel
just as though the osc format had handled it. So then the osc format would
become more of a validation, and filter module. It would contain no hashing
logic, but would load the data, transform it into 'proper' md5_gen() syntax,
and allow the the md5_gen_fmt code to do the hashing, and upon finding
results, would make sure that the john cracker code was informed of the
success using the original format string (in the above case, in a $OSC$
format). The md5_gen(4) could of course be called natively (with proper
formatted file), but if someone used the $OSC$ format file, it would work
just like today, they would have no idea that under the hood the osc_fmt was
not doing the hashing work.
NOTE I have not fully figured out just how to do that yet. I will start with
the phpass format first (since it was mine). I am getting code place into
md5gen_*.c files right now, so that phpass variants will be able to drop in.
Once I have that done, and working as fast as the 'native' phpass_fmt.c
code, I will then look at how to 'hook' the generic md5 format by the phpass
format. This will make useage easier, and should be a lot more robust in
the future. The md5_gen(*) code gets used as the engine for many (most) MD5
hashing instances, but we allow the existing input formats to properly
function, and the generic stuff simply gets used 'under the hood' to do the
work. Thus, when new 'enhancements' get added (such as CUDA support, or
other CPU support), it only has to be added/ported in one place, and ALL of
john's MD5 code gets the benefit.
The same model would would for SHA[1,2], DES, or other 'base' algorithms.
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.
