[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D8F5B1F.4070608@shinnok.com>
Date: Sun, 27 Mar 2011 18:43:27 +0300
From: Shinnok <admin@...nnok.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSOC] Another GUI idea for JTR :-)
-----BEGIN PGP SIGNED MESSAGE-----
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
conclusion.
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. :-)
http://seclists.org/nmap-dev/2011/q1/1044
Good luck,
Shinnok
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:
> 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/
iQEcBAEBAgAGBQJNj1seAAoJEAzuYPBIYMpXcOsH/RQNu/sjAurHBC3OPdp1CkLO
Z21aUBP0k3jNrMy7q+0SHeTZa6E5FIW/ZWXB2HbkXHn2YRtVNgHLm8qysungjCn6
6ecM0PAwllBi4+QyAAxeJdFILNdDUc1VQY5JIBW6P3w/GTpI1naFOq/Vxix6p4+q
aXU9U9B/Jgcp7tSZDAR0bPgUZuc0clMILsumF2Dgv6pp2Il5fyJUoTGB8bAO93lh
nqgXjdIpC7zjnyw4BBL2ky21e6sk4yOyQNJC7GoiI2jJmUgZuX7O6xEjHx2qrLpQ
8elLBmE5uicsOAV9R5R8bXVy1/o3ENIJ69uA3o6NLdXMO5MYPmbjX0oEmSw3MHM=
=W1tk
-----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.
