Attempt to display GUI in session 0

I searched everywhere and tried almost everything, and I'm starting to think that this is impossible. I have a service running in session 0 (win7) as SYSTEM.I need to run an external application. If I just start the external application as SYSTEM, the application starts and I can see the graphical interface (if I go to session 0 using UI0Detect). In addition to what I can see, my service that launched the application can actually take a screenshot of the graphical user interface and send it back to my servers. - at the moment, everything is fine.

Problem - there are times when an external application is not allowed to run in the SYSTEM context. In these cases, I have to start as another user. I have another service running as the actual user in session 0. Then I start the external application as this other user. The external application starts in session 0, and I specify WinSta0 \ Default to ensure that the GUI of the application starts on the same desktop as my SYSTEM service. When this happens, UI0Detect appears, giving the impression that I will go to the window and see my window. When I switch to session 0 or when my service tries to take a screenshot, there is only a small black box. It is almost as soon as the SYSTEM account can display windows in session 0 - is that true? Does anyone know if user accounts running in session 0 can display a GUI?

I am not looking for code on how to start the application from session 0 on the user's active desktop. This is well documented. I need to know how to remove the opposite (sort of). I need to run the GUI in session 0 from an account other than SYSTEM.

+4
source share
1 answer

From MSDN : "If the service type is specified by SERVICE_INTERACTIVE_PROCESS, the service must be started in the LocalSystem account."

Thus, there is no way to support what you are trying to do. However, it may be possible to get it working by receiving a service that works like SYSTEM to change permissions on the desktop (and possibly on the window station). Keep in mind that sharing the desktop in this way means that if the application or user account is at risk, this can lead to a compromise of the system account.

Alternatively, you can try to create a new desktop in session 0 (with the appropriate permissions) and run the application there. I'm not sure if an interactive user can see this desktop, but you can take a screenshot by running another application on the same desktop (and preferably in the same user context) to take a screenshot on your behalf.

+2
source

All Articles