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

Hash: SHA1

I forgot to mention that the GUI will be supporting full
i18n for left to right languages too. Right to left languages
from left to right is a bit tricky, although Qt widgets support
that, it gets ugly once you start implementing it. I'll have
to research that a bit more deeply, in order to provide a good

I also sent an e-mail with a GUI idea for Ncat and
Nmap too, thus you might find interesting my e-mail to nmap-dev,
though it didn't get to the size of this one, but it will
when people start tackling it and asking for specific
issues or clarifications. :-)

Good luck,

On 03/27/2011 06:21 PM, Shinnok wrote:
> 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:
> 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.
> uxtheme(
> 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:
>      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( 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
> completely.
> Regards,
> Shinnok
> <>
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.