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.
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.
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...
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.
> It seems you're trying to argue against anti-cheat as a whole?
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.
But what you've listed above are a bunch of reasons why a whitelist isn't enough. Because you can whitelist modules, but without extra precautions you have no idea whether the module you've loaded has been compromised. And even if you check the code signature of the module you're loading, unless you have some way of detecting code injection the modules or the engine code can be compromised at any point during runtime.
