Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 4 Jun 2015 22:12:47 +0300
From: Shinnok <>
To: "" <>
Subject: Re: [john-core] Getting John's stdout unbuffered for Johnny

> On Jun 1, 2015, at 6:45 PM, Shinnok <> wrote:
>> On 01 Jun 2015, at 13:02, Solar Designer <> wrote:
>>> On Mon, Jun 01, 2015 at 09:30:42AM +0300, Shinnok wrote:
>>>> On May 27, 2015, at 10:56 PM, magnum <> wrote:
>>>> As far as I'm aware it treats input as a TTY if it is indeed a TTY, nothing weird about that. It doesn't default to reading candidates, there's an option for that.
>>> If that's not the case, then maybe we need _IONBF for stdin on JtR for the non-tty and non stdin cases too. I can't get a char from Johnny to JtR.
>> What char are you trying to send and why?  I guess you're doing this to
>> trigger the status line, or you're sending 'q' to have it quit gracefully,
>> right?  If so, the first hurdle is that currently JtR would expect that
>> char to come from its tty, not from stdin.
> Yes I'm expecting status lines(from any char besides q). Quitting via q is interesting too, but has less potential now that we've handled proper termination on Windows.
> So if we're not in tty and not in stdin candidate mode, what does John do exactly on std input.. Nothing?


After some more thought, we do have to figure out and start working on a solution for both stdout and stdin. For the latter, if we take into consideration the concurrent cracking sessions feature, both of these:
1. kill process group on *nix for FORK case
2. ConsoleCtrlEvent CTRL_C_EVENT on Windows

Will fail dramatically by killing all spawned JtR attack sessions. So for the future, the ability to send q to a JtR session is critical, amongst other needs.


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.