[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 1 Aug 2012 12:13:49 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Output for dynamic formats in --list=format-details (and --list=format-all-details
This is very easy to fix this symptom, but I think this was done this
way for a reason, it is just so long ago, I cannot remember exactly
what side effect changing this back would do. The problem was
something like auto-detection, if the -format was not used, or in
'ability' to do something like: -test -format=dynamic, or something
I actually 'think' it was in that last (ability to use -format=dynamic
as a format type). This may have been more for historical compatibility
than anything else. If all that it was is -format=dynamic no longer
works, then I am not too concerned.
The dynamic (md5_gen) format used to be a very fat format. It had only]
a single format structure, and this structure would morph itself into
the proper structure layout, for the exact format being used. This was
pretty trivial for real cracking where only one format is 'needed'.
However, it made for MANY issues. There were problems in testing/benching,
problems with overflow detection, etc, etc, etc. It was a bad design.
The current dynamic is now interrogated by john.c, and an array of
proper format structures is returned. Each of these are 'stand alone'
in that they have all the proper data for EXACTLY that one sub type.
After writing this email, I am pretty sure that the code I will show
(prior to the commented out lines, shown here), was done, to keep some
of the older behavior, of -format=dynamic working. However, there are
several bad side effect to this. One you list Frank. Others are in the
multi-format detection. It will simply list 'dynamic' as one of the
types, vs dynamic_0. I have tested, and -test=0 -form=dynamic does not
work with the lines commented out, but does work when they are left
in. I am 95% sure this 'is' the reason it was done this way. However,
the side effects outweigh the benefit of allowing 'dynamic' as a format
type, to mean 'all' dynamic types. We could probably still get that
behavior, by making changes elsewhere, but I am not sure that is of
as much usefulness as it was when I was developing dynamic. Initially,
I think you could only test dynamic (md5_gen), as a whole. I do not think
testing of a single format was possible, until the formats were split up
into their own structures (but my memory of this may not be correct).
Well, here is the change. As for jumbo-7, I would vote to NOT put this
in there. Let's make SURE there are not other bad side effects before
we add this to a 'normal' release.
Within dynamic_fmt.c, in the LoadOneFormat() function, these lines get
commented out:
/* we 'have' to take the sig from the test array. If we do not have
*/
/* our preload array 'solid', then the idx will not be the proper */
/* number. So we simply grab the label from the test cyphertext
string */
strncpy(label, pFmt->params.tests[0].ciphertext, 15);
cp = strchr(&label[1], '$');
cp[1] = 0;
strcpy(label_id, &label[1]);
cp = strchr(label_id, '$');
*cp = 0;
// if (!options.format || strncmp(options.format, "dynamic_", 8))
// pFmt->params.label = str_alloc_copy("dynamic");
// else
pFmt->params.label = str_alloc_copy(label_id);
strcpy(curdat.dynamic_WHICH_TYPE_SIG, label);
curdat.dynamic_HASH_OFFSET = strlen(label);
Jim.
>From: Frank Dittrich [mailto:frank_dittrich@...mail.com]
>
>Currently, format label is always printed as "dynamic".
>Should this be changed to "dynamic_N", where N is the dynamic format
>number.
>
>I think this would be better, but I wanted to ask what others think.
>If we change this, should this be changed for 1.7.9-jumbo-6-fixes as
>well?
>
>I posted this to john-dev instead of john-users, because I think most
>users don't care, but people developing scripts of other software using
>john's output do care.
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.
