[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 Apr 2012 10:52:30 +0200
From: Simon Marechal <simon@...quise.net>
To: john-users@...ts.openwall.com
Subject: Re: automation equipped working place of hash cracker,
proposal
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
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.
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.
