Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 28 Sep 2014 12:10:41 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Restart work on mask mode

On 2014-09-28 05:31, Sayantan Datta wrote:
> I think we should follow the external mode technique with this one. In all
> modes incremental or wordlist  we should have:
>
> if (do_mask_crack(word))
>    if (external_filter(word)) // not executed when mask is active
>        crk_process_key(); // not executed when mask is active

But then we could have this for a tad extra functionality with nearly 
the same performace:

if (external_filter(word)) // might discard or alter word
     if (do_mask_crack(word))
         crk_process_key(); // not executed when mask is active


> The do_mask_crack() will return null when a mask is active and call
> crk_process_key() from within. This process necessitates splitting mask
> mode into three separate functions:
> init_mask(char *mask, db_main *db) - initialize mask
> do_ mask_crack() - generates the keys and calls external_filter() and
> crk_process_keys().
> exit_mask() - for cleanup.
>
> The init_mask() and exit_mask() function should be called during entry(just
> after initializing db_main, preferably after initializing a format because
> we might need some input from the format parameters as well for GPU
> cracking.) and exit from john respectively.
> When only mask mode is working, the do_mask_crack() would be used as usual
> with a NULL in the argument. However when other modes are active,
> do_mask_crack() is called within those modes.

Yeah this sounds reasonable. I'd still like Solar to comment, because he 
often has excellent ideas.

I see now why all modes don't just call crk_process_key() and 
filter/mask magic happens inside it. By looking at the f_filter variable 
we get rid of the external function call unless needed (see ext_filter 
macro in external.h). Mask mode should use a similar approach.

magnum


Powered by blists - more mailing lists

Your e-mail address:

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