[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86mxgvuhsb.fsf@gmail.com>
Date: Mon, 04 Jul 2011 02:21:40 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Johnny GUI interactive status from John
> >> You can force a status update by sending a signal 1 (SUGHUP)
> >> to the corresponding process:
> >>
> >> kill -s 1 <pid_of_john_instance>
> >>
> > 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.
I tried 'kill -s 1 <pid_of_john_instance>' and 'kill -s SIGHUP <pid>' on
my Debian in chroot under Android with John 1.7.7 from Debian and both
commands did not force John to show status. Of course Android is not a
good system to consider something badly portable. But signals seem to be
a too complex solution to me.
> > > 1. This one applies only if john is ran from a tty device. Merely
I tried it and it seems to be so. For instance behaviours of 'john ...'
and 'cat | john ...' are different.
Also i noticed that John reacts on ctrl-d as on enter. And as i
understand without terminal (tty or pty) it is not possible to send to a
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.
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.
> > > 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.
> > > 2. This second one has several issues to be considered:
> > > *Using this method would involve running another john instance
> > > separately from the cracking one to interrogate each time we want
> > > john's status. This is not nice.
> > > *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.
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.
