[Question] Input management from Session 0

[Jadd]

Does anyone know of easier methods (even hackish ones) to access input functions from Session 0? Possibly somewhere to specify which desktop it should access input info from?

Microsoft only lists these options:

• If a service needs to interact with the user by sending a message, use the WTSSendMessage function. It is almost identical in functionality to a MessageBox. This will provide an adequate and simple solution to services that do not require an elaborate UI, and is secure because the displayed message box cannot be used to take control of the underlying service.
  
• If your service requires a more elaborate UI, use the CreateProcessAsUser function to create a process in the requesting user’s desktop Note that you will still need to communicate between the newly created process and the original services, which is where the next bullet point kicks in.
  
• If two-way interaction is required, use Windows Communication Foundation (WCF), .NET remoting, named pipes, or any other interprocess communication (IPC) mechanism (excluding window messages) to communicate across sessions. WCF and Remoting have a better security enforcement that will prompt the user (assuming UAC not shut-off) to elevate if needed.
  
• Ensure that kernel objects meant to be shared across sessions have names prefixed with the Global\ string, indicating that they belong in a session-global namespace.

All I'm trying to do is check if a key is held from the active desktop. And I feel as if creating a whole new process and communication between the two is a bit overkill for something so simple.

This is really a big pain in my ass. Lol ^^

[Cypher]

I feel obliged to say "please don't do that" (hacky workarounds I mean).

The restrictions are usually imposed for good reasons, and hacky workarounds either cause more work from an OS appcompat perspective, or more work for the user when they have unusual configurations (e.g. lots of software doesn't work when I use the Sysinternals Desktops tool to run multiple desktops, which sucks).

Anyway, as far as legitimate workarounds I'm not entirely sure... What have you tried so far? Every time I've needed to monitor input I just spawned a process in each interactive session using a helper service...

[Jadd]

Anyway, as far as legitimate workarounds I'm not entirely sure... What have you tried so far? Every time I've needed to monitor input I just spawned a process in each interactive session using a helper service...

I haven't tried anything yet, I figured I'd ask first. I guess I will go with creating a process from the active session. Do you have any recommended means of communication between the two?

Also, lol @ your signature. I wish I got to read more of that thread before you took it down.

[Cypher]

I haven't tried anything yet, I figured I'd ask first. I guess I will go with creating a process from the active session. Do you have any recommended means of communication between the two?

Also, lol @ your signature. I wish I got to read more of that thread before you took it down.

It depends on exactly what you're trying to do. If it's just "the one key that we're interested in has been pressed" it could be as simple as an event (just don't use PulseEvent[1])... If you need something more sophisticated then you've got lots of options (shared memory, pipes, sockets, rpc, etc), though again it really depends on the circumstances.

P.S. I wasn't the one who took it down.

[1] PulseEvent is fundamentally flawed - The Old New Thing - Site Home - MSDN Blogs

[Jadd]

It depends on exactly what you're trying to do. If it's just "the one key that we're interested in has been pressed" it could be as simple as an event (just don't use PulseEvent[1])... If you need something more sophisticated then you've got lots of options (shared memory, pipes, sockets, rpc, etc), though again it really depends on the circumstances.

P.S. I wasn't the one who took it down.

[1] PulseEvent is fundamentally flawed - The Old New Thing - Site Home - MSDN Blogs

Yeah, I will actually be doing some SendInput stuff as well. Luckily I already have sockets set up from the service (though, not completely async-ready just yet). Thanks for the help.

[Hyru]

As stated previously, you can't do this without using CreateProcessAsUser for the session you're trying to query. I've done this in the past by running code on the active input desktop of every user session with a duplicate user token from csrss to get full permissions. It gets really kludgy when you try to get accurate results between XP/2003 and Vista/later, and even more ugly when you need to get processes to run reliably on WinSta0\Winlogon. Fun stuff though.

[Cypher]

As stated previously, you can't do this without using CreateProcessAsUser for the session you're trying to query. I've done this in the past by running code on the active input desktop of every user session with a duplicate user token from csrss to get full permissions. It gets really kludgy when you try to get accurate results between XP/2003 and Vista/later, and even more ugly when you need to get processes to run reliably on WinSta0\Winlogon. Fun stuff though.

Just in case anyone wants to write code to do this, it won't work on Windows 8.1 if you use CSRSS.exe because it has become a protected process (similar to how certain DRM components were protected in earlier versions of Windows). For the time being you can still use Winlogon.exe and LSASS.exe, but SMSS.exe, CSRSS.exe and Services.exe are all protected now. Personally I'd probably just install my own service (running as SYSTEM) to do the dirty work, as then you don't need to duplicate the token of another process, you can just duplicate your own token and use SetTokenInformation to change the session ID. That should shield you from potential OS changes in the future which would otherwise break your code.

EDIT:

Adding a link to the documentation for the Windows 8.1 changes:
http://msdn.microsoft.com/en-us/library/windows/desktop/dn313124.aspx

EDIT2:

I just remembered that it may actually continue to work depending on how you open the process and what access mask is required... (Though you definitely can no longer write memory, inject DLLs, etc into any of the new protected procs.) Either way, it's probably best to avoid using the Windows components in that way if possible.

[_Mike]

Adding a link to the documentation for the Windows 8.1 changes:
Protecting Anti-Malware Services (Windows)

Interesting. I wonder if we will soon see game developers abusing this as an extra anti-cheat method.

[Cypher]

Interesting. I wonder if we will soon see game developers abusing this as an extra anti-cheat method.

Nope. There are very strict rules on who is allowed to have a protected process cert.