[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120527121647.GA20017@debian>
Date: Sun, 27 May 2012 16:16:47 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: UI for MJohn
On Sun, May 27, 2012 at 12:57:51AM +0200, Frank Dittrich wrote:
> On 05/23/2012 11:04 PM, Aleksey Cherepanov wrote:
> > On Wed, May 23, 2012 at 03:46:59AM +0200, Frank Dittrich wrote:
> >> So may be when specifying the attack, the user has to pick the general
> >> attack type using a drop-down list (or may be, the list of general
> >> attack types is presented as a list of radio buttons instead), then,
> >> depending on the attack type, the user has to specify other parameters:
> >> -word list file name, to be selected from a list of existing file names
> >> (we might need to provide a way to add new wordlist files)
> >
> > In johnny I did similar way to set options for john. Though rules as
> > below and other contents of configuration file are not available in
> > johnny (yet). I think such interface is not hard to implement for
> > upload. Though I do not think it is really needed because the
> > preferred way to add attack is to run john (under wrapper) for that
> > attack and wrapper will send everything itself.
>
> OK, then I misunderstood what the wrapper should do.
> I thought it would just request new tasks to be run from the server, and
> start those tasks on the client.
Wrapper will:
- send attack's description (cmd-line and files) to server when it is
invoked as regular john (this is why it is wrapper),
- request new task when it is invoked with attack's name.
- manage attacks in more interesting ways (like modification) that we
could need.
> But I think it is important for the users to be able to see the attacks
> defined by other users, and to see how good those tasks which already
> completed were, to be able to either define similar attacks for other
> hash types, or to define other attacks on the same hashes (which have
> not yet been tried, but might be successful as well).
>
> I don't see how you want to support this workflow with the wrapper.
Wrapper is not the only thing in this system. There is also server
with (web) ui where users see all attacks, could search them.
Attack's names help users to use information from web ui with wrapper
in shell.
For instance user looks into web ui, find successful attack that
covers only part of hashes (how?), copies <its name>, then goes into
shell and use this name to create new similar attack like '$ wrapper
--modify-attack=its_name ...'.
Is it clear?
There is a question how to find successful attack that covers only
part of hashes. Say we track attack's ratio of cracked password to
candidates count (are there better properties for success? it could be
tricky to go this way with incremental mode) so to estimate attack's
success we compare this ratio with some value we consider successful
(for instance if every 1000 candidates gives 1 password then attack is
successful). But how to estimate coverage? For that user should take
one attack and then look over all related attacks. It does not seem
right for me.
I think it could be solved storing separately meta-attacks that lack
some certain information and contain more general properties. For
instance pattern could be applied to different hash types thus giving
us one attack per hash type. That attacks differs only by hash type.
So if we look onto all attacks and pick only those with different hash
types then we could generalize them into such meta-attack. But as of
meta-attack is not connected with john's cmd-line directly we could
populate properties like 'applied to hash type X = yes/no' so it will
be easy to search on them. To apply such meta-attack to new hash type
we need just to alter one regular attack that consists in that
meta-attack. (I think user should see not only name of attack in web
ui but start of cmd-line to modify it.) Meta-attack is not something
magical, it is just a way to group similar attacks together to have
easy access to advanced statistics (that involves more than one real
attack), but thinking about them like about attacks gives ability
search them like regular attack.
I'd say that we could only meta-attacks generalizing real attacks on
the fly but we could group attacks in different directions. As you
said we could alter hash type but also we could alter something other.
And it seems worth to store several possible groups (or maybe even all
if it is not too slow).
> >> It should also be easy to create new attacks by adjusting a copy of an
> >> old attack.
> >
> > I just imagined following:
> > $ wrapper --modify-attack=old_name --name-attack=new_name
>
> In your example, is ol_name the name of another attack defined by the
> same user (on he same client), or could it be any attack defined by
> another user on another client?
> If it is the latter, I assume you thought of letting the user decide the
> attacks name.
> Of do you distinguish attack defined by several (if not hundreds of)
> different users, all naming their attacks test1, test2, and so on?
Hmm, I think it would be convenient for user to use short names for
his attacks.
For new attacks I thought wrapper could give names automatically. I
think similar could be applied to renaming on modification.
Though it seems natural to allow user name his attacks himself. I
think attack could have short and long names: by short name user could
refer only his own attacks while long name refer any attack. To make
it easy to work with such names we could say that long name is
user_name+attack_name with some delimiter between them (for instance
aleksey_test1, or maybe aleksey::test2). So when user1 works he uses
test1, test2 and so on for his attacks while other users see them as
user1_test1, ueer1_test2 and so on. It is easy to implement: wrapper
looks for delimiter in attack name, if there is no delimiter then
wrapper prepends (though we could append, so there is a question how
is better?) attack name with user name and delimiter.
So probably it could be better to mix automatic naming with manual: if
user wants to name attack he names else wrapper name it itself.
> >> There should also be some way to compare, sort, filter attacks according
> >> to various attributes, to detect which attacks were more successful than
> >> others...
> >
> > I'd say this is not a problem because request-tracker has custom
> > fields
>
> So you want to define some custom fields which will be populated by the
> server (or by the client running the attack) automatically?
Yes, I would like to define some custom fields. It will allow us to
use searching/filtering capabilities of request-tracker.
Some fields should be filled by wrapper. We could have separate fields
for each cmd-line option. Some fields will be filled and then updated
during run (for instance speed). This fields represent real values
from user and john, but also it could interesting to store computed
values there (for instance time since last crack or ratio of password
to candidates for last 5 minutes). I think it is possible compute
values on both client and server. Each way has its benefits and
drawbacks: it could be easier to implement on server but it will load
it.
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.
