Would you consider adding the ability for the injector to detect and inject into games running under another user? (I have 22.5.30)
I’ve taken to running Steam under a different user with more limited permissions than my normal user. It’s not an administrator and doesn’t have file write permissions to anything outside the games directory and its user directory. The reason I do this is security. Once a remote code execution vulnerability was discovered in the Dark Souls franchise games, I decided to lock things down a little, because who knows what other, online games may have such vulnerabilities, yet undiscovered.
SpecialK’s injector seems not to detect games that are launched under another account. It displays “waiting for game” forever, even after the game launches and after it exits normally.
I had to restart Steam under my normal user in order for TMNT Shredder’s Revenge to be detected by the injector service, and I cannot use the file installation method because the process appears to deadlock (one CPU core fully utilized) during initialization and never displays a window. As usual, I’m using Special K to convince it to engage g-sync, as the game normally does not.
As an aside, the game decided to launch in a resolution of something like 860x400 when Special K was active, but I overrode it in the .ini file to fix it.
Have you tried launching SKIF as the same user you’re running Steam as and starting the services through that instance? Or run SKIF (or the service) elevated/as an administrator?
Based on my testing, both methods seems to work:
- Launching SKIF as the other user (same as the game is running as)
- Launching SKIF or the service elevated as the main account
For security purposes I would recommend the former method.
Yeah, actually, that works. I’m surprised the limited user has the ability to start and stop the service, and maybe it shouldn’t, but that should be mostly harmless (maybe it’s not a system service, in Windows terms?). Thanks!
The service runs as the user that starts it, and doesn’t have any requirements of higher privileges since the basic privileges are enough for it to do all it needs to do. All an elevated service allows for is injection in processes running in an elevated security context, or that of another user in the same login session.
Injection into elevated processes is actually the only reason why third-party apps like RTSS etc runs elevated, as running the game elevated is a common occurrence by anti-cheat protects games to separate it from non-elevated processes.
Special K and SKIF was designed with lowest-privilege in mind — even the installer can technically be executed on a standard user provided the required dependencies are already installed (as installing those requires elevation). After the installer has completed, practically all functionality of SKIF and Special K will function the same as if they were run on an admin user.
So working as intended basically
Edit: And yeah, this is not a Windows service per se. It’s a background process called SKIFsvc32 and SKIFsvc64 that provides the same functionality. Having the service installed and run as a typical Windows service as e.g. the SYSTEM account would be a major compatibility and security concern. A Windows service also has various limitations in how it communicates with “foreground apps”, which would make that sort of approach much harder to utilize. Hence, the current approach where two standard background processes acts as the global injection “service.”