[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D8F55E3.5080101@shinnok.com>
Date: Sun, 27 Mar 2011 18:21:07 +0300
From: Shinnok <admin@...nnok.com>
To: john-dev@...ts.openwall.com
Subject: [GSOC] Another GUI idea for JTR :-)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
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.
First my solution is based on C++ and the Qt application
framework. Now i am going to take every issue and feature
that was discussed on the mailing list related to the GUI
and discuss why it is or isn't a problem with Qt and how
i am going about to dealing with it.
Throughout the discussion I will use as an example a simple
tool I wrote called NetcatGUI which is available here:
http://shinnok.com/projects.php#ncgui
You can get much of the dissemination of issues just by reading
about it and taking it for a spin.
0. Performance
Since I am planning to use C++, the default binding of Qt
then we are talking about native code, thus maximum performance.
1. Cross Platform Compatibility
Qt is really good these days at cross platform compatibility
and in my opinion and many others it is the best choice for
cross platform graphical user interfaces. Currently supported
desktop platforms are Windows, Linux, Mac OS X as tier 1 and
many more Tier 2 and 3. More on that here:
http://doc.qt.nokia.com/4.7/supported-platforms.html
As an examples, NetcatGUI builds and runs the same on Windows
and Linux without any source modifications. I don't own a Mac
OS X, thus i can't do much about it, though it should be the
same case with it too.
2. Native looks and feel across platforms
Solar Designer mentioned that native looks are a must and that
Qt didn't achieve that when Qt as last evaluated in the jtr
context in 2004. Honestly, 6 years have past since then and Qt
has gone a long way from back in 2004. Qt now achieves native
looks out of the box on Windows(XP and Vista/7 by interrogating
uxtheme), on Linux(Gnome and KDE) and on Mac OS X.
You can take a look at some example of NetcatGUI looks on different
platforms, without any source modification on the screenshots
section: http://shinnok.com/projects.php#ncgui. No Mac OS X
screens. since I don't own one as stated before. For some kind of
proof you can take a look at QMacStyle:
http://doc.qt.nokia.com/latest/qmacstyle.html
Quote from http://qt.nokia.com/products:
"Qt uses the native graphics APIs of each platform it supports,
taking full advantage of system resources and ensuring that
applications have native look and feel."
Now in comparison with wxWidgets, Qt emulates the ui but it does it
intelligently by interrogating the system apis for the default
native looks of the os, for e.g.
uxtheme(http://msdn.microsoft.com/en-us/library/bb773187(v=vs.85).aspx)
on Windows, while exWidgets
is using the native api calls for the widgets and controls themselves
thus leaving out a lot of customization possibilities, like
Qt Stylesheets and Dynamic UI loading and rendering(more on this
later).
3. Easy Distribution across platform
Distribution from platforms can be achieved in a couple of ways for
every platform. I'll try and touch Windows and Linux for a start
and the way I would go about it:
Windows:
a. Static build seems the best way of deploying a Qt application
for Windows. I have achieved that with NetcatGUI by building
a static version of Qt and then linked NetcatGUI statically
against it:
https://github.com/downloads/shinnok/netcatgui/NetcatGUI-v1.0-win-portable.zip
Advantages for this approach are easy portable(across Windows
versions) distribution.
Disadvantages are that you can't exchange Qt libraries at
runtime, though that's more of an issue on Windows then on Linux.
b. Share build. With this approach you have to ship the Qt dlls
bundled with the app either as an archive or an installer.
Linux:
Linux is a really pain in the ass when it comes with distribution.
a. Source distribution(as a tarball) is the most common approach of
distribution for Linux for lazy(or busy) devs. that don't want
to mess around with static libs or build packages(deb, rpm) for
the available package managers. This approach is fine for people
like us that like and know how to compile stuff and interpret
the output in case of failure, but this is really not an option
fore *mere mortals*(steve jobs).
b. Static distribution, is a somewhat good approach though there
is the issue of whether you link statically against the Qt
libraries only or *everything*(libX11, libstdc++, etc..). If you
do link against everything you might turn out with a horribly big
executable and it turns out to be a really big hassle to maintain.
I am currently building a static version of NetcatGUI linked
against a statically build Qt(takes an awful amount of time to
finnish) only and leave the other dependencies at runtime.
Now it's all up to the user to ensure it has some
decent versions of the other required libraries that are binary
compatible with my build or at least an lsb compatile distribution
equal or greater with mine.
There lots more to say here and on the other approaches and since
this is a really complex issue and takes a lot of writing to get
all angles of the problem covered and since this is not the scope
of this e-mail entirely I am going to end it here.
If one is interested in this topic further we can continue the
discussion then.
d. Shared libraries in combination with packages for different package
managers(think rpm, deb). This combination is probably the smartest
choice since you build a shared binary that dynamically links
against the required libraries. You then specify the dependencies
in the package manager description language and leave it to the
package manager to install the required libraries for your binary.
The disadvantage here is the effort it takes to create packages
for each supported distribution and maintain them.
e. Bald shared builds. These are only useful if you ensure that the
user runs the binary on the same distribution and version you did
the build on.
4. Interfacing against JTR.
As mentioned before there are only two approaches here:
1. Wrapper around the command line
I would chose this option first since it doesn't create binary
dependencies between the gui and the jtr backend. Another
advantage to this approach is that you can use the same GUI with
multiple versions of jtr. For this approach i would use stdlibc
popen() to interface to jtr on *NIX systems and _popen() on
Windows, nothing special here.
2. Interfacing with the object files
I would go with this one only after the first one has been
accomplished and time and reason enough is left to do it.
First of I am thinking that since jtr doesn't provide a stable
api interface for the gui to use this might turn out in to a cat
and mouse game or we implement one which is extra work.
The only real reason here to do this would be speed and
flexibility. The the latter one is more of a mirage if you don't
have a stable jtr api layer to base on. As for speed..well it
only counts if we are talking about millions of hashes, thus
results that need to parsed from the jtr output.
I am willing to go with this approach if you go head on with
this one and forget about the wrapper approach since there's
no real reason to support both because of fragmentation and
confusion on the end user perspective.
Now let's get to my proposal for a GUI to john.
What I am willing to do is a cross platform, easily customizable
graphical user interface with default native platform looks for each
supported platforms that is both easy to use and feature rich enough
to access all of jtr options from it. Initially I would concentrate
on supporting Windows and Linux, since I don't own a Mac and can't do
real testing and development for it. I would welcome external help on
the Mac issues of course or remote access to some Mac box that OpenWall
might have available for development.
The full customization of the user interface would be achieved using
Qt Stylesheets(http://doc.qt.nokia.com/latest/stylesheet.html) combined
with Qt Resources (http://doc.qt.nokia.com/latest/resources.html) to
create a theme engine that will enable full customization of the GUI
from the native look any kind of crazy interface. I am also thinking
about allowing for full customization of the ui(meaning the layout and
types of widgets) using at runtime dynamically loaded interfaces from
themes using QUiLoader(http://doc.trolltech.com/4.7/quiloader.html)
for e.g.
The GUI will enable easy interactive editing of password files both
as input and output, comfortable session management, interactive editing
of wordlist rules, enabling or disabling of options like -shells or
- -single and realtime status interrogation either via SIGHUP/popen()
on *NIX systems(if we decide that detaching john is better, since
there's no reason to keep it attached only for status if we can get
it in a file and read that) or _popen() on Windows with sending a key
over the pipe/stream and then reading the output.
I am welcome for feedback and suggestions. Also feel free to ask
anything that you think i left ill described, in doubt or missed
completely.
Regards,
Shinnok
<http://shinnok.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNj1XhAAoJEAzuYPBIYMpXL3wH/RpLvzVBnAvuXA1kjZwh4tfZ
mWd2MIZQ/I1ybWm4PmwifYwojmiw5koIo3MLAmEjGa/9Y6L1QOIgPORd8o1lANGJ
kmJLPxh2n4sHeqtioYmGVFB2G/27xmdDyaFNYaEcnUq83jzTb8jnQNQy9wP67Lfj
zkNIKnmXPwhHWwTbm9sSfuKaWP17+4HINOzD3kzvE2wt85bzIJv3ReTXtAijplUt
j6sWGqhU1T9xdkhkpGk6ZvGUr93QNM/9B7vbL/34ZSWrd8c1MU/eCVTKiAVc1WVc
yR44B40B55oOgMM3zbzlveOBuLpD/Rb6ypKbPMb3Pwhc2IxfQEhBrI3/9+03Vi8=
=KsnW
-----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.
