[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Jul 2011 10:02:30 +0300
From: Shinnok <admin@...nnok.com>
To: john-dev@...ts.openwall.com
Subject: Re: Johnny GUI interactive status from John
Hey Aleksey,
Thanks for the answer. Comments embedded below.
On Mon, Jul 4, 2011 at 1:21 AM, Aleksey Cherepanov
<aleksey.4erepanov@...il.com> wrote:
>> > What about Windows? I can't use signals on that.
>
>> We can code to receive a RegisteredMessage and then perform the same
>> duty as the signal. It's a code change, but likely this will not be
>> the only code change needed to properly hook in a GUI into the
>> project.
>
>> This can be done easily under cygwin/mingw/or VC.
Windows messages are of two types: window messages and thread
messages(PostThreadMessage) for headless applications.
Both messaging routines require a message queue(for WM_USER++) and
thus a loop to be run that checks for incoming ones, which seems
unlikely for JtR.
http://msdn.microsoft.com/en-us/library/ms644927(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/ms644946%28VS.85%29.aspx
Even if we'd like to do it somehow and would create a message
marshaling thread for John, we still couldn't find out which of the
two John threads to send the message to:
http://stackoverflow.com/questions/3083903/postthreadmessage-to-another-process
>> > > creating the process with popen() makes john ignore those keypresses and
>> > > as a result this method cannot be used. Approaches to this one
>> > > would be
>
> Personally i prefere Qt's QProcess class rather than popen() because we
> write in C++ and use Qt. However it does not make sense for the problem.
Yes, Johnny will use QProcess, however, I thought popen() would be
more familiar and descriptive to the problem. :)
> I found that there are no terminal support in Qt itself but there are
> some terminal widgets. At least there are QTermWidget that i think could
> help us.
Using that kind of code doesn't seem like a good approach. Neither
emulating a terminal on Johnny's side is. Hopefully we're not going to
be forced to take this one.
>> > > to modify john's behavior in this regards or add an extra(secret?not
>> > > showing in -h or manpage) parameter specific for the GUI. This approach
>> > > would leave room for extra information to be printed that we might need
>> > > for the GUI.
>
> In my opinion any extra parameters for GUI should be documented as usual
> but with mark that it is for GUI. Because even if such options are
> useless for normal users then they however exist and someone could want
> to write its own GUI or another program that will do interaction with
> John and such options could ease this task.
Yes, I agree, they shouldn't be *that* hidden, but probably not in the
user manpage. A wiki page describing them and a reference in the
manpage would suffice.
>> > > *Another issue with this one is that john updates the status in
>> > > john.rec as often as specified in john.conf "Save" directive, which
>> > > by default it is set to 600 seconds. Using this from the GUI would
>> > > mean to modify the configuration to something like 5s or 10s.
>
> Is it needed to check status so frequently? And if it is not needed then
> i think separate John should not be too expensive.
If we'd like to display nice progress bars and current word(even if
not that accurate) and performance counters, yes. At most 10s. And
even 10s seems too long to wait for from an interactive GUI
perspective.
Thanks,
Shinnok
--
Shinnok <http://shinnok.com>
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.
