Date: Mon, 28 Mar 2011 18:37:04 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Interface for John There were a couple of postings on Qt to john-dev recently: http://www.openwall.com/lists/john-dev/2011/03/24/1 http://www.openwall.com/lists/john-dev/2011/03/27/2 Summary: Qt is within consideration, along with wxWidgets. Shinnok's lengthy proposal (above) covers many other topics as well. On Mon, Mar 28, 2011 at 05:16:45AM +0400, Aleksey Cherepanov wrote: > I wrote a simple interface for John. It is not complete and is more an > example of code rather than a real interface. It is available at > http://code.google.com/p/aleksey/downloads/detail?name=john_simple_gui.001.py&can=2 I gave this a try under Fedora 13/x86_64 running in an OpenVZ container on Owl (displaying to a remote X server - my desktop). It worked, with the major limitations as per your description indeed. I have mixed feelings about prototyping in wxPython before starting to work on the real thing, but this approach is within consideration. > I make a gui from the code but with WxWidgets it > is also possible to use xml to define gui and there are tools to do it > easily. For instance, wxGlade seems to be for WxWidgets like Glade for > GTK providing a featurefull gui designer. This approach has both pros and cons, but we may discuss it (on john-dev since it is not something we need users' feedback on). > During this small development i studied that there are wxCheckListBox > that is a listbox which each element has checkbox in. Also i found that > wxGrid has a way that is suggested for big amounts of data by > documentation (wx2.8-doc/wx-manual.html/wx_wxgrid.html): "For > applications with more complex data types or relationships, or for > dealing with very large datasets, you should derive your own grid table > class and pass a table object to the grid with wxGrid::SetTable." Sounds good. Thank you for finding and sharing this. > It should drows first time faster but for instance scrolling may be > slow. But with so big table scrolling seems to me as about useless > thing. To manage such tables it could more useful to have flexible > filtering system. Scrolling might be of little use for large tables, but it should not lock the application up for a minute if accidentally invoked. Also, scrolling a little bit up/down from a certain place makes sense (e.g., search for something, then see what's nearby). Sorting and filtering are also nice to have. With sorting in place, scrolling makes more sense. > On other hand i faced a problem with parsing of John's output. I think > about password as about untrusted data that is unpredictable (at least > if a user is not restricted to brute only alphanumeric, for instance > with its own algorithm that includes fancy charachters). Both filtering > system and unpredictable input make me think about some sort of database > to interchange with John. Yes. If we choose the wrapper approach, yet want to process the results (not just display them in a text viewer window), then we may implement and use the proposed "--show=csv" mode. > Also it may improve John's scalability. But > changes in John and writing gui for that changes will make gui not > compatible with any old versions of John that someone could value. Even Maybe the GUI will need to probe for "--show=csv", but have a fallback, or maybe this should be configurable. We can approach this later. > with the right data exchange between John and gui there is a problem > about how to show strange data in the ui. I could imagine problems with > charachter encodings, exactly with bad utf-8 sequences. Right. > Also as i understood gui should bring new users to JtR but it is also > needed to support all advanced features like very big hash files. Hence > there should be a lot of settings. But they could afraid new users. So > who is gui for firstly? If gui is for new users then it may be important > to concentrate on a usability and work "out of the box" with many hints > for new users rather than on advanced features. We should be able to add advanced features once the basic functionality is in place, but any advanced-only features should be in tabs, menus, or whatever - not confusing new users. That said, just what advanced features are you thinking of that would be confusing new users if not "hidden"? I don't see how supporting large data sets is a problem for new users. It does not involve any extra setting. Being able to produce pretty reports is not a confusing feature, and it is useful to new users too. Perhaps some of the features of the current command-line JtR may be considered advanced and moved out of the main program window, though - such as the "--salts" setting. 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.