Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 27 Mar 2011 18:21:07 +0300
From: Shinnok <>
Subject: [GSOC] Another GUI idea for JTR :-)

Hash: SHA1


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:
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:

  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: 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:

  Quote from
  "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.
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

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:
  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:

     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 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( combined
with Qt Resources ( 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(
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


Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


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.