[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <55870CFB-9D44-490C-9F44-BDAB14FE4F77@shinnok.com>
Date: Mon, 11 May 2015 16:35:23 +0300
From: Shinnok <admin@...nnok.com>
To: john-dev@...ts.openwall.com
Subject: Re: [core john] [Johnny] Windows event loop
> On May 8, 2015, at 8:43 PM, Mathieu Laprise <mathlaprise@...il.com> wrote:
>
> On Fri, May 8, 2015 at 12:39 PM, Aleksey Cherepanov <lyosha@...nwall.com <mailto:lyosha@...nwall.com>> 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 http://www.qtcentre.org/threads/36911-Can-t-send-a-Ctrl-C-to-a-QProcess-%28Win32%29 <http://www.qtcentre.org/threads/36911-Can-t-send-a-Ctrl-C-to-a-QProcess-%28Win32%29>, 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) https://msdn.microsoft.com/en-us/library/windows/desktop/ms683155(v=vs.85).aspx
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." https://msdn.microsoft.com/en-us/library/windows/desktop/ms686016(v=vs.85).aspx <https://msdn.microsoft.com/en-us/library/windows/desktop/ms686016(v=vs.85).aspx>
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.
Shinnok
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.
