Date: Tue, 22 Mar 2011 01:43:52 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Interface for John Hi Joseph, On Mon, Mar 21, 2011 at 11:08:07PM +0530, joseph varghese wrote: > I'm really interested in developing a gui for john. And i also have > experience building gui in gtk. Can you provide more info on this GUI in GTK that you developed, please? If it's Open Source, then include a link to the project and source code. How much of the work did you do yourself? Did you have a task to distribute pre-compiled (binary) builds of the program for certain operating systems (and which ones)? How did you approach it? Specifically, did you get the same binary working for a wide range of versions of the underlying OS/distro, and how? (I have some thoughts on this, but I want to hear about your experience, and your thoughts on the matter first.) > May I know what all functionalities i need to incorporate in the gui. As our ideas page briefly mentions, there are two possible approaches: 1. Wrapper around the command-line program. The various command-line options of "john" will need to have their GUI equivalents (checkboxes, input fields, etc.), and a command line will be formed from those. Then the GUI will need to actually run "john" (upon the click of a button). There will need to be some minimal interaction with the running "john" - much like what is possible from a terminal now - its status should be visible somewhere in the GUI, and its "terminal" output should appear in the window. There should be a convenient way to invoke "john --show" on the "loaded" file(s) and browse its output, without altering the main (cracking) command-line settings. There are already some GUIs for JtR of this type: http://www.mcafee.com/us/downloads/free-tools/fscrack.aspx http://fscrack.sectoolz.com/sites/sectoolz.com/files/fscrack.jpg http://bogus.jp/johnthegui-1.html http://bogus.jp/johnthegui-2.html Unfortunately, they're not good enough. Aside from limitations of the wrapper approach and issues with the specific implementations, these programs are not entirely free (not Open Source, and FSCrack is not licensed for business/commercial use at all), not portable (they're Windows only), and one of them is Japanese-only. The lack of publicly available and suitably licensed source code makes their future unclear (or rather, it is almost certain that they won't be updated, and definitely not in time, to support any new options of JtR, etc.) This makes them pretty much unusable even by people who would otherwise appreciate a limited wrapper-type GUI. Another wrapper-type GUI to look at is Zenmap: http://nmap.org/zenmap/ It is not for JtR, but it does a better job of wrapping a program's features, and it is FOSS. 2. Integrated GUI, linking with the main John program object files and producing a GUI-enabled binary executable file. In my opinion, this approach is only worthwhile if it provides better user experience and/or greater functionality than the wrapper approach. Specifically, the loader of password hashes will need to become interactive. On the command line, it is currently possible to specify a set of password hash files along with some options to include/exclude certain kinds of entries, but not always individual entries (e.g., there's no reliable way to include a "root" user from one file but not from another, yet load the rest of entries from both files). With the GUI, this should become possible, with checkboxes next to each entry loaded from the files. Further, the same widget may be used to display cracked passwords (in the corresponding column), both during and after cracking. This kind of interface is implemented in programs such as L0phtCrack, SAMInside / PasswordsPro, Proactive Password Auditor: http://www.l0phtcrack.com/learn.html http://www.insidepro.com/eng/saminside.shtml http://www.insidepro.com/eng/passwordspro.shtml http://www.elcomsoft.com/screenshot.html?product=PPA In a future revision, greater interaction with a running cracking session may be added, such as to add/remove nodes on the fly (once distributed processing is implemented). With either approach, further enhancements may include more verbose and/or visually pleasing status reporting, as well as analysis of cracked/uncracked passwords with pie charts and the like. Obviously, it should be possible to run such analysis on previously cracked passwords, even if John was not previously run through the GUI. (For some people, the only reason to run a GUI would be to generate the pretty charts for their report.) The two approaches are not strictly mutually-exclusive. Either type of a GUI has its pros and cons. For example, the wrapper-type GUI will have the advantage of working with various experimental builds of the command-line "john", including of versions/branches of John that might not have GUI support integrated or updated to reflect other changes (so they would not compile with the integrated GUI). So it may make sense to work on both types of GUI at once, sharing some portions of the effort between them (such as GUI toolkit choice and the experience of making binary builds suitable for distribution). In fact, maybe the integrated GUI should have a mode where it switches to be wrapper-type for a command-line build of John (instead of invoking its linked-in version of John), and maybe it should have a compile-time setting that causes a wrapper-only build to be made (disables linking in of a copy of John). I welcome proposals in this area. > I also need a rough idea how the interface should appear. I've partially addressed this above. One more requirement (or strong preference) is that it should have native look on every major system it runs on. This primarily applies to Mac OS X and Windows. On Linux, it should probably have a GTK app look, which is pretty common. This is why I had suggested wxWidgets (rather than Qt, or using GTK directly). My understanding is that it can achieve native look on Mac OS X and Windows, while being a wrapper around GTK on Linux and other Unix-like systems. Is there any reasonable alternative to wxWidgets that meets this requirement? I don't strictly object to us using GTK directly (and thus having GTK look on every system...), but I would consider that a drawback. The GUI toolkit topic (in the form of wxWidgets vs. Qt) was also briefly raised on john-dev: http://www.openwall.com/lists/john-dev/2011/03/14/12 I think the above should be more than enough to address your initial questions. Please let me know if you have any further questions or, better yet, proposals. Thanks, Alexander
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.