john-users - Re: External filter question

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201109130011.51005.pfernandez@13t.org>
Date: Tue, 13 Sep 2011 00:11:50 +0200
From: Pablo Fernandez <pfernandez@....org>
To: john-users@...ts.openwall.com
Subject: Re: External filter question

Hi,

> > Actually, I have been making myself some numbers, and it turns out to be
> > better than Parallel, given the same conditions: jobs will have a limited
> > duration.
> Yes, but it works this way only for the very first batch of jobs.  Once
> your nodes are done with those first 10k passwords, if you want to test
> the next 10k, you incur 145k skips for those, or 190k total.

Indeed, my assumption is that you need to stop after 10k passwords (and then 
recover a session) in any case, either Parallel or Block. If you don't know 
when to stop, and you don't care about recovering sessions, Parallel is a 
better option.

> Yes, you may get past the non-I/O buffering by testing extra passwords.
> The minimum number of extra passwords you'd need to test varies by hash
> type and John build.  For non-OpenMP and non-GPU builds, 256 is almost
> always sufficient, and for some hash types and builds much smaller
> numbers are sufficient (sometimes even none).  (For OpenMP or GPU, it
> can be thousands.)

I did some tests, and even 512 was not enough (plain john -i with MD5 hashes).
What indeed turned out to be useful was to put:
Save = 1
in john.conf. But this practically duplicated running time (trying 9 salts, 
block size: 50000).

Does this make sense? In the documentation it seems to be only for recovering 
sessions.

> > > We might introduce a way for filter() to ask for process termination in
> > > a later version.  In fact, maybe external mode functions should also be
> > > able to ask for the status line to be displayed (simulate keypress).
> > 
> > Those two would be awesome to have! Any idea on how to do it? Maybe I
> > could do my work on a "patched" version,
> 
> You may try adding some of the event_* variables (see signals.h) to
> ext_globals (turn it into an array) in external.c.

Wow, very interesting! So, I am going to try to make event_abort global, and 
try to set it to true in the filter. Will come back with more info tomorrow 
(probably). And hopefully with a patch :)

Actually, looking through the code, I get lost in c_block. So, ext_globals is:

static struct c_ident ext_globals = {
        NULL,
        "word",
        ext_word
};

But this is passed to the compiler:
c_compile(ext_getchar, ext_rewind, &ext_globals)
And then the compiler does a c_block with it:
c_block(0, externs);

This is where I get lost, because c_block seems to operate things between 
braces and stuff like that (blocks, in c), I don't see where does the globals 
show up here.

I guess that, when you said I need to make ext_globals an array, you meant "an 
array of structs", right?

Thanks again,
Pablo

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.