[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 23 Sep 2014 01:01:07 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Workaround for option flags shortage
On 2014-09-22 11:14, Solar Designer wrote:
> On Mon, Sep 22, 2014 at 12:42:13AM +0200, magnum wrote:
>> Unless you have a better idea, I plan the following workaround:
>> For options that require an argument, add some trivial logic in getopt.c
>> (or whatever is proper) that verifies the argument was not already set.
>> If it was, handle it as a dupe option.
>>
>> This means simple options like
>>
>> {"mkpc", FLG_MKPC, FLG_MKPC, 0, OPT_REQ_PARAM,
>> "%u", &options.force_maxkeys},
>>
>> can be just
>>
>> {"mkpc", FLG_NONE, 0, 0, OPT_REQ_PARAM,
>> "%u", &options.force_maxkeys},
>>
>> and get the same protection without need of its own flag. I think this
>> will work just fine, and it would free up several handfulls of flags.
>>
>> For future support for eg. multiple rules or wordlists, like "-wo:1.txt
>> -wo:2.txt", I suppose we should make this new logic active only for the
>> FLG_NONE case. Other than that, I see no caveats. But I haven't actually
>> looked at the code yet.
>
> Your suggested workaround sounds fine to me.
I had the idea I could just verify that the buffer pointer was NULL but
that was not the case when a 'format' was used with sscanf(). So I ended
up adding a flag to the opt_entry struct. This made for a trivial patch
that should hopefully not fail or cause any problems (yeah famous last
words).
https://github.com/magnumripper/JohnTheRipper/commit/0b5ce0d
After the above commit, another one uses this logic to free 15 option
flags in the high/jumbo 32 bits. Pretty good ROI for effectively 2-3
lines of code :-)
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.
