Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 May 2015 16:35:23 +0300
From: Shinnok <>
Subject: Re: [core john] [Johnny] Windows event loop

> On May 8, 2015, at 8:43 PM, Mathieu Laprise <> wrote:
> On Fri, May 8, 2015 at 12:39 PM, Aleksey Cherepanov < <>> wrote:
> If you AttachConsole(), can't you just send Ctrl-C?
> Though it is not clear to me: does CTRL_BREAK make john to save state
> on exit? Or is it just a way to kill the process?
> If you mean sending Ctrl-C to stdin, I saw there <>, that it didn't work the same way if we send it with stdin(at least on unix).
> If you mean sending CTRL_C_EVENT,
> In John, signal.c, all CTRL_XXX_EVENTS are handled by this code for Windows. 
> #ifdef __CYGWIN32__
> 	SetConsoleCtrlHandler(sig_handle_abort_ctrl, TRUE);
> #endif
> #ifdef __CYGWIN32__
> static CALLBACK BOOL sig_handle_abort_ctrl(DWORD ctrltype)
> {
> 	sig_handle_abort(SIGINT);
> 	return TRUE;
> }
> #endif
> So, sending event CTRL_C_EVENT or CTRL_BREAK_EVENT, both call sig_handle_abord(SIGINT) which will handle cleaning or other stuff needed by John like if it was from the tty. So john saves its state.
> However, in my tests, I got the same result as Shaktra for CTRL_C (returned true but wasn't sent). Here is what he said on stackoverflow.
> It is very important that each step is done like this. I've been trying all different kinds of combinations but this combination is the only one that works. You can't send a CTRL_C event. It will return success but will be ignored by the process. CTRL_BREAK is the only one that works. Doesn't really matter since they will both call ExitProcess() in the end. (EDIT by me: In our specific case, we reimplemented the handler so sig_handle_abort_ctrl() will be called before)
> Aleksey said:
> I am pretty sure that you've tried `taskkill` without /f to kill john
> from cmd. It did not work, right?
> Yeah exactly, I didn't get it to work.

Mathieu, I'm not sure you have been exhaustive enough in assertions regarding the exploitation of the CTRL_ events. 

What we know:

1. We can signal CTRL_ events to JtR on Windows with GenerateConsoleCtrlEvent. (#ifdef'ed of course)
2. We can ignore CTRL_ events in Johnny by doing:
	"	• Calling SetConsoleCtrlHandler with the NULL and TRUE arguments causes the calling process to ignore CTRL+C signals. This attribute is inherited by child processes, but it can be enabled or disabled by any process without affecting existing processes." <>
3. We can re-enable CTRL_ events back in JtR. Simple patch to core.
4. Verify in signals.c that JtR does indeed kill itself upon doing that for Windows.
5. Hail that we don't have --fork there.

Let's focus on CTRL_C_EVENT until we have reason to do otherwise.

Content of type "text/html" skipped

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.