Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110912071847.GA1416@openwall.com>
Date: Mon, 12 Sep 2011 11:18:47 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: External filter question

On Sun, Sep 11, 2011 at 09:27:33PM +0200, Pablo Fernandez wrote:
> I am trying to define an external filter that works with any other mode (like 
> incremental) that simply defines where to start and where to stop. This will 
> basically be a filter that creates a "block" in the password-space (for 
> distributed processing)

This sounds even worse than the [List.External:Parallel] sample, which
is pretty bad on its own.  I recommend that you consider other approaches:

http://openwall.info/wiki/john/parallelization

Is your reason to go for "blocks" instead of having each node try every
Nth password (like [List.External:Parallel] does) to be able to retry
skipped/failed blocks from a master node, and to adjust the number of
nodes on the fly?  If so, this makes sense.  But having each node skip
to its starting password number each time it's invoked on a relatively
small block is going to kill performance unless you're running against
salted and extremely slow hashes.

> So, there is no generate() on purpose, to make it compatible with the 
> incremental mode. This basically runs John between the password number 10000 
> and 11000, and at that point it forces a sw trap: divide by zero, forcing an 
> exit. This is the expected behavior.
> 
> BUT I am having problems, probably related to the way the system flushes the IO 
> buffers. This is not an "elegant" way to exit john, and it turns out that, if I 
> find a password match in the last seconds before the fault, it does not write 
> it to john.pot, hence losing it.

Worse, it will also not even find some passwords, because there's not
only I/O buffering, but also crypto algorithm related buffering in JtR.

> I would like to solve this, two questions arise:
> - Is there a more elegant way to exit John from the filter() section?

No.

> I was 
> looking at John's code and I could not find an easy way out, seems to be 
> possible only with generate().

You're correct.

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).

> - Or maybe, is there anything I can do to force John to flush the IO buffer 
> before doing the word=1/0 operation?

No, not from external mode, and it's not only about the I/O anyway.

Alexander

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.