AMD forgot to detour the VAC integrity checks too.
For example, Nvidia cards are great for cheaters because you can disable flashbangs and smoke grenades using the stock driver.
If we push it that way, any improvement of FPS due to hardware could even be considered unfair, and to ensure fairness, everybody could theoretically be limited to 30 FPS and xxHz refresh rates.
I don’t know how this design passed basic red teaming during the design phase not to mention QA.
A framerate limitation for "fairness" wouldn't make sense because you'd basically be arguing that it's unfair that someone saw one single extra frame that some player zipped across the screen and they were able to track them whereas they wouldn't without that extra frame.
But a game being networked naturally presents the same issue and it can't be solved (in an engine like source or unreal): player locations are sent to your client at a fixed sample rate. Whether you see a player zip across the screen will just be determined by a bunch of phases of cyclic phenomena: for instance your client renders every 33.33ms (for 30FPS) and the server says he's at position A, then the server says he's at position B which is in your view, but your game isn't rendering yet because it just finished rendering the previous frame. Then you get a packet saying he's at position C which is also off your screen and now finally the rendering happens, rendering another frame with the player off your screen. So you never saw him cross your screen. But another player sitting right behind you looking in the exact same direction will be on a different phase of his render loop: he may render right after receiving position B and so he will see the player zip across. This example ignores interpolation and stuff but it will still apply even then.
Once it's running in trusted mode all hooking is blocked, so even the Discord overlay would not be allowed.
Source: https://help.steampowered.com/en/faqs/view/09A0-4879-4353-EF...
If Nvidia requires extra hooks into the game they usually ask the developer to call certain functions in NVAPI, which is their vendor-specific driver interface.
> No. Unfortunately, even benign applications are often a vector for cheats that hijack them in order to cheat in CS:GO. So in Trusted mode, all foreign software is blocked.
Source: https://help.steampowered.com/en/faqs/view/09A0-4879-4353-EF...
Note that by definition GPU drivers _require_ the ability to inject DLLs into the process, read/write to the process memory, and even create new threads on it...
That's the reason Chrome and derivatives put GPU stuff on a separate process. But you try to do this type of sandboxing on a game and it will utterly destroy performance.
Anything else would just not work. You can't prevent the drivers from doing whatever they want or you would quickly hit a myriad crashes. You cannot rely on what the OS calls a "graphics driver" because then someone would implement their own drivers (wrapping NVs). Your only resort is to allow the well-known drivers and prevent everything else.
The same reasoning applies to all operating systems (e.g. OpenGL ICDs). It is not windows exclusive.
And btw, mods which change rendering related functions are some of the most classic cheating devices and therefore are of critical importance to block in the first place.
As far as I know this is not standard behavior for GPU drivers at least I’ve never seen anything like that happening before.
My bet is they have just decided to put whatever this new thing is in a separate module which they they forgot to send to Valve for whitelisting.
You can hook a message loop using regular Win32 APIs, while hooking a Win32 API requires you to modify code in the process. Specifically you need to inject a trampoline function into the process memory and then overwrite the first two bytes of the Win32 function you'd like to hook with a jump instruction to your trampoline.
The former is a lot easier to allow while the latter is much more likely to open the flood gates for cheats.
But when you're trying to detect cheats, how it was loaded and what it attempts to do in your address space is exactly what you're trying to detect.
a) they're impractical or even impossible to detect: let me know how can you avoid code that is being executed in your address space from not doing anything that it wants to your address space. This is not a buffer overflow looking for a rop, this is code with x permission that is already being executed.
And b) they're irrelevant. Does it matter if your cheating code is loaded as part of the graphics driver? It is trivial to create one...
b) It seems you're trying to argue against anti-cheat as a whole? Yes, anti-cheat will always be defeated in the end. We've reached the point where cheaters are starting to use Direct Memory Access attacks, no way to detect that. But it's still necessary to make sure there's a high enough barrier that prevents the casual cheater from just downloading a cheat without the fear of getting banned.
However I do understand your aversion to it, these are techniques that are hostile to the user and attempts to wrest away control over what code the user is allowed to execute on their own hardware. The fact that the PC allows the user to execute any code they want is a precious right that's being chipped away at.
No at all. I'm arguing that they just have a whitelist of modules they can load, and prevent any unknown module from loading. Because that is the simplest AND only reasonable way to approach this, for the reasons I've exposed above.
With all due respect, I'm struggling to parse this part of your comment.
With that said, I'm pretty sure your target is calling this API method:
https://partner.steamgames.com/doc/api/steam_api#SteamAPI_Re...
If you don't care about being authenticated with a "legit" session for online play, just strip SteamStub and apply a Steam emu with the necessary config. Those will obviously not care about wherever they are being launched from. I recommend the CODEX one if your target is not too recent.