Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 May 2015 16:25:47 +0300
From: Shinnok <>
Subject: Re: [core john] [Johnny] Windows event loop

I decided to take this shebang for a spin myself, here are the results.

As it turns out there is no problem with using the CTRL_C_EVENT, if implemented properly and the required attention is attributed to it. I already warned you that WinApi development is not to be taken easily, lest you had known otherwise, you should have heeded my advice.

Here's how I proceeded:

1. I implemented the Johnny side exactly as outlined in my previous e-mail:

	i. We can signal CTRL_ events to JtR on Windows with GenerateConsoleCtrlEvent(); FreeConsole() before AttachConsole() included.
	ii. We can ignore CTRL_ events in Johnny by doing SetConsoleCtrlHandler(NULL, TRUE);
	iii. We can re-enable CTRL_ events back in JtR. Simple patch to core. SetConsoleCtrlHandler(NULL, FALSE);
	iv. Verify in signals.c that JtR does indeed kill itself upon doing that for Windows;

Inspect the commit in Johnny <>.

2. Grab latest core Windows build from <> (1.7.9 (Windows binaries, ZIP, 2029 KB)). That one is built with Cygwin. Verify if Johnny can properly terminate it with CTRL_C_EVENT. Lo and behold, it does.

3. Grab latest master(thus core) from Magnum's Github account. Build and verify if Johnny can terminate that too. It doesn't. I looked over it in signals.c, re-enabled CTRL_ events and a couple more additions and now Johnny can kill it too. Alexander, the patch is attached to this e-mail. Let me know if something is not right. Regarding the __MINGW32__, that one has been obsoleted for over a decade if my memory is right. I only applied my change to signals.c, though the are many more places that use it.

4. Grab latest jumbo Windows build from <> (1.7.9-jumbo-5 (Windows binaries, ZIP, 3845 KB)). Also built with Cygwin. Is terminating properly on CTRL_C_EVENT.

5. Switch Magnum's repo clone to latest stable jumbo(1.8.0-jumbo-1). Try to build it, this one didn't go too far because of <> . I'll leave my 2cents as a comment there later.

6. Switch Magnum's repo clone to previous stable jumbo(1.7.9-jumbo-7). Try to build it, some result as step 5.

7. Go on to try out bleeding-jumbo on MinGW somewhat blindly, although I investigated previous attempts on john-dev/users a bit. I tried to build via pure MinGW-w64 via MinGW-builds and under MSYS(this is a pure MinGW build AFAIK). I then tried to cross-build from inside Cygwin's MinGW distribution. Both attempts failed somewhat dramatically (I didn't even bother to gather the details, I also got a bit confused about the many choices of MinGW now(3 or 4) so I gave up), but I expect this to be picked up after we fix at least the Cygwin part of the problem.

I can try this out on bleeding-jumbo again after we fix the Cygwin build, though I don't expect much to change there.

The most likely reason for why 2. and 4. are working without changes is that some Cyg dlls, subsystem specific that exact version used to build those(I don't know who built them, nor when) was already including the proper console headers and enabling CTRL_C events. Somewhere along the road some subsequent Cyg release "fixed" that behavior. I didn't have the time to bisect this further to find out if it's exactly that or just some JtR core code that was purged.

As you probably have figured out by now, this took me a considerable amount of time to do, so Mathieu, next time around, please strive a bit more when I tell you that you haven't been exhaustive enough regarding an approach.

Another bit of advice: don't take SO QA's as the definitive answer to all questions and issues. Most of the SO links that you pasted here lacked sufficient context, details and follow back that it triggered all of my BS flags. I don't expect you to have that sensitivity, you'll get it further down the road, but right now you have all of the great people on this list to hint and help you, so please seriously consider any advice when offered.

I expect you to take an hour or two to figure out if all of this is confirmed on your system too, then I'd like you to proceed to the comments task. My system was a Windows 7 VM. Cygwin latest as of today with gcc version 4.9.2.

Aleksey, you have your answer in this e-mail. I hope it's obvious enough.

Disclaimer: writeonce, thanks for your clarifications, they have been helpful.


> On May 11, 2015, at 8:01 PM, Mathieu Laprise <> wrote:
> On Mon, May 11, 2015 at 11:15 AM, Shinnok < <>> wrote:
> Have you tried DetachConsole first then Attach? Some people say that fixes their problems.
> I didn't find a DetachConsole method but I tried FreeConsole(). Which the doc say,A process can use the FreeConsole <> function to detach itself from its console. 
> In my tests, it doesn't changes anything before or after etc..
> To stress this option a bit more, have you explicitly re-enabled CTRL events in JtR after disabling in Johnny? like this:
> SetConsoleCtrlHandler(NULL, FALSE)
> As per the doc:
> "If the HandlerRoutine parameter is NULL, a TRUE value causes the calling process to ignore CTRL+C input, and a FALSE value restores normal processing of CTRL+C input. This attribute of ignoring or processing CTRL+C is inherited by child processes."
> Unfortunately, the problem with CTRL+C is worse than that. SetConsoleCtrlHandler(NULL, FALSE) don't work on Johnny. We get killed with it too, maybe it's Qt's fault. 
> Also, CTRL+C, even without the SetConsoleCtrlHandler(NULL,FALSE) doesn't work on John, it never get into the corresponding method even though the code looks great in john. I've done multiple combinations for some days and I've never sent a CTRL_C_EVENT that seemed to do the right thing. However, CTRL_BREAK did. It's weird because john treats all CTRL_XXX event the same so my hypothesis is that it is not sent/ignored by windows like the guy on stackoverflow said.


[ CONTENT OF TYPE application/octet-stream SKIPPED ]


Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ