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.