[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86sju6nhin.fsf@gmail.com>
Date: Tue, 29 Mar 2011 18:11:28 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Interface for John
> We should be able to add advanced features once the basic functionality
> is in place, but any advanced-only features should be in tabs, menus, or
> whatever - not confusing new users. That said, just what advanced
> features are you thinking of that would be confusing new users if not
> "hidden"?
I think features for new users may be also advanced. I mean extended
userfriendliness like hints, tips and documentation integrated in the
interface. Is that important?
About confusing i think it is possible that users may be afraid when
there are many options they do not need now. For instance, navigation
and filters for the resulting table are necessary for all users but may
confuse someone. I think in the simpliest way there should not be any
options at all. But they should be easily accessible. I think users do
three types of work: managing of files and their hashes, managing of
settings and managing of Johns. Each type of work will have its own
features not connected to other types of work. For instance user may
want to look through hashes and split them by type without running
John. I've already imagined an powerfull interface that will not confuse
anyone. I will show it soon but whithout functionality.
Managing of files consists of selecting a part of file, splitting files
by different parameters like hash types, shells, or even by number of
password with the same salt, joining files together.
Managing of settings consists of setting up everything and making
profiles with sets of configured options. Each started John have its own
set of options.
Managing of Johns consists of starting, stopping one or multiple Johns
keeping sessions. For wrapper it is possible to run John remotely (for
instance over ssh). It seems to be good for gui to have its own sessions
and to be able to be setted up with John's session file.
A question about reading John's output: is it needed to read John's
output on the fly? Or is it possible not to read output and to call
'john --show' by user's demand? Or should it be customizable? If it is
possible to read from time to time and not line by line as John writes
then it should be easy to read input from csv as of WxWidgets supports
csv reading through wxODBC module. It is interesting because it gives
wxTable object that is capable to be used with customized wxGrid.
It may provide an interesting property: all processor intensive
operations would be done by WxWidgets. So using of wxPython should not
decrease performance. Also wxPython is somewhat portable and it seems to
be easy to distribute only a script while all distributions provide
their own wxPython without any thoughts about binary compatibility.
I do not keep python in my heart. I mean it is ok for me to write in C++
(or even with Qt; i like to learn anything new). But prototyping with
python splits a task into two separated: writing a fully functional gui
and integration of gui and John. I could imagine that writing of an
excellent gui may spend a full summer. And a good pythonic gui even
without next integration may be good in the whole. Also it is possible
to make then a python (and others) bindings to John.
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.
