On Wed, May 13, 2015 at 12:41:08PM -0700, math07 wrote:

1. Johnny seems to update only console log when attack ends. For example, sometimes I get the 4 hashes loaded message only when I pause attack.

It may be due to output buffering. (John prints but we don't get it
till it is flushed on the end of work.)

2. Maybe status button could be interesting, or automatic status(sigup) every X minute.

You may try the following option
--progress-every=N emit a status line every N seconds
--crack-status emit a status line whenever a password is cracked

It may help partly: older output will be just pushed out by newer
output more often but with lag too (so the last status line won't be
seen at the moment it is printed).

On the same note, I've seen a TODO
void MainWindow::readJohnShow()
{
// TODO: Read John's output while it runs. Do not wait before it
// finishes.

The function above reads the output of john --show that is expected
to finish rather quickly (immediately). The continuous reading would
be good when the output is very big to process it not storing memory
fully.

Thanks!

Regards,
Aleksey Cherepanov

There's several things to be done here:

1. Subclass m_showJohnProcess from JohnProcess too.
   2j. Add --progress-every settings option, enable by default with sensible default. This will override how we update the status bar.
   3j. Always pass --crack-status. This will override the current m_showTimer.
2. Verify if JtR flushes output stdout when writing status&progress lines(both flush() and '\n' should properly flush a std buffer).
3. If 4. is not confirmed, ask john-dev if we can get an unbuffered option to JtR(man setbuf(stdout, NULL)). Maybe no-tty option could be unbuffered on stdout by default?

Do you guys mind if "--progress-every=N and --crack-status" isn't available in john-core, it's only available in jumbo ?

@Math07 I don't see how it could be different.

Shinnok said:
2j. Add --progress-every settings option, enable by default with sensible default. This will override how we update the status bar.
3j. Always pass --crack-status. This will override the current m_showTimer.

What I meant is : do you think it's a great idea to have two differents logics in the code to update the progress bar and the status(timer) one specific to john-core and another code specific to jumbo ? Also, given the fact that the bug would still appears in john code.

For core, we need answers for points 4 and 5.
For jumbo, the crack-status and --progress-every will eventually override the timer option since it is a better method.
We are talking about two different things here:

1. The inability to get status from core john stdout. This relates to showing statistics, reading cracked passwords and updating Console Log.
2. Jumbo presents improved options for us to get statistics and status lines. However we'll still be hit by the inability to read stdout properly.
   In these two contexts:
   a) Updating console log properly;
   b) Getting info from a running JtR instance;

It might be best to split these into separate issues and tasks respectively. Also to start the appropriate discussions on john-dev.

All right, I understand thanks. Let's concentrate on case a) for this issue. I'll make another issue for case b)
You are right guys, it's related to the buffering of john. For example, for the X hashes loaded message), there is this line in john.c with \n, but it doesn't seems to flush the buffer. If I add fflush(stdout); after this line, Johnny will get it and print X hashes loaded at the right time. I guess this happens with other important strings in JtR. I'll start a thread about this on the mailling list.
printf("Loaded %s (%s%s%s [%s])\n",
john_loaded_counts(),
database.format->params.label,
database.format->params.format_name[0] ? ", " : "",
database.format->params.format_name,
database.format->params.algorithm_name);

@Math07 I got caught up in some general improvements today following up on your TODOS PR integration, thus I won't get to write the CoreHandler stub until tomorrow. If you get some spare time left can you please create the separate issue for b) and also try and write a followup to the e-mail discussion on john-dev? Take the time to sink into the issues described, since they are quite important for now and the future, so it's important that you have a grasp of it.

If you have questions or doubts, include them in the e-mail.

--progress-every option would be useful for updating the Statistics pane.

@Math07 do we have a resolution for sending keys to a running JtR instance? (john core especially)

do we have a resolution for sending keys to a running JtR instance? (john core especially)

No, I don't think so. The write to process didn't work last time I tried it. I remember seeing in the code comment and in the mailling list that this was a concern Aleksey had back in the days and that's why he had to rely on john --show and timer.