7 ms·

> Is there a whitelist of software that can be safely injected into CS:GO? > No. Unfortunately, even benign applications are often a vector for cheats that hij

> Is there a whitelist of software that can be safely injected into CS:GO? > 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-EF95#whitelist https://help.steampowered.com/en/faqs/view/09A0-4879-4353-EF...

AshamedCaptain 3y ago
Almost 100% sure they keep a whitelist with all common GPU drivers. 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.
- dogma1138 3y ago
  Can you provide some docs around it? It goes quite against everything public, when NV adds new features that are not part of D3D or other APIs they release binaries for developers to use to call NVAPI directly Ive never seen their driver injects anything into a running process.
  - AshamedCaptain 3y ago
    D3D is not IPC. It is mostly implemented in the process' address space. When you call a D3D function you are not magically dumping all your primitives into the kernel-side driver (which would be slow), you are calling into nvd3dum.dll which _may_ eventually call into the kernel. All of this happens in the same process and therefore the GPU driver can do whatever the hell it wants to it.
    - mardifoufs 3y ago
      Yes but this derouted the engine.dll (or equivalent) code in userspace (not sure if that's the right term here). I agree that they probably whitelist or even just don't check the graphics or rendering related functions, since tons of mods allow you to do that without any widespread ban wave. But when it's hooking to the core engine code, I think that's a different story. Correct me if I'm wrong though.
      - AshamedCaptain 3y ago
        There is no way to make this distinction purely from userspace, you cannot "sandbox" a library you are loading into your process. Therefore they just keep a whitelist of graphic drivers that are allowed to load (and do whatever they want). 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.
        dogma1138 3y ago
        This wasn’t the driver doing what ever it wants up stream it was overriding the renderqueue and other functions within the executable at runtime. As far as I know this is not standard behavior for GPU drivers at least I’ve never seen anything like that happening before.
        AshamedCaptain 3y ago
        I really doubt that; not because they haven't done that in the past, because they have; but because with the frequency of updates of game clients these days you really cannot get away with that as easily. On the other hand, hooking the lower-level Win32 functions is extremely common, I am yet to see a GPU driver that doesn't implement some level of idle/activity detection based on hooking the message loop, for example. 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.
- armada651 3y ago
  Graphics drivers don't need to use code injection to load their DLLs. They're loaded by the process when it initializes the graphic context.
  - AshamedCaptain 3y ago
    There is no practical difference. You can't really know if the graphics driver comes because it is "injected" by whatever or because the system loads it; from the point of view of the process it is exactly the same (code you didn't explicitly request magically appears on your address space). If you are already loaded by the process you can do _anything_ you want to it, including loading other modules.
    - armada651 3y ago
      You're glossing over distinctions that do matter when you're trying to detecting cheating. Yes, once a DLL is loaded into the process memory it can do anything it wants. 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.
      - AshamedCaptain 3y ago
        They don't matter because 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...
        armada651 3y ago
        a) It is impractical, but necessary to ensure a fair game. It is just as impractical as a virus-scanner trying to protect the OS from novel malware that's being directly executed by the user at admin rights. Just because it's hard doesn't mean it can't/shouldn't be done. Also the anti-cheat doesn't need to prevent it, it just needs to detect and report it. 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.

AshamedCaptain 3y ago

Almost 100% sure they keep a whitelist with all common GPU drivers. 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.

dogma1138 3y ago
Can you provide some docs around it? It goes quite against everything public, when NV adds new features that are not part of D3D or other APIs they release binaries for developers to use to call NVAPI directly Ive never seen their driver injects anything into a running process.
- AshamedCaptain 3y ago
  D3D is not IPC. It is mostly implemented in the process' address space. When you call a D3D function you are not magically dumping all your primitives into the kernel-side driver (which would be slow), you are calling into nvd3dum.dll which _may_ eventually call into the kernel. All of this happens in the same process and therefore the GPU driver can do whatever the hell it wants to it.
  - mardifoufs 3y ago
    Yes but this derouted the engine.dll (or equivalent) code in userspace (not sure if that's the right term here). I agree that they probably whitelist or even just don't check the graphics or rendering related functions, since tons of mods allow you to do that without any widespread ban wave. But when it's hooking to the core engine code, I think that's a different story. Correct me if I'm wrong though.
    - AshamedCaptain 3y ago
      There is no way to make this distinction purely from userspace, you cannot "sandbox" a library you are loading into your process. Therefore they just keep a whitelist of graphic drivers that are allowed to load (and do whatever they want). 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.
      - dogma1138 3y ago
        This wasn’t the driver doing what ever it wants up stream it was overriding the renderqueue and other functions within the executable at runtime. As far as I know this is not standard behavior for GPU drivers at least I’ve never seen anything like that happening before.
        AshamedCaptain 3y ago
        I really doubt that; not because they haven't done that in the past, because they have; but because with the frequency of updates of game clients these days you really cannot get away with that as easily. On the other hand, hooking the lower-level Win32 functions is extremely common, I am yet to see a GPU driver that doesn't implement some level of idle/activity detection based on hooking the message loop, for example. 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.
armada651 3y ago
Graphics drivers don't need to use code injection to load their DLLs. They're loaded by the process when it initializes the graphic context.
- AshamedCaptain 3y ago
  There is no practical difference. You can't really know if the graphics driver comes because it is "injected" by whatever or because the system loads it; from the point of view of the process it is exactly the same (code you didn't explicitly request magically appears on your address space). If you are already loaded by the process you can do _anything_ you want to it, including loading other modules.
  - armada651 3y ago
    You're glossing over distinctions that do matter when you're trying to detecting cheating. Yes, once a DLL is loaded into the process memory it can do anything it wants. 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.
    - AshamedCaptain 3y ago
      They don't matter because 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...
      - armada651 3y ago
        a) It is impractical, but necessary to ensure a fair game. It is just as impractical as a virus-scanner trying to protect the OS from novel malware that's being directly executed by the user at admin rights. Just because it's hard doesn't mean it can't/shouldn't be done. Also the anti-cheat doesn't need to prevent it, it just needs to detect and report it. 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.