Date: Sun, 27 Mar 2011 06:16:47 +0400 From: Aleksey Cherepanov <aleksey.4erepanov@...il.com> To: john-users@...ts.openwall.com Subject: Interface for John I am looking for creating a gui for John too. I know C++ enough to write something but not good. I'll improve it in the nearest future. I am more skilled with scripting languages including Python, Ruby, Perl, Tcl, php, Lua, shell (exactly bash). I have experience with WxWidgets and C++, and more experience with other frameworks like WindowsForms in conjunction with IronPython, IronRuby, C# or Boo (under Mono), Tk with Perl, Ruby or Tcl, Swing with JRuby and Shoes with Ruby. Example of my code in tcl-tk is available at googlecode: http://code.google.com/p/aleksey/downloads/detail?name=sii_signs.002.src.tcl&can=2&q= . Comments has littly outdated formatting style. Now i write comments much prettier. Also i participated in other opensource projects: i am the second owner of jetdroid (http://code.google.com/p/jetdroid/ ) project and i posted some bugreports with a little patch into android-vnc-viewer project. I had tasks to build an application for a particular platform. With wxwidgets i built an application for windows mobile. I had problems with encodings of wxstrings. Then app was adopted to platform in non-portable way. Encodings is a widely spreaded problem with gui frameworks. I also noticed that problems with Tk on windows and Shoes on utf-8-aware systems. When target platform did not have some libraries i used static compilation to get application work. That was used with wxwidgets on windows mobile and with small native app for android where libc was built into app. Also with wxwidgets i encountered that some widgets have very different set of really working minor features on different platforms. Hence if one uses features rarely used and rely on code tested only on one platform then on other platform app may behave surprisingly strange. I suppose to fastly write easily editable gui in wxpython as wrapper for JtR, polish it and then rewrite in the c++ language integrating with JtR. Polishing may include triing different ways of gui construction and different widgets in use, improving usability by correct grouping of settings, adding built-in help, extending gui with exciting features. Simpliest integration as i think should look like movement main function into library as is with only renaming and addition of small real main function that just passes its argument to old main function from the library. And gui will call it like that. It will provide an ability to pass any arguments to John without a need to think about windows specific quoting on windows (exec family works through a CreateProcess function, hence building single string from arguments and then split it back, it works improperly with quotes inside args on windows xp, i do not know about new windows' versions). Possibly it will be needed to make some tricks with input/output to interact with such full John in a way we interact with it as with a regular child process. Lately more tight integration should be done but for start it seems to be good. Also it is possible that for user looking for a attractive ui it will be comfortable to have additional features like editing rules in that interface rather then in a separate editor. I do not know John enough well to imagine all advanced features like this. One another thing is to provide a field in that user could see (and copy from) command line string that John will be called with (or like it will be called with). It is something like --libcurl option for curl that dumps a C program stub for particular command line but that dumps command line string for particular settings configured through gui. I am going to write a very simple gui for John in wxpython soon. I would like to hear some critics. What should i think about? What will be good to learn? Regards, Aleksey Cherepanov
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.