Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Sep 2009 07:52:31 -0500
From: "JimF" <>
To: <>
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 

>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 

For your commerce mode, you have this format listed:


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:


for the 2 lines above.  But the output in john.pot would still end up being:


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.


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.