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 18:15:30 +0300
From: Shinnok <>
Subject: Re: [core john] [Johnny] Windows event loop

> On May 11, 2015, at 4:45 PM, Mathieu Laprise <> wrote:
> Shinnok said: 
> 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.
> I tried this solution a few days ago which is based on KingDragon( <>) but as I stated at the end of this answer <>.
> 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(from the same stackoverflow article) 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)

Have you tried DetachConsole first then Attach? Some people say that fixes their problems.

My gut instinct after reading about this is that the CTRL_ events are only supposed to work from inside the Windows Console Application, but then that doesn't explain why it works via the intermediary process method.


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.