Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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


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.