[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4D9790F3.8030501@shinnok.com>
Date: Sun, 03 Apr 2011 00:11:15 +0300
From: Shinnok <admin@...nnok.com>
To: Solar Designer <solar@...nwall.com>
CC: john-dev@...ts.openwall.com
Subject: Re: [GSOC] Another GUI idea for JTR :-)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi again Alexander,
I have written a basic concept GUI for JtR name Johnny and uploaded some
screenshots to the wiki page: http://openwall.info/wiki/john/GUI#Shinnok
. No interfacing to john is done.
The GUI in the current state is a proof of concept and
it doesn't implement everything that I am going to describe bellow,
though it should be enough to prove the concepts and GUI paradigms
that i've chosen. There's still lots of thinking to do, on issues like
how to visually present multi-sessions and better grouping of options
and actions in category tabs, as well as lots of work small or iterative
tasks like tooltips, menus. I will e-mail again once I have considerable
advancement with Johnny or built packages(static or not) for some of the
platforms supported(currently you have to build Johnny yourself if you
want to see it for real).
What follows is an overall and future plan useful both now when I am
trying to describe what Johnny is all about as well as for further
reference.
Next I am going to describe in more detail what I am thinking about
and how would I see further implementation of Johnny.
The reasoning behind the GUI is simple but at the same time profound:
Complexity through simplicity and non-intrusive expert and non-expert
availability.
The idea is that with careful design and by identifying the most basic
and common operations(or concepts) of JtR which we can then use as main
actions within the application(the big intuitive buttons in Johnny) as
well as action containers(the tabs in each session) grouping logically
related actions for the more advanced(expert) options that JtR has
available. This way we don't need to *hide* the expert options in
complex menus and/or dialogs(+questions) that might popup at undesired
moments in time(which btw, it is very hard to come with a timing that
pleases for all) or be really annoying for the more
experienced users(they'll perceive them as nag screens or a wall in
their efficiency).
With this design we hide the expert options in *plain sight*, thus
making them ignorable for inexperienced users through default
reasonable(and visible, not hidden in menus and such) options
(restore:yes, allgroups, allshells, allusers, etc..) and
at the same time accessible to the experienced ones with at most
one click(or keyboard shortcut). Hover help tooltips for all options
and actions achievable from the GUI are provided as well as a big
help button, to encourage the unexperienced to dive into more
advanced usage of john.
The interface also leaves room for lots of new options, either future
john options, as well as gui specific options like, hash detection,
dictionary editing and generation or interactive bruteforce charsets or
rules creation and many more cool things that I am thinking about. :-D
The GUI also shows a possible approach to the millions of
table(spreadsheet) rows issue raised by you Alexander when discussing
the GUI. The approach consists of using a model view implementation
using QAbstractTableView(http://doc.qt.nokia.com/latest/qtableview.html)
and
QAbstractTableModel(http://doc.qt.nokia.com/latest/qabstracttablemodel.html)
which eliminates the need to have a widget
for each single table cell(an approach which would render a
system/application useless(both cpu and mem terms) at about 10000
widgets). The current model view allows for about 500000 items to be
displayed in less or equal to
a second(on my system),using reasonable amounts of ram and then scroll
and interact with the items seamlessly and smooth. There's still room
for improvement, for eg. to display handle the displaying itself
manually too using
QAbstractItemDelegate(http://doc.qt.nokia.com/latest/qabstractitemdelegate.html)
and work with more raw data structures instead of Qt's ones(QString) as
well as try to omit some additional
steps when passing/modifying data from the controller to the custom
data structures in the QAbstractTable model. The end goal is to print
1000000(one million) table lines in less or equal then a second, which
is a comfortable number. One can test the loading of data in the current
model-view implementation by pressing "Load 500000 hashes" in this
screen
http://openwall.info/wiki/_detail/people/shinnok/johnny/johnny-gnome-unity-1.png?id=john%3AGUI&cache=cache
, if you built johnny that
is.
That's about it for now, I'm waiting for your feedback.
Regards,
Shinnok
On 03/28/2011 08:28 PM, Solar Designer wrote:
> Shinnok -
>
> On Sun, Mar 27, 2011 at 06:21:07PM +0300, Shinnok wrote:
>> By reading the latest e-mails on john-dev and john-users
>> as well as the ideas wiki page debating the GUI issues i
>> would like to propose my own idea for a GUI to john as well
>> as disseminate the views on Qt and why i would chose it.
> ...
>
> Thank you for writing this! Unfortunately, I have difficulty finding
> time to fully review and consider it now, but I intend to. I've also
> referred to your posting in the thread on john-users such that others
> making proposals for a JtR GUI can consider your thoughts on the matter.
>
> I also appreciate you posting a link to your proposal to Nmap. It is
> helpful for us to know who intends to apply to other projects as well.
>
> I am leaving your message "flagged" in my mailbox as needing further
> action on my part.
>
> Thanks again,
>
> Alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJNl5DsAAoJEAzuYPBIYMpXGzQIAJEJEWlLsEwpatYvBHjmsOZ9
kF10/Rw0UUn6kgDBrCFdWurCpKyv5M3gNrageETDEXHgrwPHUNCXC67VnXWD5BKg
VCuc1i8wXe/iuGVz/xrAXUUyHnZqJ7h3wEL27Ck18YXWfXjnNiMdaupIRIcJo6DI
jaKWkoYXBalQVb6j5O6VFp0Komlgeqvxu21Lgmesd47cLB4f6Vs52WvsWF9g2B2j
L0j0/F1KqrIvHVUDWNLkvM3dCLxBLQ3LJJEwEla9wI31RBjjskFg1PFI9mFS+ccr
vdMSCyMxJDLqHwumwUfONz3p0Cti3mkHQtrOlGobe05QFx64mQOdxh8GkfqKUAo=
=RM5a
-----END PGP SIGNATURE-----
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.
