Closed Gammler closed 8 months ago
If that is the case then that means that EA starts games via a combination of WTSGetActiveConsoleSession and CreateProcessAsUserW using a duplicated token.
If so then there's nothing I can do about this without triggering anti-cheat systems.
Besides, it really makes me question what's wrong with EA to go that route in the first place.
I don't know why but right now it is working again. I have no clue how i can reproduce this again after my PC restart. I will update if i have any information, but i also think like you are saying that this is a EA App related issue.
I try to avoid any sandboxing, because i like the fact that i can just reuse my applications like i left them in my real windows session. If i start steam in a remote session, steam is gracefully shutting down, which i prefer right now to be honest. I guess this bug is just for documentation then.
I had a second person report this exact same issue and it was limited to the EA app as well.
Using process monitoring, I can confirm that this is explicit behavior, aka. a call to CreateProcessAsUserW with a duplicated token stolen from the console session.
The only way I could reliably prevent this is by hooking inside a kernel / minifilter driver.
But those need to be double-signed via the Microsoft hardware dashboard, and I don't have access to that.
I'm not entirely sure if I should close this issue, given how I have no direct way to fix this without access to this dashboard, or if I should leave this open, in the hopes that someone that has access to it can hook us up with means to sign such a minifilter driver.
Ideally this should be fixed in the EA App, by swapping WTSGetActiveConsoleSession for ProcessToSessionId.
These two functions are essentially the same but the latter works for remote sessions as well.
These two functions are essentially the same but the latter works for remote sessions as well.
If i were an evil company i would say, nope. This presents unauthorized use in server environments.
What i am confused about is, that after further testing ( after reboot i didn't have this issue ). What the hell is happening. Didn't test further though.
I can only hazard a guess but was the difference with no active console session being logged on?
Because WTSGetActiveConsoleSession returns invalid values when that is the case.
Maybe EA App falls back to using the regular process functions in that case.
I guess so? Can't remember, but i just checked it with being logged in and it is doing it again.
Now i do not login after restart on my PC but start the session and i can see that there are two user sessions running. It tries to spawn the game in the not even logged in real session. I do not understand wtf is happeing here.
Is there a reason for that? I would assume that there is only one user session when logged in with duo.
There's many session types Windows can spawn, but to keep the explanation simple, let's limit ourselves to the basic 4:
I figure that EA is trying to inject applications into the secure desktop there for some reason. Given its EA we're talking about, I'm not really surprised.
I'm unsure how to best handle this issue though, the only way to truly fix it, without triggering anti-cheat systems like EAC, is to write a kernel minifilter driver to hook NtCreateProcess, but I have no way to sign such a driver because I don't have access to Microsoft's hardware dashboard, which I need to sign the driver.
Hello,
just found the weirdest issue since using Duo.
If you start an Game running through the EA APP like FC24 or It Takes Two it just starts the EA App and the launched Game in the real windows session on my PC Screen and not on my remote session streamed through sunshine.
This would be very annoying if i am not at home and means Duo can not be used with EA Games. Did you experience any of those issues yet?
EDIT: hold on, that might be related to not sandboxed applications. I need to check this this weekend.