Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 Nov 2011 14:24:10 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: md5_gen tagging

This has now been changed in patch 0037.  This was not a trivial change.  Quite a bit had to be addressed.

The new functionality, a format like raw-md5 (or dynamic_0) will detect any of these 'forms'

$dynamic_0$HEX_32
HEX_32
md5_gen(0)HEX_32

It will use any of those forms as input, .pot file data, etc.   Also, either format (raw-md5 or dynamic_0) will output $dynamic_0$HEX_32 to the john.pot file (for newly found items).


Note, there 'are' some side effects.

1. I had to re-order linkage of dynamic formats, ahead of any that use them (i.e. the #include was put after the dynamic linkage).
2. More input files will list 'multiple' possible format warning.   Any input file with $dynamic_0$  $dynamic_6$  $dynamic_9$ $dynamic_17$  $dynamic_29$ will all list multiple formats, if no specific -format=XX line was used.  This is due to the thin format, AND the dynamic format matching.
3. The thin formats required some changes, and some additional logic.  Now, any format that has a 'more complex' line, than a straight hash, will have to have a split function added.  This split is really thin.  It simply calls the 'convert', and then calls the split function of dynamic (similar to C++ inheritance, which is how the 'thin' format has been modeled)

This has been tested with the test suite.  That helped flush out a lot of issues, that showed up, due to the changes.  A lot of the problems were due to some global stuff in the dynamic format, AND the changes to john to 'show' the multiple/ambiguous formats which could also handle the input file.

Jim.

>-----Original Message-----
>From: magnum [mailto:john.magnum@...hmail.com]
>Sent: Monday, October 24, 2011 5:22 PM
>To: john-dev@...ts.openwall.com
>Subject: [john-dev] md5_gen tagging
>
>JimF (or anyone with a thought),
>
>I can't remember this having been discussed: NT hashes can be bare or
>tagged (or a mix) in input files, but they are stored *with* a tag in
>john.pot regardless, and non-NT hashes in john.pot will never be used
>when loading NT hashes.
>
>But md5_gen/dynamic hashes are not stored with the tag unless the tag
>were there in the input file. Maybe this is because at some point in
>time, the tag was always needed in the input file?
>
>I really think the md5_gen/dynamic format should be changed, so it
>always writes the tag to the pot file. For backwards compatibility, it
>would need to keep supporting (old) bare hashes in the pot file - but
>that could (imho should) be an option in john.conf.
>
>Wouldn't this be a pretty trivial fix in split()? Or is it complicated
>by the multi personality of the format? If so, I suppose at least all
>thin formats (eg. raw-md5 and raw-md5u) could do this on their own. But
>I haven't tried it yet.
>
>magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ