ctrl+alt+del

I have searched the net all over, everywhere, but have given up hope. I'm looking for a way to disable the CTRL+ALT+DEL Keystrokes on Windows NT/2000/XP, but all I find is ways to do it with Windows 9x/ME and so forth. I know I can disable many keystrokes on Windows NT based systems, heck, EVERYTHING but CTRL+ALT+DEL.

I know there is a way to do it, because I have seen demostrations of it in other security related applications. But nobody on this entire Internet seems to be willing to share his/her knowledge about it. Hopefully I will find such a person in this forum.

Thanks.

There's no way to do it, I don't think. NT gets first dibs on Ctrl-Alt-Delete because it's used to verify password integrity (i.e. you can guarantee you're giving your password to the OS because only the OS can get C-A-D).

Maybe hooks will solve this problem? There is a new hook called WH_KEYBOARD_LL in NT/2000/XP. Here is what MSDN tells about it:

Quote:

---

The LowLevelKeyboardProc hook procedure is an application-defined or library-defined callback function used with the SetWindowsHookEx function. The system calls this function every time a new keyboard input event is about to be posted into a thread input queue. The keyboard input can come from the local keyboard driver or from calls to the keybd_event function. If the input comes from a call to keybd_event, the input was "injected".

---

Maybe it'll allow us to capture & deny any low-level keyboard message directly from the keyboard driver. I have already tried the WH_KEYBOARD hook but it still allows the system to capture any keyboard event that is sent to open Start Menu or to respond to C+A+D (might be others too). Right now I can't use WH_KEYBOARD_LL because my header files aren't updated so I'll have to go through the hazzle of first installing the latest SDK and then testing it.:(

I have already tried the Low Level Keyboard Hook. I tried it with Win 2K and XP. I even let the function return the value TRUE no matter what, it still won't intercept c-a-d. :( The only way i think this might be possible is through some goofy direct hardware access or keyboard driver messing. I don't know much about that stuff. (Maybe a bios call or sumthin?)

Trust me, it's not going to let you catch Ctrl-Alt-Delete...

do you mean the hardware/bios/kb-driver thing or the "Low Level" thing?

I think you're going to have to write your own device driver to catch it. The idea I think is that no normal software program (not even a service) can intercept Ctrl-Alt-Delete because it's used by the security features.

Device drivers are another matter.

I really hate to say this, but... I don't think I'm so eager to get into learning how to write vxd's and stuff. *sigh* so much hassle. but if it needs be, well, do i have any choice? the other question is, how long does it usually take to learn that stuff?

And after all the hassle of writing it, I doubt if I'll be able to install and use it dynamically while running windows (without having to restart).

Windows Virtual Machine can pick it up... IE, if you press Ctrl-Alt-Del in a WVM session, WVM warns you and tells you to use Ctrl-Alt-End instead. Mind you, since that software is Microsoft based, they'd know the workaround.

and yet so reluctant to share... :o:). After all, they put the feature into NT specifically and intentionally to guard it, otherwise NT would not have been NT, now would it?

If WVM can get around it (even on NT) surely it must be possible. Have you tried that code which apparently makes Windows thinks there is a screen saver active, disabling keys like Alt+Tab and Ctrl+Alt+Del. I haven't tried it on Win2k or WinNT, but I know it works on Win98/Me

That "secure screen saver" thing only works on Win9x/ME based OS'es. I tried a system wide keyboard hook which intercepts keyboard input, and it works quite well, except for major system keys like alt-tab, the windows key and c-a-d. I even tried the low-level keyboard hook, but without success.

But after all this struggling, in the end it MUST be possible, because everything is. We just need the right "code". It is most likely NOT going to be VB code. C++ is a bit more likely to be it, but ASM code is the most likely thing that may do the trick. But about ASM code I know nothing. :rolleyes: *sigh*.

Win NT based OS'es installs a "VERY low level keyboard interceptor" when it loads on startup. It does this at a very early time through some dll called the "gina" dll. It is responsible for security regarding NT user password input. Requiring c-a-d to enter your password at login helps keep your pwd secure because, when you press c-a-d, the gina thing is supposed to be the first process to intercept it and then acts on it first, so you can be sure your password only goes to NT, and not some other keyboard catching program that may try to steal your password. Modifying the "gina" dll, replacing it with your own, is a partitial answer, but is not exactly what I want.

I need this at "run time", without having to replace the "gina" thing. I may be wrong, but somewhere in my mind, I recall hearing (or reading) something about replacing the keyboard driver, at run time, and then change it back when finished. I don't remember where I saw or read it. Nevertheless, I'm not very into writing driver stuff. :(

Sounds too low level for me to intefere. Last time I went that low level I had to reinstall my whole machine.. Actually I chucked it out and bought a new one. Never gonna go there again!

I discovered a way to disable the Task Manager. It can be done through setting a certain registry key.
This key is located at "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System --> DisableTaskMgr"
Set this to '1' to disable the Task Manager button on the SAS window, and set it to '0' to enable it again.
But this method can have undesired results, for instance, when this value is set to '1' in the registry while my program is running, and there is a sudden power failure, what will an inexperienced user do if (s)he does not know that (s)he can fix the problem by running my program and quiting it again? So... when I discovered this flaw, I decided that using this method is not that appropriate for me. I MUST find a way to disable Ctrl+Alt+Del completely instead.

I think I have an idea of how it might be possible, but... the other possiblity is that my idea is the stupidest suggestion ever. :D :D :D ... so any comments will be greatly appreciated. ;) But before replying to my post here, please read ALL of it, so that you won't come to any conclusions about my appearantly "bad/stupid" ideas too early. :) Thanks.

Anyway... Dreamlax, I gave some thought on what you said about WVM and Microsoft knowing the workaround. After some brain-storming I came to the conclusion that using the "gina" dll thing to make c-a-d unavailable in "run time", might be possible. But for me to be sure, I must have the original code of the "msgina.dll" and know how it works.

I was thinking that maybe... just maybe, there is some function in msgina.dll that can be called, or some kind of hook procedure or something, inside msgina.dll that can get a certain kind of special formatted message that allows it to ignore Ctrl+Alt+Del. Just take this scenario for example.

If msgina.dll installs some interrupt hook thingy at a very low level in memory or something, that intercepts c-a-d, then surely it should interrupt and execute the interrupt handler (procedure) EVERYTIME you press c-a-d. So... for Windows to make sure it doesn't spawn a new security window everytime you press it, there must be a variable somewhere in the memory that tells gina that c-a-d has already been handled, and not to handle it again. If we could somehow access that specific variable in memory (with read/write access), we can fool gina into thinking it has already handled c-a-d and ignore it.

So... how can that variable be accessed...? (without causing access violations or illegal operations and stuff.) Surely, some hardcore coder must know how to bypass Win NT's denying of direct hardware/memory access. Someone told me that he is sure it is just a registry setting, but I'm not so sure about that.

And lets say it is NOT possible through direct hardware/memory access... perhaps the variable is volatile? (i.e. It can be accessed/modified by external factors such the OS or a hardware device.) How about calling a public/exported dll function in msgina.dll that sets that specific variable FOR us (if it is not volatile)?

If not through msgina.dll, then maybe through one of the DLL files that msgina.dll depends on?

I made a list of possible files:

MSGINA.DLL
MSVCRT.DLL

KERNEL32.DLL {mwuahahah, it is very unlikely, but who knows, maybe M1cr0$oft put it there because they thought we wouldn't look or suspect that it might be there... lol.}

NTDLL.DLL
ADVAPI32.DLL
USER32.DLL {another unlikeliness}
NETAPI32.DLL
GDI32.DLL {another unlikeliness}
USERENV.DLL
SHELL32.DLL
SHLWAPI.DLL
COMCTL32.DLL {lol}
WINSTA.DLL
RPCRT4.DLL
ODBC32.DLL {whoaaa !!! this is very interesting, but it DOES seem to be a dependancy :)}

And let's say for instance one of those files DOES contain the function or variable, maybe Microsoft gave it a misleading name to prevent clueless dudes (like me :P) from messing with it?

This was just an idea/thought I had. Any comments would be greatly appreciated.

Thanks.

jovton
mailto:[email protected]

P.S. Anyone know where I can get the code for WVM? :D

The memory protection is implemented on its lowest level by the cpu itself. I doubt any hardcore coder can bypass this protection.
msgina.dll probably runs in kernel mode, so you'd have large difficulties getting into it.
Variables are not exported by dlls.

You can load msgina.dll into the dependency viewer and look at all the functions. Maybe one of them suits your needs, though I doubt it.

Why do you want to disable C-A-D? Which programs do it that you've seen?

I agree with CB. You can REALLY piss off users if your program locks up and then they can't kill it - they could lose all their work in other open programs. BAD PLAN. You should re-think your design unless you're working for NSA or DOE or some other place with sky-high security requirements.

:D

Quote:

---

Originally posted by CornedBee
The memory protection is implemented on its lowest level by the cpu itself. I doubt any hardcore coder can bypass this protection.

---

Only if told to ;)