How to install a utility manager application that it can run on the secure desktop?

Question

I tried to write a Utility Manager application, and I am trying to test it on WinXP SP3. I added it to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Accessibility\Utility Manager, and it works well when loading the utility manager when I am logged in.

However, when I try to load it from Utility Manager at startup before login (via Window+U), or from the locked screen, an error message appears, saying (approximately, since it is a German version of WinXP) "This application cannot be executed on the secure desktop. Contact your system administrator to obtain the required permissions".

What do I have to do differently to make this work on the secure desktop?

[b]edit:[/b] I followed the advice of David Pope and tried to debug utilman.exe (using OllyDebug since I'm more used to that than using a new debugger..., and asked it to break on process creation). It seems as if my application does not get started at all. As OllyDebug seemed to have some functions (like break on API call) disabled (maybe because the process runs as a different user), i double checked it using Sysinternals Process Monitor. When launching the on-screen keyboard, an "Process created" event appears; when launching my tool, no event appears.

Another side note: When I put osk.exe (the on-screen keyboard) into my new registry key, it works fine (I basically have two onscreen keyboard entries in the menu then), but if I copy osk.exe to osk2.exe and put osk2.exe as the executable, the copy of the on-screen-keyboard onls starts on the non-secure desktop. So it must be some kind of validation (against filename+content) prior calling the executable? Replacing magnify.exe by my tool (or by osk.exe) will make that one not-work after the next reboot (when utilman is restarted??).

In other words: It will only work if the file is named osk.exe and is the On screen keyboard or the file is named magnify.exe and is the magnifyer.

This does not create any information in the event log either.

Answer 1

I'm not sure what the origin of that message is, but I do know that there is a desktop object called Winlogon that is the secure CTRL+ALT+DELETE desktop. You can use OpenDesktop and SetThreadDesktop before you create any windows in your GUI thread and that should enable your windows to display there. There may be another way to do it with the accessibility APIs in the newer versions of Windows.

Answer 2

Have you followed all the instructions on this page? It seems to cover more registry settings than what you described.

Edit: As you point out, looks like that page is for Vista. It's annoying how MSFT culls legacy information and makes it downright hard to find...

One thing to check is the event logs - maybe they contain a clue. It may be possible to crank up the auditing level to see more security-related data.

I don't have your code so I couldn't debug it myself, but I was able to hook a debugger into utilman.exe and get control at the point it launches the utilities on the secure desktop. Maybe if you do this you can figure out the security violation.

1. On the target computer:
   • Install the Debugging Tools for Windows.
   • Enable RDP access.
   • Lock the screen.
   • Press Win-U to bring up the utility manager and leave it running.
   • Make sure your symbols and source are visible on the target at the same path that they were compiled on the dev machine.
2. On another machine:
   • RDP into the target computer as a user with debugging/admin privileges.
3. In the RDP session:
   • Run WinDBG and attach to the utilman process (F6 key)
   • If it doesn't break into the debugger, press ctrl-break.
   • Do .childdbg 1 to ensure your utility gets loaded into this debugger instance when it launches.
   • Do g to continue running.
4. Back on the target computer console (login screen):
   • Launch your utility from the utility manager. The debugger (in the RDP session) should break inside the new process and you should be able to debug from there.

(I don't have Visual Studio on the machine where I tried this out; if you have VStudio on the target machine you can probably use it instead of WinDBG.)

If your utility doesn't even load, then Windows is doing some kind of validation prior to the call to CreateProcess. The security logs might be able to help you there.

Edit 2 I tried using the strings utility to locate the program that generates the dialog box, but I'm on an English WinXP so I don't have the actual string. I also looked for hardcoded "osk.exe" etc. with no luck.

If you can figure out what EXE is putting up that dialog (perhaps utilman, perhaps winlogon...), you should be able to attach to it with the debugger and walk back up the stack to find the check that errors out. Once you have the general vicinity of the check that fails, you should be able to set a breakpoint earlier in the codepath that should break into the debugger the next time you try to launch. You should be able to step through the failing check from there. For all of this, make sure you have the OS symbols available, since it should make the "signposts" much easier to read. I'm not familiar with whether your debugger has support for the symbol server.

Answer 3

Is your program digitally signed? Where is your program running from?

Try having it in one of the following protected paths:

* ..\Program Files\ (and subfolders)
* ..\Program Files (x86)\ (and subfolders, in 64-bit versions of Windows only)
* ..\Windows\System32\

Have you seen http://netsecurity.about.com/od/secureyourwindowspc/qt/uacuiaccess.htm ? That seems to describe some of what you're trying to do.