|
Message-ID: <f5e387686daa4186b0581a3d658556ea@smtp.hushmail.com> 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.