Block Control+Alt+Delete

Question

Hi, I'm doing an Online Quiz project in C#. The test client is a Windows Desktop Application running on Windows XP. I need to block the control+alt+delete key combination to prevent students from minimizing/closing the application. I know this question has been asked a million times, but I'm simply unable to find a working solution. Using PInvoke is okay for me. Could you please provide some info/links to info about this? I know this is definitely possible because I've seen 3 applications doing this,but they're all proprietary, so I have no way of knowing how it was done. Thanks Evans

Answer 1

What do you really want to do ? Disable the task manager ?

Hive: HKEY_CURRENT_USER
Key: Software\Microsoft\Windows\CurrentVersion\Policies\System 
Name: DisableTaskMgr
Type: REG_DWORD
Value: 1 disable

But the user can still close your app with a third party task manager.

The proprietary application might "disable Ctrl+Alt+Del" using this registry key :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe, Debugger, Hotkey Disabled

Answer 2

There're three ways of doing it (registry, administrative templates and hooks) described in this article.

The code is in C++, but it will be easy to port it to C# with P/Invoke.

Answer 3

I found a very ugly way of doing this (which works well). If I open taskmgr.exe exclusively, than nothing happens when the user presses Ctrl+Alt+Del.

FileStream fs = new FileStream(System.IO.Path.Combine(Environment.SystemDirectory, "taskmgr.exe"), FileMode.Open, FileAccess.ReadWrite, FileShare.None);

What I like the most about this solution that it has no permanent effects. For example if the application gets killed than Ctrl+Alt+Del will just work again.

Drawback: One must have the Welcome screen enabled or Windows Security will popup instead of Windows trying to open taskmgr and silently failing. (→ It also won't work if the machine is in a domain, because being in a domain disables the Welcome screen.)

(Of course this won't work on Vista and W7.)

Answer 4

For Windows XP, the correct way to do this is to create your own Graphical Identification and Authentication Dynamic Link Library, or gina.dll for short. Here's an MSDN article about it. This DLL exports a set of functions that interact with the Winlogon process and provides the user interface to logon requests - the Secure Action Sequence event. The main logon request is the ctrl-alt-delete response. The standard gina.dll invokes the logon screen or the task manager/logoff dialog. It's not too difficult to create your own gina but it does require C/C++ coding and not C# and it is quite easy to make the system fail to boot. This does not stop people from pressing F8 at boot up and selecting the Safe Boot option, which won't load the custom gina.dll.

EDIT: I should also say that you don't need to implement all the functions the gina is required to implement, you can dynamically load the previous gina.dll and pass all the calls you're not interested in to the old gina.dll.

EDIT 2: This does not work with Vista/Win7 as they changed the architecture of the logon process. It is still possible to disable ctrl-alt-delete in Vista/Win7 but it requires a different mechanism - there are MSDN articles about it somewhere.

EDIT 3: Here's a ZIP file containing the source code to make a gina.dll It was built using DevStudio 2005. The file GinaInterface.cpp details the steps needed to install the new gina.dll library. This will disable the "Welcome" screen and replace it with the 'press crtl-alt-del' to login dialog. As it stands, there is no difference between this and a standard gina.dll, all the gina related calls are passed through to the original gina.dll file (called msgina.dll in the Windows\System32 folder). To disable the ctrl-alt-del key press, update the function WlxLoggedOnSAS in GinaInterface.cpp. To stop ctrl-alt-del whilst your application is running, you could create a named mutex (CreateMutex) and test for its presence in the gina.dll, stopping ctrl-alt-del if the mutex exists.

Answer 5

According to the Windows Internal book (4th edition), Ctrl-Alt-Del sequence cannot be intercepted by non-privileged applications. Also, it is said that this particular sequence cannot be intercepted and that the Winlogon process will always receive it (page 529).

I never tried to do this, however, but I would trust the book :)

Answer 6

Alternate solution:

Make the app so you never need to use the alt or ctrl key.

Then, take out the Ctrl (or alt) key and put paper on the contacts.

Tada!

(just use another keyboard for maintenance)

Answer 7

A very dumb solution (which assumes that the machine is dedicated your software) is to remap the Alt key (to nothing).

Drawbacks:

• Permanent effect
• Requires a restart/logoff to activate

Works on xp, Vista, W7.

You can use SharpKeys to remap/disable any key.

For info on what registry key SharpKey changes see this. One can also remap on a per user basis.

Warning: If you disable the Alt key and login requires you to press Ctrl+Alt+Del than you won't be able to login. :)

Answer 8

I achieved a similar goal, but with a different tactic in a Time Tracker tool I whipped up. This will give you a form which takes over the screen - doesn't allow windows to appear on top of it and will shoot down task manager if it is started.

1. Set your form TopMost = True.

2. override the Form.OnLoad method like so:

   protected override void OnLoad(EventArgs e)
   {
       base.OnLoad(e);
       this.Location = SystemInformation.VirtualScreen.Location;
       this.Size = SystemInformation.VirtualScreen.Size;
   }
   

3. Create a timer, with a 500 millisecond interval, which looks for, and kills "taskmgr.exe" and "procexp.exe".

4. Override the Form.OnFormClosing:

   protected override void OnFormClosing(FormClosingEventArgs e)
   {
       if (e.CloseReason == CloseReason.UserClosing || e.CloseReason == CloseReason.FormOwnerClosing)
       {
           MessageBox.Show("Nice try, but I don't think so...");
           e.Cancel = true;
           return;
       }
       base.OnFormClosing(e);
   }
   

5. Override OnSizeChanged:

   protected override void OnSizeChanged(EventArgs e) {
       base.OnSizeChanged(e);
       this.WindowState = FormWindowState.Normal;
       this.Location = SystemInformation.VirtualScreen.Location;
       this.Size = SystemInformation.VirtualScreen.Size;
       this.BringToFront();
   }
   

Answer 9

You'll also want to block alt+F4 with something like this:

private void form_KeyDown(object sender, KeyEventArgs e) {
    if (e.KeyCode == Keys.F4 && e.Modifiers == Keys.Alt)
        e.Handled = true;
    base.OnKeyDown(e);
}

Answer 10

I wonder if you could install a filter on the keyboard driver?

I know on USB interfaces, you can install an upper or lower filter to the USB data to intercept it as it arrives on the computer, and perhaps a similar approach could be taken. Essentially, you would modify the key combinations coming from the keyboard as long as your testing application is running.

I did find an 'UpperFilters' registry key defined for my keyboard...

This USB sniffer comes with source code that implement a filter. It may be usable in the context of a keyboard sniffer / modifying filter. (Download link)

Answer 11

I would suggest other way to disable Task Manager, works well with Windows 7 yet it just affects task manager option. The solution is to set following registry key to irrelevant value, like "C:\"

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe\Debugger

You can also use this hack to start your own task manager, just by setting Debugger key to full path of your application. I have discovered this by analysing how ProcessExplorer replaces TaskMgr.

Answer 12

As pointed out in the other answers, there is no secure way of accomplishing this without checking each student's computers, because they could always run a VM.

As an alternative, have you considered burning your app to a LiveCD and requiring students to boot the LiveCD?

That way, you control their OS as long as they are running your app. Once done, they can reboot and everything's back to normal.

Of course, students could reboot their laptops inbetween, but that would probably take long enough to be noticed by the supervisors.

The VM solution would still trick this, so you'd need to make sure everyone really boots from the CD; otherwise I cannot think of any way around this.

As a bonus, you'll be isolated from any weird OS problems on the student's laptops (maybe some installed Linux or OS X ;-) ) .