[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120418202732.GA26290@debian>
Date: Thu, 19 Apr 2012 00:27:32 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: automation equipped working place of hash cracker,
proposal
On Mon, Apr 16, 2012 at 10:52:30AM +0200, Simon Marechal wrote:
> On 15/04/2012 23:03, Aleksey Cherepanov wrote:
> > dispatches client. So my question was about how server works: does it have two
> > separate parts to dispatch commands remotely and to convert hi-level tasks
> > into John commands for other part? Is automatic pattern searcher built on top
> > of dispatcher? Or does it have integrated dispatcher (not usable by other
> > means)? I thought not pattern search vs. abstract "cracking device" but abstract
>
> If I was to design this, I would do it that way :
> * the server converts high level demands into low level job units
> * the server has at least a network API, and possibly a web interface
> * the server handles dispatching
I think the easiest way to split cracking task into parts for distribution is
to split candidates list, to granulate it: we run our underlying attack
command with '--stdout', split it into some packs and distribute that packs to
nodes that will just use packs as wordlists. Pros: it is easy to implement, it
is flexible and upgradabl, it supports modes that we don't want run to the end
like incremental mode, all attacks could paralleled as such (if I am not
wrong). Cons: it seems to be suboptimal, it does not scale well (candidates
generation could become bottleneck, though it could distributed too), while it
would be easy to implement recheck for results for untrusted nodes (contest
environment) it would hard to hide sensitive data from them (real life), also
it does not respect work that is already done (by other distribution
projects).
That seems to be a good first step. But I am not sure that to develop totally
my own system for distribution could provide something better than a robust
fallback. I am curious why there are no popular, canonical distribution
system.
> Everything else is a client. Less code in the server will not hurt. You
> need :
> * an admin client, to control the server
> * a client for every cracking program, that will fetch job units and
> convert them to actual commands
> * any kind of bot that will analyze cracking results and submit some
> more work
>
> The dispatcher could be external to the server. This is IMO the most
> important part, as it is central and hard to get right the first time. I
> wrote one such system (that I tried to use during one of the contests),
> and while it seemed awesome in the office, it failed when used to
> schedule hundreds of cores on the Internet.
>
> All the other parts, particularly the "smart" part with pattern
> searching and stuff like that, need a strong infrastructure to be more
> than disposable scripts that will just be used during the challenge.
> OTOH, "disposable scripts" are more or less needed to experiment and
> validate ideas.
I see full server as following parts integrated together in a chain:
distribution server,
dispatcher,
system to design attacks by humans (collaborative part),
bot to autodesign attacks and to push them into the system above for check by
humans.
Regards,
Aleksey Cherepanov
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.
