[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110321224352.GA32577@openwall.com>
Date: Tue, 22 Mar 2011 01:43:52 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Interface for John
Hi Joseph,
On Mon, Mar 21, 2011 at 11:08:07PM +0530, joseph varghese wrote:
> I'm really interested in developing a gui for john. And i also have
> experience building gui in gtk.
Can you provide more info on this GUI in GTK that you developed, please?
If it's Open Source, then include a link to the project and source code.
How much of the work did you do yourself?
Did you have a task to distribute pre-compiled (binary) builds of the
program for certain operating systems (and which ones)? How did you
approach it? Specifically, did you get the same binary working for a
wide range of versions of the underlying OS/distro, and how? (I have
some thoughts on this, but I want to hear about your experience, and
your thoughts on the matter first.)
> May I know what all functionalities i need to incorporate in the gui.
As our ideas page briefly mentions, there are two possible approaches:
1. Wrapper around the command-line program. The various command-line
options of "john" will need to have their GUI equivalents (checkboxes,
input fields, etc.), and a command line will be formed from those. Then
the GUI will need to actually run "john" (upon the click of a button).
There will need to be some minimal interaction with the running "john" -
much like what is possible from a terminal now - its status should be
visible somewhere in the GUI, and its "terminal" output should appear in
the window. There should be a convenient way to invoke "john --show" on
the "loaded" file(s) and browse its output, without altering the main
(cracking) command-line settings.
There are already some GUIs for JtR of this type:
http://www.mcafee.com/us/downloads/free-tools/fscrack.aspx
http://fscrack.sectoolz.com/sites/sectoolz.com/files/fscrack.jpg
http://bogus.jp/johnthegui-1.html
http://bogus.jp/johnthegui-2.html
Unfortunately, they're not good enough. Aside from limitations of the
wrapper approach and issues with the specific implementations, these
programs are not entirely free (not Open Source, and FSCrack is not
licensed for business/commercial use at all), not portable (they're
Windows only), and one of them is Japanese-only. The lack of publicly
available and suitably licensed source code makes their future unclear
(or rather, it is almost certain that they won't be updated, and
definitely not in time, to support any new options of JtR, etc.) This
makes them pretty much unusable even by people who would otherwise
appreciate a limited wrapper-type GUI.
Another wrapper-type GUI to look at is Zenmap:
http://nmap.org/zenmap/
It is not for JtR, but it does a better job of wrapping a program's
features, and it is FOSS.
2. Integrated GUI, linking with the main John program object files and
producing a GUI-enabled binary executable file. In my opinion, this
approach is only worthwhile if it provides better user experience and/or
greater functionality than the wrapper approach. Specifically, the
loader of password hashes will need to become interactive. On the
command line, it is currently possible to specify a set of password hash
files along with some options to include/exclude certain kinds of
entries, but not always individual entries (e.g., there's no reliable
way to include a "root" user from one file but not from another, yet
load the rest of entries from both files). With the GUI, this should
become possible, with checkboxes next to each entry loaded from the
files. Further, the same widget may be used to display cracked
passwords (in the corresponding column), both during and after cracking.
This kind of interface is implemented in programs such as L0phtCrack,
SAMInside / PasswordsPro, Proactive Password Auditor:
http://www.l0phtcrack.com/learn.html
http://www.insidepro.com/eng/saminside.shtml
http://www.insidepro.com/eng/passwordspro.shtml
http://www.elcomsoft.com/screenshot.html?product=PPA
In a future revision, greater interaction with a running cracking
session may be added, such as to add/remove nodes on the fly (once
distributed processing is implemented).
With either approach, further enhancements may include more verbose
and/or visually pleasing status reporting, as well as analysis of
cracked/uncracked passwords with pie charts and the like. Obviously, it
should be possible to run such analysis on previously cracked passwords,
even if John was not previously run through the GUI. (For some people,
the only reason to run a GUI would be to generate the pretty charts for
their report.)
The two approaches are not strictly mutually-exclusive. Either type of
a GUI has its pros and cons. For example, the wrapper-type GUI will
have the advantage of working with various experimental builds of the
command-line "john", including of versions/branches of John that might
not have GUI support integrated or updated to reflect other changes (so
they would not compile with the integrated GUI). So it may make sense
to work on both types of GUI at once, sharing some portions of the
effort between them (such as GUI toolkit choice and the experience of
making binary builds suitable for distribution). In fact, maybe the
integrated GUI should have a mode where it switches to be wrapper-type
for a command-line build of John (instead of invoking its linked-in
version of John), and maybe it should have a compile-time setting that
causes a wrapper-only build to be made (disables linking in of a copy of
John). I welcome proposals in this area.
> I also need a rough idea how the interface should appear.
I've partially addressed this above. One more requirement (or strong
preference) is that it should have native look on every major system
it runs on. This primarily applies to Mac OS X and Windows. On Linux,
it should probably have a GTK app look, which is pretty common. This is
why I had suggested wxWidgets (rather than Qt, or using GTK directly).
My understanding is that it can achieve native look on Mac OS X and
Windows, while being a wrapper around GTK on Linux and other Unix-like
systems. Is there any reasonable alternative to wxWidgets that meets
this requirement?
I don't strictly object to us using GTK directly (and thus having GTK
look on every system...), but I would consider that a drawback.
The GUI toolkit topic (in the form of wxWidgets vs. Qt) was also briefly
raised on john-dev:
http://www.openwall.com/lists/john-dev/2011/03/14/12
I think the above should be more than enough to address your initial
questions. Please let me know if you have any further questions or,
better yet, proposals.
Thanks,
Alexander
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.
