I am 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.
Using PInvoke is okay for me.
I know this is definitely possible because I have seen three applications doing this. They are all proprietary, so I have no way of knowing how it was done.
I found a very ugly way of doing this (which works well).
If I open taskmgr.exe exclusively, then 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, then 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 or W7.)
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.
As other people have mentioned it's very hard to block Ctrl-Alt-Del, as it's a fundamental part of Windows security.
However you can block what can be done after Ctrl-Alt-Del has been pushed by adding the following registry keys.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System
DisableTaskMgr
DisableChangePassword
DisableLockWorkstation
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
NoLogoff
If you do this then when you push Ctrl-Alt-Del you will get a dialogue like the following (under XP):
It's not fool-proof, but it stops the user from doing some basic things.
Update: Just realised that this also blocks Ctrl-Shift-Esc, which I didn't realise before.
You can pre-run the hidden process taskmgr.exe
ProcessStartInfo psi = new ProcessStartInfo(System.IO.Path.Combine(Environment.SystemDirectory, "taskmgr.exe"));
psi.RedirectStandardOutput = false;
psi.WindowStyle = ProcessWindowStyle.Hidden;
psi.UseShellExecute = true;
processTaskMgr = Process.Start(psi);
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.
Set your form TopMost = True.
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;
}
Create a timer, with a 500 millisecond interval, which looks for, and kills "taskmgr.exe" and "procexp.exe".
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);
}
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();
}
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.
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
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 :)
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 ;-) ) .
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)
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);
}
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)
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.
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. :)
Related
I'm working on an app (Written in C#) that have a setting to run on KIOSK mode. I've just an challenge here which is disabling Ctrl+Alt+Del combination Event.
There is no right answer in the similar past posts. Please let me know about the right action.
Considering, my code is working with registry keys to disable/enable options, if you know any registry key,it will be more helpful.
CTRL+ALT+DEL is the secure attention sequence of Windows NT (and its derivatives like Win7). It is the one key combination that is guaranteed to get the OS's attention. The whole point of the SAS is that it can't be intercepted or stopped by user programs.
One security issue it addresses is that of a false login screen: consider a screen that looks exactly like the normal Windows login screen. There's no way to tell that it's a fake just by looking at it. But, if you're in the habit of always pressing CTRL+ALT+DEL before logging in (there is an option to always require it for the legitimate screen), pressing the SAS on a false login screen will bring up task manager or the secure attention screen (with the log off, change password, etc options). The real login screen doesn't do that; it just stays there on the screen. As long as the OS itself isn't replaced or compromised, CTRL+ALT+DEL will protect you from false login screens. If a user program could intercept the SAS, it wouldn't be worth anything.
The SAS was baked into the Windows NT design right from the beginning (it was in the first release in 1993), so getting around it won't be easy. I'm sure there are keyboard filter drivers-- or something to intercept that sequence-- that are designed for kiosk use.
It is not possible to capture CTRL+ALT+DEL, it is so by design in all Windows systems. This is a security issue, if the user hits CTRL+ALT+DEL, he or she should be certain that it is the operating system and not some application (possibly a password-catching trojan) that responds to it.
I guess to capture CTRL+ALT+DEL you would need to write a device driver of some sorts.
Edit: Also see This answer. I did not try it, but the question is fairly similar.
Although it is sort of possible, it is not an easy task and not something that can be done in C#. This Article will show you how to disable CTRL+ALT+DEL using group policy editor. To permanently disable the combination though, you will either need to write your own keyboard driver or write your own GINA stub (Graphical Identification and Authentication).
It is possible to pick up the CTRL+ALT+DEL combination, but not to disable it.
I tried to disable it with SetWindowsHookEx and WH_KEYBOARD_LL and you can successfully get notified when CTRL+ALT+DEL is pressed, but you cannot do anything about it.
It is possible to block CTRL+ALT+DEL combination. However, you can't really disable it. As far as I know, there are two possible methods.
Remapping the keyboard layout. There is a registry binary key that allows you to remap keyboard layout:
HKLM\System\CurrentControlSet\Control\Keyboard Layout\Scancode Map
Please check this out: Disabling Windows Hot Keys
This method can be dangerous, but I haven't noticed any side effects this method can cause. The CTRL+ALT+DEL combination is handled by winlogon.exe. If your process has administrative privilege, you can suspend winlogon.exe. Hence, it cannot process the hotkey and nothing will happen if the user presses CTRL+ALT+DEL.
Please check this out: C++ code to disable CTRL+ALT+DEL.
You will need to do some P/Invoke, in user32.dll, there's a method called SystemParametersInfo, check out these resources for more info
http://pinvoke.net/search.aspx?search=SystemParametersInfo&namespace=[All]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724947%28v=vs.85%29.aspx
I did something similar a long while back, but no longer have the code, though I did find this (it's in vb6), but it shouldn't be too hard to get the idea and translate to .NET
http://www.developerfusion.com/code/1021/how-to-disable-ctrlaltdel/
I have what seems to be a common problem. I am running Windows 7 Home Premium on one of the most awesomest computers (when it was bought last year) and certain visual effects just automatically turn themselves off.
My average user experience rating is high, so it doesn't explain why this happens. The only feature that ever gets turned off is the 'Show window contents while dragging' option. And it really annoys me.
There are currently no working solutions to this problem online. Other than to "there must be a conflict with another app installed on your machine."
And yes, I do know what app is causing this conflict. It's my bloody Internet Provider's software - you know... that app that you absolutely MUST have open at all times when you're connected to the net.
So, I had a thought. What if I could subscribe to an event so that my app that runs in the background will detect when this 'show window contents while dragging' option is turned off - and then my app will simply turn it back on again.
When I do this manually, it seems to stay in effect for about an hour or two, then it gets switched off again.
Is it possible to handle these types of events, and re-start certain visual effect features? If so, are there any resources on this?
I have not been able to find anything on this sibject yet.
Yes the WM_SETTINGSCHANGE message is sent to all windows when a system setting is changed. Then you can call SystemParametersInfo with SPI_GETDRAGFULLWINDOWS to determine if the "Show window contents while dragging" is disabled and use SPI_SETDRAGFULLWINDOWS to enable it.
So all that you will need to do is create an application with a form (that can even stay hidden) and override the forms WndProc and handle the WM_SETTINGSCHANGE message and call SystemParametersInfo using p/Invoke. The p/Invoke definition for SystemParamtersInfo is available at pinvoke.net
Altough what may be easier is change security on the HKCU\Control Panel\Desktop\DragFullWindows registry value so that it can't be changed.
I have to run my C# application that I wrote it recently on several computers with window 7 operating system. Here is a big challenge with it, Application must run on startup and user must not be able to work with anything else such as windows hotkeys, other applications, some directories and etc.
Considering I don’t want to kill any process or service as less as possible, Please give me the best solution.
Thanks and waiting
Maybe A little more information will help
did you see Devices like ATMs or Medical devices that window is running on? Those devices don't allow user to manipulate with desktop or anywhere else, I want their solution. . . my Application Will run as a device handler(A Medical Device in Operating room).
You probably shouldn't write such an application in the first place (nagware?).
Anyway. I think what you are looking for is actually "kiosk" software. Here is blog entry that describes how to lock down the computer to effectively run in "kiosk mode".
Note however, that not every application can (or should) be used in that mode. Either because it has loopholes that still allow you to do thing (for example the file open/save dialog still allows you to create directories or navigate the file system), or because they were simply not designed with that goal in mind.
This sounds actually like a (very) bad idea to me...
You could probably hook every Keyboard event so you disable OS shortcut (Windows + D, Windows + E...). See here.
Also hide the Windows taskbar.
Make sure your application starts with Windows.
This sounds a bit hacky to me...
A program with the properties you mention is called a (very restrictive flavour of) shell. So you need to register your program as a shell (instead of explorer.exe) for the poor, poor user you want to restrict.
You might look into using a local group policy to enforce this restriction. Check this out.
How can I disable Print Screen functionality while my WPF application is running?
The use-case is that my client wants to avoid unnecessary replication of valuable patient-centric data from the outside world and they provide the physical security to keep people from taking data through non-digital means.
Okay, it is possible, and could indeed be useful if your application is deployed in an environment where a camera is not available to the user.
First of all, I used the RegisterHotKey and UnregisterHotKey API calls, documented here http://pinvoke.net/default.aspx/user32.RegisterHotKey as described in this rather old article here http://msdn.microsoft.com/en-us/magazine/cc163713.aspx.
I registered the IDHOT_SNAPDESKTOP hotkey in the Window_Load event and unregistered it in the Window_Closed. Trying to do this in the constructor gave me problems getting a consistent handle with the WindowInteropHelper(this) method.
If you'd like to do more than just ignore the keys you can set up a windows message handler, making a kind of WndProc using,
HwndSource source = HwndSource.FromHwnd(<handle>);
source.AddHook(<WndProc>);
making the handle as described above, and the WndProc implementation yourself.
As yet, I don't know how to "not" handle the hot key and get windows to perform its normal behaviour except, of course, by unregistering the hotkeys.
Its not very elegant or "WPF" but it worked for me.
As #ghord comments
The use of EnsureHandle() looks useful for getting a handler in the constructor.
It's not possible to disable printing, and even if it were possible, it would be easily circumvented by a cell phone camera. Many are in the megapixel resolution range, making it quite easy for someone to get the information they want.
If you want to disable the Print Screen Key on your keyboard, Jodrell's answer gives a way of doing that (understanding that it's not going to keep people from printing, and a determined user will find a way around that).
Really, it all comes down to trust. If an employer can't trust their employees not to remove data that is already protected by law in most jurisdictions (HIPAA in the USA), then there's a bigger issue at stake.
Easy:
Windows.UI.ViewManagement.ApplicationView.GetForCurrentView().IsScreenCaptureEnabled = false;
Simply speaking, you cannot. "Print screen" just copies the pixels on the screen to the clipboard, and is not part of your application.
Basically you can hook to the ClipBoard events and then set the image copied to null if someone does it. So they can copy the image but it will be reset:
Have a look at this:
Clipboard event C#
Alternatively in a timer, check the content of the clip board and clear it as soon as it is set to a picture.
No, No way to do that. Even if you capture the Print Screen key in your application user might set focus to some other application and then do the Print screen(having your application on side etc.).
Only way would be to create a dummy application in background which captures all keystrokes using Keyboard Hooks and filters Print Screen, but that will happen for all applications not just yours. And moreover as George said user can use cellphone camera too!
I think Microsoft Rights Management System can help. Give it a try. Following is the link:
Microsoft Rights Management System
The only way I can think of is to use the native Windows API (SetWindowsHookEx) to catch all keystrokes and filter out the PrintScreen key. However this would involve creating a native (i.e. unmanaged) DLL to actually do the keystroke processing.
I have a windows form application which needs to be the TopMost. I've set my form to be the TopMost and my application works as I'd like it to except for in one case.
There is a 3rd party application (referred to as player.exe) that displays SWF movie files on a portion of the screen that popup on top of my application.
Using Process Monitor I determined that player.exe application calls
flash.exe <PositionX> <PositionY> <Width> <Height> <MovieFile>
in my case:
flash.exe 901 96 379 261 somemovie.swf
Since flash.exe is being spawned in a new process after my form has been set to the TopMost it is appearing on top of my application.
First thing I did was make my application minimize the player.exe main application window hoping that this would prevent the Flash from appearing also. But, unfortunately it doesn't... even with the window minimized whenever the flash movie starts it shows up at the pixel location (901,96). I then tried creating a timer to keep setting the form.TopMost property to true every 10ms. This sort of works but you still see a very quick blip of the swf file.
Is there some type of Windows API call which can be used to temporarily prevent player.exe from spawning child processes which are visible? I admit it sounds a little far fetched. But, curious if anyone else has had a similar problem.
Addendum:
This addendum is to provide a reply to some of the suggestions layed out in Mathew's post below.
For the emergency situation described in the comments, I would look at possible solutions along these lines:
1) How does the third party application normally get started and
stopped? Am I permitted to close it
the same way? If it is a service, the
Service Control Manager can stop it.
If it is a regular application,
sending an escape keystroke (with
SendInput() perhaps) or WM_CLOSE
message to its main window may work.
Easiest way to close the app is to CTRL-ALT-DEL, then kill process. -OR-
The proper way is to Hold ESC while clicking the left mouse button... then input your username and password, navigate some menu's to stop the player.
There is no PAUSE command... believe it or not.
I don't think using WM_CLOSE will help since minimizing the application doesn't. Would that kill the process also? If not, how do you reopen it.
2) If I can't close it nicely, am I permitted to kill it? If so,
TerminateProcess() should work.
I can't kill the process for two reasons. 1) Upon relaunch you need to supply username/password credentials... There may be a way to get around this since it doesn't prompt when the machine is rebooted but... 2) Whenever I kill the process in task manager it doesn't die gracefully and asks if you want to send an error report.
3) If I absolutely have to leave the other process running, I would try
to see if I can programmatically
invoke fast user switching to take me
to a different session (in which there
will be no competing topmost windows).
I don't know where in the API to start
with this one. (Peter Ruderman
suggests SwitchDesktop() for this
purpose in his answer.)
I got really excited by this idea... I found this article on CodeProject which provides a lot of the API Wrapper methods. I stopped implementing it because I think that in order for desktop's to work you must have explorer.exe running (which I do not).
EDIT2: On second thought... maybe explorer.exe isn't needed. I'll give it a try and report back.
Edit3: Was unable to get the code in that article working. Will have to put this on hold for a moment.
Answer Summary
As one might have expected, there is no simple answer to this problem. The best solution would be to problematically switch to a different desktop when you need to guarantee nothing will appear over it. I was unable to find a simple C# implementation of desktop switching that worked and I had a looming doubt that I would just be opening a whole new set of worms once it was implemented. Therefore, I decided not to implement the desktop switching. I did find a C++ Implementation that works well. Please post working C# virtual desktop implementations for others.
Setting the TopMost property (or adding the WS_EX_TOPMOST style to a window) does not make it unique in the system. Any number of topmost windows may be created by any number of applications; the only guarantee is that all topmost windows will be drawn 'above' all non-topmost windows. If there are two or more topmost windows, the Z-order still applies. From your description, I suspect that flash.exe is also creating a topmost window.
Aside from periodically forcing your window to the top of the Z-order, I think there is little you can do. Be warned, however, that this approach is dangerous: if two or more windows are simultaneously trying to force themselves to the top of the Z-order, the result will be a flickering mess that the user will likely have to use the task manager to escape.
I recommend that your program not attempt to meddle with other processes on the computer (unless that is its explicit purpose, e.g. a task manager clone). The computer belongs to the user, and he may not value your program more highly than all others.
Addendum:
For the emergency situation described in the comments, I would look at possible solutions along these lines:
How does the third party application normally get started and stopped? Am I permitted to close it the same way? If it is a service, the Service Control Manager can stop it. If it is a regular application, sending an escape keystroke (with SendInput() perhaps) or WM_CLOSE message to its main window may work.
If I can't close it nicely, am I permitted to kill it? If so, TerminateProcess() should work.
If I absolutely have to leave the other process running, I would try to see if I can programmatically invoke fast user switching to take me to a different session (in which there will be no competing topmost windows). I don't know where in the API to start with this one. (Peter Ruderman suggests SwitchDesktop() for this purpose in his answer.)
You can use the Process class to start flash.exe directly - and use an appropriate ProcessStartInfo settings to show the window in a hidden state - or with a WindowStyle of hidden or minimized.
You could also consider using the SetWindowsHookEx API to intercept the process start API calls, and when the process is flash.exe run some code to restore you window to top-most status.
Matthew's answer is excellent, but I suspect you may be asking the wrong question. Why does your application need to be topmost? If you're trying to create a kiosk or some such, then topmost is not the way to go.
Edit: After reading your response to Matthew's comment, I'd suggest creating a new desktop and switching to it before displaying your alert. (See CreateDesktop and SwitchDesktop in MSDN.)