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.