In response to the many requests from VB (and other languages) coders, I finally took some time to update the project and move all the functions into a DLL so that any program developed in a language capable of calling Windows standard libraries (DLLs) can use them. To demonstrate these functions, I also included C and a VB projects.
I manage a system where I need to restrict users from accessing the desktop and running other applications. The search for ways to achieve this returned several different techniques. Although in the end I didn't use any of the techniques described here, I decided to compile all the code in one application for everyone who should need it.
Note: I don't claim to be the author of any of the code presented in this article. The application is a compilation of several sources and I will try to acknowledge the authors whenever possible.
I. Hiding Desktop Windows
Hiding the Windows Desktop, Taskbar, Start Button,..., is generally achieved by passing the window handle returned by
If, for example, you want to hide the Taskbar, you can use the following code:
ShowWindow(FindWindow("Shell_TrayWnd", NULL), SW_HIDE);
If you want to hide the Start Button, you have to know the button control ID first and use the same technique:
How do I know that the Taskbar class name is "
Shell_TrayWnd" or that the Start Button id is 0x130? I used the Spy++ utility that comes with Microsoft Visual C++ 6.0. You can use this technique for any window or control you wish to hide.
If you want just to disable the window, and not hide it, change the
ShowWindow() call to
You will see that if you hide the Desktop and the Taskbar, the Start Menu still pops up when you press the Win key or double click the desktop area. To find out how to prevent this unwanted behavior, you have to read the next section.
II. Disabling System Keys
I call system keys all the special key combinations that the operating system (OS) use to switch between tasks or bring up the Task Manager.
There are several ways to disable these key combinations.
You can disable all these key combinations (including Ctrl+Alt+Del) by fooling the operating system into thinking the screen saver is running. This can be accomplished with the following code:
SystemParametersInfo(SPI_SETSCREENSAVERRUNNING, TRUE, &bOldState, 0);
This trick doesn't work in Windows NT or higher (Win NT+), so you need other techniques.
In Win NT+, one way to trap key switching combinations is to write a keyboard hook. You install a keyboard hook by calling
hKeyboardHook = SetWindowsHookEx(WH_KEYBOARD, KeyboardProc, hInstance, 0);
function is a callback function that is called by the OS every time a key is pressed. Inside
KeyboardProc(), you decide if you want to trap the key or let the OS (or the next application in the hook chain) process it:
if (Key == VK_SOMEKEY)
return CallNextHookEx(...); }
To release the hook, you use:
There are two type of hooks: local and global (or system wide) hooks. Local hooks can only trap events for your application, while global hooks can trap events for all the running applications.
To trap the switching task keys, it's necessary to write a global hook.
The Microsoft documentation states that global hook procedures should be placed in a separate DLL. The DLL is then mapped into the context of every process and can trap the events for each process -- that's why hooks are used to inject code into a remote process.
In my application, I wanted to avoid the use of an external library, so I set the global hook inside my own application (without an external library). This is accomplished by passing in the 3rd parameter of the
SetWindowsHookEx() call, the instance handle of the application (and not the library as the documentation states). This technique works perfectly for Win 9x but Win NT+ is different. The same effect can be achieved by using the new keyboard and mouse low level hooks. These new hooks don't need an external library because they work differently from the other hooks. The documentation states "[...] the
WH_KEYBOARD_LL hook is not injected into another process. Instead, the context switches back to the process that installed the hook and it is called in its original context. Then the context switches back to the application that generated the event.".
I'm not going into more details about hooks because there are many excellent articles dealing with this subject.
There's still one remaining problem: keyboard hooks cannot trap Ctrl+Alt+Del sequence! Why? Because the OS never sends this key combination to the keyboard hook chain. It is handled at a different level in the OS and is never sent to applications. So, how can we trap the Ctrl+Alt+Del key combination? Read the next section to find out.
There are several ways to disable this key combination:
- Disable Task Manager. This doesn't trap the key combination, it simply disables the application (Task Manager) that pops up when this key combination is pressed. See below how to do this.
- Trap the keys using a keyboard device driver. For this, you need the DDK installed. I will not describe this method here.
- Write a GINA stub. GINA is the DLL that Winlogon uses to perform user authentication. I'm not going to discuss this method here, but you can find out how to do it here .
- Subclass the SAS window of the Winlogon process. For this, you must inject code into the Winlogon process and then subclass its Window Procedure. Two techniques for doing this are described later.
Disable Task Manager
To disable the Task Manager, you only have to enable the policy "Remove Task Manager", either using the Group Policy editor (gpedit.msc) or setting the registry entry. Inside my application, I used the registry functions to set the value for the following key:
Set it to 1 to disable Task Manager and 0 (or delete key) to enable it again.
Subclassing Winlogon's SAS window
You subclass a window's procedure by calling:
SetWindowLong(hWnd, GWL_WNDPROC, NewWindowProc);
The call only works for windows created by your application, i.e., you cannot subclass windows belonging to other processes (the address of
NewWindowProc() is only valid for the process that called the
So, how can we subclass Winlogon SAS window?
The answer is: you have to somehow map the address of
NewWindowProc() into the address space of the remote process and pass it to the
The technique of mapping memory into the address space of a remote process is called Injection.
Injection can be accomplished in the following ways:
- Registry. To inject a DLL into a process, simply add the DLL name to the registry key.
This method is only supported on Windows NT or higher.
- Injecting a DLL using hooks. This method is supported by all Windows versions.
- Injecting a DLL using
LoadLibrary(). Only usable in Windows NT or higher.
- Copy the code directly to the remote process using
WriteProcessMemory() and start its execution by calling
CreateRemoteThread(). Only usable in Windows NT or higher.
My preferred injection technique is the last one. It has the advantage of not needing an external DLL. To properly work this method requires very careful coding of the functions you are injecting onto the remote process. To help you to avoid common pitfalls of this technique, I inserted some tips at the beginning of the source code. For people who think this method is too dangerous, I included also the
LoadLibrary() method. Just
#define DLL_INJECT and the application will use this method instead.
After injecting the code into Winlogon's subclassing, the SAS window reduces too:
- Getting the SAS window handle:
hSASWnd = FindWindow("SAS Window class", "SAS window");
- Subclass the SAS window procedure:
SetWindowLong(hSASWnd, GWL_WNDPROC, NewSASWindowProc);
NewSASWindowProc(), trap the
WM_HOTKEY message and return 1 for the Ctrl+Alt+Del key combination:
LRESULT CALLBACK NewSASWindowProc(HWND hWnd, UINT uMsg,
WPARAM wParam, LPARAM lParam)
if (uMsg == WM_HOTKEY)
if (lparam == MAKELONG(MOD_CONTROL | MOD_ALT, VK_DELETE))
return CallWindowProc(OldSASWindowProc, hWnd, wParam, lParam);
I only managed to disable Alt+Tab and Alt+Esc key combinations using this method.
In all the versions I tried, this method never worked!
3. Switch to a new desktop
With this technique, you create a new desktop and switch to it. Because the other processes (normally) run on the "Default" desktop (Winlogon runs on the "Winlogon" desktop and the screen saver runs on the "Screen-saver" desktop), this has the effect on effectively locking the Windows desktop until the process that runs in the new desktop has finished.
The following code describes the steps necessary to create and switch to a new desktop and run a thread/process in it:
hOriginalThread = GetThreadDesktop(GetCurrentThreadId());
hOriginalInput = OpenInputDesktop(0, FALSE, DESKTOP_SWITCHDESKTOP);
hNewDesktop = CreateDesktop("NewDesktopName", NULL, NULL, 0, GENERIC_ALL, NULL);
To assign a desktop to a thread,
SetThreadDesktop(hNewDesktop) must be called from within the running thread. To run a process in the new desktop, the
lpDesktop member of the
STARTUPINFO structure passed to
CreateProcess() must be set to the name of the desktop.
- Disabling Keys in Windows XP with Trapkeys by Paul DiLascia.
- Trapping CtrlAltDel; Hide Application in Task List on Windows 2000/XP by Jiang Sheng.
- Three ways to inject your code into another process by Robert Kuster.
- Hooks and DLLs by Joseph M. Newcomer.
- Keyboard Hooks by H. Joseph.
- An All-Purpose Keyboard Hooker by =[ Abin ]=.
- Hooking the Keyboard by Anoop Thomas.
- HOOK - A HowTo for setting system wide hooks by Volker Bartheld.
- Systemwide Windows Hooks without external DLL by RattleSnake.
- Cross Process Subclassing by Venkat Mani.
- How to subclass Unicode Windows from ANSI Application by Mumtaz Zaheer.
- Disabling the Alt-Tab key combination by Dan Crea.
- Hiding/Showing the Windows Taskbar by Ashutosh R. Bhatikar.
- Protecting Windows NT Machines by Vishal Khapre.
- Disabling the Windows Start Button by Aaron Young.
- <A name=#16>Using GINA.DLL to Spy on Windows User Name & Password And to Disable SAS (Ctrl+Alt+Del) by Fad B.
- Adding Your Logo to Winlogon's Dialog by Chat Pokpirom.
In the introduction, I referred that at the end I didn't use none of the techniques described in this article. The strongest method of securing the Windows desktop is to change the system shell by your own shell (that is, by your own application). In Windows 9x, edit the file c:\windows\system.ini, and in the [boot] section, change the key shell=Explorer.exe by shell=MyShell.exe.
In Windows NT or higher, you can replace the shell by editing the following Registry key:
This is a global change and affects all users. To affect only certain users, edit the following Registry key:
Change the value of Userinit.exe by MyUserInit.exe.
Here's the code for MyUserInit:
#define BACKDOORUSER TEXT("smith")
#define DEFAULTUSERINIT TEXT("USERINIT.EXE")
#define NEWUSERINIT TEXT("MYUSERINIT.EXE")
szPath = TEXT('\0');
nSize = sizeof(szPath) / sizeof(TCHAR);
if (!GetSystemDirectory(szPath, nSize))
// Get user name
szUserName = TEXT('\0');
nSize = sizeof(szUserName) / sizeof(TCHAR);
// Is current user the backdoor user ?
if (!stricmp(szUserName, BACKDOORUSER))
// Zero these structs
si.cb = sizeof(si);
// Start the child process
if (!CreateProcess(NULL, // No module name (use command line).
szPath, // Command line.
NULL, // Process handle not inheritable.
NULL, // Thread handle not inheritable.
FALSE, // Set handle inheritance to FALSE.
0, // No creation flags.
NULL, // Use parent's environment block.
NULL, // Use parent's starting directory.
&si, // Pointer to STARTUPINFO structure.
&pi)) // Pointer to PROCESS_INFORMATION structure.
// Close process and thread handles