To clarify, this does not seem to only affect cs2. Antilag+ has been slowly enabled on a game per game basis, and they recently started adding multiplayer games. They seem to also be affected.
AMD also openly said that they are patching game engine code, which is just bizarre. Not sure what the thought process was. Even if we assume they were aiming to be whitelisted (I'm not sure hooking into game engine code is even common, apparently it isn't), they have still pushed the updates before the whitelisting happened. What was the plan here?
There are open source projects attempting a similar approach to antilag+ ("patching" the DLLs at runtime) but they all seem to warn you about possible anticheat detection on multiplayer games. Again, this was patching the actual engine DLL, not the rendering or graphics related DLLs that drivers sometimes have to patch for specific games.
> AMD also openly said that they are patching game engine code, which is just bizarre. Not sure what the thought process was
Hasn’t it been true for ages that GPU drivers contain fixes for a lot of GPU instructions from popular games that would otherwise be broken.
In that case, if they are used to fixing games already, it might not seem a big step from their side when they decided to also patch game code that runs on the CPU. It was unfortunate that they did not realise this would lead to triggering anti-cheat systems in games though.
But there is history of others altering program code too. For example Microsoft Windows included code specific to various pieces of software that would otherwise be broken. I wonder if that ever lead to trigger anti-cheat systems in any games.
>> it might not seem a big step from their side when they decided to also patch game code that runs on the CPU. It was unfortunate that they did not realise this would lead to triggering anti-cheat systems in games though.
Never mind anti-cheat systems. This is a huge boundary violation - like when Sony installed root kits. It's one thing to modify your own products behavior, but quite another to modify other software!
I believe all AAA companies work very closely together with the GPU vendors during all the cycle of dev.. it isn’t as if they aren’t aware or don’t want it
From my understanding they continue to patch even when the developer has abandoned the title. iD doesn’t care if Doom won’t run on a new graphics card, but the consumer will so it’s in GPU maker’s problem, not the developers (they already have your money).
It’s a different layer for those though. In each of those other cases, the code paths that diverge per app are not within the app libraries but within the system SDK or the graphics driver.
Those are layers the application has to trust , and also has expectations may change implementations. They’re only accessible as an API.
In this case they were stepping into code they don’t control which is a huge violation of trust
AMD should work with Valve to release these improvements to everyone. They pretty much patched the engine to lower latency, I believe everyone could benefit from it if Valve saw what AMD did and implemented their "fixes".
Tangentially related: Back in the day, the AMD Cool'n'Quiet feature had a funny effect in CS:Source where your player would move much faster than normal. This resulted in bans because of the obvious advantage, which was mistaken for a speed hack.
Something similar happened when anyone try to play un-patch Unreal Tournament (1999 game) on modern cpus. The dynamic cpu speed confuses the game engine, that results on the game slowing of becoming comically faster.
Some AMD employee really wanted those last few FPS out of their CS2 rig. I wonder how you’d even go about optimizing a game this way. They must have some profiling that shows where the engine hotspots are, then somehow tie those to actual engine dll entry points. Kind of a tricky/impressive bit of reverse engineering.
Most likely, this is similar to NVIDIA reflex. In that case, they simply wait in the engine loop directly before mouse and keyboard entry are handled. That way, the GPU can process this new data immediately (as opposed to first waiting for vsync) and thereby overall latency is reduced.
Why would this be considered an illegal cheat? In a networked game, shouldn't the only determinative factor be whose input arrives at the server first?
The server doesn't always decide. It's common for shooters to want to guarantee that if it looks like you shot the other player on your screen, the game will react as if you shot the other player, even if the server would have considered it a miss due to timing differences. Those things can really only be done by trusting the client not to lie, which means verifying that the client hasn't been tampered with.
Plus, there's a lot of cases where the server sends some pieces of information to the client but the user isn't supposed to see it. The locations of the other players is a common example, where people modify their client to render outlines of players through walls. That's a huge advantage but doesn't even affect anything hit registration related.
> It's common for shooters to want to guarantee that if it looks like you shot the other player on your screen, the game will react as if you shot the other player, even if the server would have considered it a miss due to timing differences. Those things can really only be done by trusting the client not to lie, which means verifying that the client hasn't been tampered with.
Why does server-authoritative backwards reconciliation require trusting the client not to lie? The server keeps a history of the past N states and client claims to hits are verified by the server using that history. A client could lie and say it made a hit in one of those prior states (but not an state the client invented whole cloth.) But if the client is doing that then from the server's perspective that player is lagging and backwards reconciliation makes lagging players easier for other players to hit.
Obviously if you're doing client-authoritative unlagging then you need anticheat, but AFAIK competitive shooters have used server authoritative backwards reconciliation ever since the early 00s.
If the target is moving and the shooter is moving their crosshair, there doesn't have to be a single server-side state where where shooter's crosshair is on the target's hitbox. Yet the shooter, being usually tens or hundreds of milliseconds out of sync with the server yet responding instantly to player input, might have had their crosshair right on the target's hitbox when they click the shoot button. Modern games usually still want to register that as a hit; it's a principle is called "favor the shooter". I don't see how that doesn't mean reacting to a state which the client invented whole cloth?
Not that this really matters. If you think that you could do favor the shooter style hit registration in a completely server authoritative way, we can just use wall hacks or aim bots as an example instead.
If you read deep into the community and play something like modern warfare 2 2022 (mw2) you'll see quite often the game seems to purposely lag players and decide outcomes on a per engagement basis. kill cams show a totally different set of events than what you saw on say a decent PC such as running around a corner and you shot first but kill cam shows the opposite. they aren't just doing de lag or whatever they are balancing kill death ratios too.
This makes me wonder—how much performance would you loose by taking a "distrusted client" approach, and only sending data that you want the player to know about? Could you make cheating basically impossible?
Valorant and Counter-Strike attempt to do this as much as they can, not sending information about enemies the player shouldn't be able to see. This is not flawless, though, probably due to performance or latency requirements.
Iirc, Warzone also sends information about non-existing players to suspected cheaters to attempt detecting aimbots.
I think the client also receives information about non-visible-but-nearby players for things like footstep noises. In counter strike you can hear a person around the corner running around, reloading, etc. and I think in some cases you can shoot through thin walls at these players. Even if they are completely obscured from view.
Ah, so it's considered a "bot" because the game is expecting something to reach the display before a human responded? The card isn't doing any network input, so something must be checking if the state was blitted before the human response...(?!)
It's not considered bot or anything. It's just Valve forbids any software signed or unsigned to mess with game executable, data or memory without being specifically whitelisted.
Why? Because even if software doing this is legitimate it's can still be used by actual cheaters by patching it.
They are being banned for the game code being modified in memory, the anti cheat knows nothing about the fact that input latency was decreased. And no, reducing input latency is not considered a cheat, anywhere, no game does that.
Yep exactly. It does remind me of the story of someone coming to quake con in the 90s though and using a "feature" of idtech game engines where it tied a lot of code to frame rate and thus once you get enough fps, time accelerated effectively for that player. I think it was ruled not a cheat for that season (I could be wrong it's been over 20 years) but discouraged for future years.
Not sure if that's what you're referring to, but quake 3 physics behaved differently based on the client frame rate. 125Hz made all of the physics steps round up when jumping, allowing for just a little extra height that allowed for some jumps.
My guess: this changes the timing profile of the overall game/engine. If the engine monitors itself for erratic/unexpected delays, it may conclude that it's running under a debugger if certain procedures take far longer (or shorter) than they should.
You can literally check if something has attached itself to your executable or replaced a DLL. No need to check for timings or anything particularly elaborate.
Wait, how does exactly this work? As I understand it works something like this: mouse/keyboard input -> driver -> game engine -> graphic engine -> GPU. So, what exactly NVIDIA reflex (and Radeon lag+) did? How does intercepting commands in game engine helps the performance of GPU?
Upd: I did read explanation of Nvidia reflex (NVIDIA Reflex keeps the CPU perfectly in sync with the GPU to eliminate the render queue.) and still not sure that I understand. Why developers of game did not implemented this fix themselves?
The first step to reducing input latency is to eliminate the frame queue. Usually the driver allows the CPU to submit up to 3 frames worth of rendering commands, which means that on a 60Hz monitor the image being displayed could represent input from up to 45ms ago because of the frame queue.
The frame queue exists to eliminate GPU bubbles where the GPU sits idle waiting for the CPU to send new rendering commands. If the game developer puts in the work of eliminating these GPU bubbles as much as possible then it's possible to turn off the frame queue while maintaining a good frame rate.
This step of reducing latency does not require intercepting any calls and is probably what is being done in AMD Anti-Lag. However there is a further step to reducing input latency that AMD called Anti-Lag+ that does require extra hooks in the engine. I explained that in this comment: https://news.ycombinator.com/item?id=37879517
Triple buffering maintains a queue* of fully rendered frames ready to be displayed by the monitor. What I'm talking about is a queue of rendering commands for frames that still need to be rendered by the GPU.
* triple buffering does not actually use a queue, but rather two buffer swaps, which means a frame is allowed to skip ahead if completed early.
Turning it off means doing what instead? No vsync at all will certainly give you faster updates, if you don't mind the tearing. But in general I would describe triple buffering as a way to reduce lag when vsync is on but your system is fast.
Nvidia reflex works by inserting a wait before input processing that dynamically adjusts so that the frame completes rendering right before the monitor's v-blank. Thereby reducing the amount of time the completed frame sits idle in the backbuffer, which in turn reduces the delta between when input is sampled and when the frame is displayed.
To do this effectively is very difficult without a complete view of the pipeline all the way to the display. That is why a feature like that works best when the driver and game engine work together rather than either side attempting to implement it unilaterally.
It seems that AMD attempted to implement this feature without help from the game developer by hooking the Windows input APIs directly.
VAC bans in waves, you might be banned a month after you were caught cheating. This prevents cheat developers from iterating and finding ways to circumvent the system.
Never understood how Valve's VAC bans are even legal. You pay for a game, Valve decides they don't like your computer and they take away your ability to play that and other games that you paid for without refunding you. Worse, they slander you on your Steam profile page so other gamers know what Valve thinks of you.
They claim to never make mistakes, but that's obviously bullshit since they make mistakes time and time again.
What happens in meatspace if you pay a cover charge to enter a place, and then don't follow the rules of the establishment? The same thing, you will be asked to leave, and trespassed if you refuse.
Just because you paid to access someone else's servers doesn't mean that you can do anything you want, with no way for the owner of the server to enforce any rules. It works like this with any kind of service on the internet. Games are not any different.
If I pay a lifetime membership fee for a meat space, and they ban me, I expect the lifetime membership fee to be refunded, subject to reasonable prorating, even if they claim I violated their "subscriber agreement".
Anything else would seem to me to incentivize banning as many lifetime members as possible before significant consumer retaliation (e.g. maybe we'll just ban the lifetime members with low social clout), to reduce costs and maximize profits.
It's not purported to be perpetual, the EULA is defined as the "subscriber agreement" and it's clearly laid out that violation of anti-cheat protections violates the terms of your game subscription.
Doesn't the profile just say how many VAC bans you've received? That's just a statement of fact rather than slander, regardless of fairness of the ban.
Overall though, when you make a Steam account, you agree to their terms of service, where you agree not to engage in "modification of content and services" in the context of multiplayer games. You also agree that the owners of the game the modification was made to can report you to Valve, that Valve can put that info on your profile, and that other games can decide to deny you online services for that. You still retain access to offline stuff and any online games which don't care about your VAC bans.
It sort of sucks in the sense that sometimes you might not know that something is modifying your game executable, thus getting you a ban, but otherwise a reasonable means of dealing with cheaters.
The average user is not capable to agree or disagree with such a requirement. Look at this very post: all they did was enable a feature of their GPU driver. And they got branded a cheater by Valve. Sure, Valve promises to make it right this time but how can a user predict what will happen when they update or install software on their machine that happens to step on Valve's toes? And good luck getting anyone to believe you or even look into your case unless the issue affects a ton of players and makes the headlines.
Valve's solution appears to be to have a "trusted mode" which rejects modifications. This is obviously a minimal barrier for malicious code, but it can reject benign code (eg Discord's in game layout).
Thus, they expect that the average user is likely to only be running "average" things like Discord and the graphics driver, which should be using the benign way of injecting themselves rather than breaking into trusted mode.
I don't know how it works in detail, all I know is that they once again banned players for something completely beneign, all the while pretending that they never make mistakes.
The point I'm making is that Valve has defined fairly clear lines in the sand for what they consider acceptable behavior from 3rd party applications and it's AMD's fault for pushing something that is not in fact benign as being benign.
I agree and in this case it may have just been a driver update turning this feature on.
My friend has auto hotkey installed for volume control automations and immediately got banned for single player call of duty. Valve at least is trying to be fair vs. Activision just saying "too bad"
You don’t buy the game but a license to play it. You can still play CS after a ban, just not online on their servers or any community servers which block vac banned players.
(They killed all community servers two weeks ago btw)
> You don’t buy the game but a license to play it.
This is such a pedantic argument that misses the point and short circuits the entire discussion. I don't think there's a single reasonable person who mistakenly believes that they're buying the IP itself when they "buy" a game on Steam.
Of course it's "just" a license to play it, what's being questioned are the terms of those licenses, both from moral and legal perspective.
Most current EULAs boil down to: "We reserve the right to suspend your account and revoke access to the software you paid for for any reason, no refunds". To the best of my knowledge these EULAs haven't been tested in court so they shouldn't be taken at face value.
There's a lot of room to balance the rights of customers who should be granted the same rights they would enjoy when buying a physical product, and the practical needs of platforms which need to ensure a fair environment for other players.
Should cheaters be allowed to ruin the experience for other players? Obviously not.
Should platforms be allowed to permanently ban suspected cheaters without a fair and transparent appeals process and without offering refunds? I don't think so.
"You can play it except for the game modes people actually care about"
Do you also think it's okay if a car that you bought prevents you from driving it, but oh don't worry, it's okay because you're still allowed to open the doors?
Look, I get where you’re coming from. But ask people who actually play competitive online games and I can all but guarantee the general consensus is that anti-cheat is celebrated, not hated. Most people’s complaint with VAC would likely be that it is too lenient or too slow to ban.
Some online games don’t have anti-cheat, and they become nothing but a cheating cesspool. Which consequently drives away actual players, and then you have a dead game except for essentially bots.
That's the same argument as "but think of the children". Are you also fine with CSAM scanning tools being installed everywhere? It's okay to have a bunch of false positives that potentially ruin people just in case you can also catch a bad apple?
Because if you do own a phone then it becomes your property and the manufacturer shouldn't be allowed to invade the privacy of your data on your phone, but CS is free to play, it's not your property, it's Valve's property, and Valve is allowed to allow or ban whoever they want on it, you don't have a constitutional right to be allowed to paly CS without Valve's permission.
> Are you also fine with CSAM scanning tools being installed everywhere?
No, and neither am I ok with anticheat software doing it. Afaik, most anticheats don’t do that. They just make sure that nothing is modifying/injecting into the game code. Which is imo reasonable, as the anticheat is just monitoring for any injections/modifications to the game that it came with.
You argument sounds good to an executive, however, it is simply not the case that games have rampant amount of hacking in general.
EDIT: Why would you just downvote this, I already suspected you're one of those idiots who thinks everyone is cheating. Now I'm just convinced, and that's enough of this self masturbating forum for the month. Most cheat accusers in games are literally clueless slobs who just sign on to level up or some idiots in a closed circle of friends and think anyone who doesn't use their basic immediate method of naive play like walking into each other and clicking on each other is cheating.
> however, it is simply not the case that games have rampant amount of hacking in general.
Yes, many do. Especially ones with poor anti-cheat, which tend not to be very popular - because of the aforementioned cheating. Even non-overly competitive games are rampant with cheating, take a look at GTA5 online for an easy example. Without VAC games like the counter-strike series would be completely unplayable, I have over 1000 hours in the game and have ran into my fair share of extremely obvious cheaters over the years. I suspect you don't play competitive games very much if that's your view on the matter.
> Why would you just downvote this, I already suspected you're one of those idiots who thinks everyone is cheating.
1. I can't downvote you, as you're a reply to my comment. Not that I would have anyway.
2. I've never cheated in an online game (my Steam account is 17 years old..), and I'm well aware that many players are not cheating and are simply better than me.
3. No need to resort to attacking me because you disagree.
HN software doesn’t allow downvoting posts that are responses to your own posts. The poster couldn’t have downvoted your post just like you can’t downvote this one.
There's a big difference between things I'm okay with as a punishment for being convicted of a felony, and things I'm okay with being imposed by megacorps with zero due process or accountability.
For certain traffic violations (including DUI in some states), your car gets impounded and your license taken away on the spot, way before you get your court hearing and get charged with anything.
I'm not a murican but I assume that over there it's also legal to drive your car on your property without a license. How can they strip you of that right?
I think the assumption in that rule is that it applies only to cars that you want to have registered and drive on public roads.
Naturally, if you want to drive your car on your own private property, you won’t need a valid registration or license, so it won’t fall under that rule. So no, this law wouldn’t strip your rights to that.
You are welcome to play CS on your own servers without being in compliance with the EULA, at this point in time you get to do that alone but that will change.
I've had a steam account forever and haven't been banned. that said call of duty appears to ban people running on cloud gaming with no way to contest it so you're out $70+ or more just because your laptop sucks and you're using a streaming service to enjoy your games anywhere.
unless games are written from scratch with security around preventing cheating first they are left with grasping for virtual straws at what is an exploit or not. in a lot of cases it's low level drivers that are suspect, game code changing in ram such as by a hook into the code, etc.
a few friends and I sat down and pondered what it would take to make a game like quake 2 robust enough and we gave up after deciding it'd be a ground up rewrite of both the client and server sides to only send specific data the client needs but no more so even wall hacks don't work and sending encrypted code to run in a VM inside the game from the server and if that memory is touched assume it's kick worthy but even then bit flips can happen etc. Could we trust video drivers from being tweaked to show wireframe renders and other things like that came up. Given this was like 1998 so I'm sure some of this has been implemented these days, I haven't kept a pulse on the tech.
I have read that even secure systems such as the PS4 have cheating going on with rooted systems so who even knows.
No, I don't even play these games competitively. I just care about being able to run what I want on my devices without some company telling me I don't get to do that or else
And admittedly their grandstanding of "VAC is always right, we never make mistakes and bans cannot and will not be reversed" hits a nerve, because that is just a blatant lie.
They actually banned players for using Windows 7, and now they're doing it again to AMD users. Both were obvious mistakes on their end.
You can cheat all you want in counter strike, you just can't do it on a VAC verified server. Which is most servers because people don't want to play with cheaters. But you can go host your own server and disable VAC.
Or another way to look at it is, you CAN do whatever you want with the software on your computer. But Valve can do whatever they want with the software on THEIR computers. They have no obligation to network with you.
Carrying your request even further, you're sort of saying websites cannot moderate content because that interferes with your ability to use your browser freely.
It's not about wanting to cheat, it's about being able to do things such as updating your graphics driver without being branded a cheater and having the things you paid for being taken away
If you don't trust the anti cheat why would you trust the game?
Other people like to play competitive games, do you have another option other than anti cheat?
They didn't ban people for using win7, they detected something that ran on win7 only. Where is this grandstanding? They've had false bans before and they reverse false bans now and then no? Usually it's a group that is banned so pretty obvious when a bunch of people starts complaining.
Unfortunately, games involving human reflexes or difficulty-to-see visual clues aren’t very fun against strangers who can run what they want on their devices. Because cheating.
I don’t think a good solution exists except to keep those games to locked down consoles only.
But maybe a more transparent appeals process could help, even if it gets expensive.
An overwhelming number of players who do play these games regularly would not pay for or play them if the vanishing minority of potential users like you who care about hypothetical freedoms had their way.
Afaik you can still run cs if you're vac banned, just not connect to servers with vac enabled (which is the vast majority; nobody wants to play with cheaters).
You can still play with a VAC ban, you just can't play on VAC enabled servers. If I remember correctly, in CS:GO there used to be VAC disabled community servers you could play on, though they'd unsurprisingly have an increase in cheaters.
Paid VAC protected games exist, and arguably it's worsewl with counter strike: you pay for cosmetics that become worthless one Valve has decided they do not like what you install on your computer.
Just go back to private servers, no matchmaking, no competitive ranking. And no I haven't played multiplayer since around the time Battlefield 1942 added punkbuster and vote kicking.
The real issue here is that it was a detectable optimization, Nvidia may play similar tricks except it’s not an issue if the code is embedded deeper into the hardware stack.
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.
Reflex requires the game developers to use the Reflex interface via NVAPI, the AMD global anti lag feature was hijacking calls at runtime and modifying the memory of running processes.
I don’t know how this design passed basic red teaming during the design phase not to mention QA.
What actually happened is that the game code was modified in memory which VAC disallows because that's how many cheats are implemented. I'm not even sure what you're trying to say. Yes you can disable some effects in games through changing driver options and you can make your monitor render a red dot and add macros to your keyboard, those all are a distinct problem from the subject here.
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.
> 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.
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.
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.
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.
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.
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.
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.
There's a world of difference between hooking a message loop and hooking a Win32 function:
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.
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.
GPU vendors don't have to hook rendering functions since they're the ones providing the implementation of those rendering functions.
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.
There must be some kind of whitelist system. Discord for example doesn't have many options to draw it's ingame overlay. They either create a topmost transparent window (does not work in exclusive fullscreen) or hook glEnd() of the targer or however it's called these days.
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.
Same, but R9 380X back in college. Bang per buck it seemed better than NVidia. But despite my distaste for NVidia back then, after that experience, I resolved to never get an AMD GPU again unless things drastically change.
Drivers would constantly break something, some games would run poorly and I would have to fiddle with driver versions to address this (often involving annoying version rollbacks), it would randomly start overheating for no reason, sometimes it would just crash the system, etc. Upgraded to 480 later, and the exact same story repeated.
You know what happened once I got an NVidia GPU years later (1080Ti)? I never had to think about the GPU ever again. I install a driver update occasionally, it “just werks”, and I would go on my merry way. Upgraded to a 3080 about half a year after it got released, and had the same story - it just works, and I never have to think or worry about it ever.
I would love to support AMD GPUs, but I cannot, in good conscience, buy their GPU again and waste time troubleshooting it and stress over every driver update.
On the flip side, AMD CPUs are amazing. Been with them since the original Ryzen release, upgraded once (from 1700 to 3900x), no issues whatsoever and am very happy with those. My next build will be an AMD Ryzen CPU as well, but it will have an NVidia GPU.
Funny since I agree about mobile radeons being like this where every update is a risky thing however I moved from Nvidia only (after my one ATi 9800 Pro) to AMD due to the drivers stuttering, breaking and finally making my 8800Gts 320 unusable in games because it wasnt the magic 640mb edition.
I've since had 5770, 6770 (same card but in fire), 290X, RX580X, and now 6750 without any issues.
iGPU stuff however has been awful but then again so was my Intel/Nvidia laptop having problems with iGPU fighting the dGPU.
In my case, all of the configs I described were desktop builds, as I am not willing to touch a windows laptop with a 10 foot pole again, and in general gaming is the last thing on my mind when considering a laptop.
I remember back in the day ATI Tray Tools also injected itself into processes and caused bans. I don't know what's with AMD and their complete incompetence in matters of software.
What does that have to do with incompetence, though? Incompetence would imply that the feature either didn't work or broke things, which it didn't. It triggered a very specific anti-cheat mechanisms of one specific and relatively new game.
The game still worked as intended, though.
It's not one game. And remember they enabled it on very few multiplayer games, yet all of them have reported issues. CoD just crashes when it detects antilag+, while apex actually handed out tons of bans
"What does that have to do with incompetence, though?"
They've made this same mistake before, didn't learn their lesson, and repeated the same mistake. That's pretty incompetent. Like Cisco-level incompetent.
Unless either tool was actually a cheat, the mistake in both cases was made by the anti-cheat software: a false positive.
Users should be free to play without cheating and not worry that the a anti-cheat will falsely think they are.
"but wait!" one may protest, "the tool is similar to a cheat if they detect using [technique X]!"
Well, I'm not forcing them to use [technique X], and they aren't entitled to exclusively use it, if it returns false positives. Sounds like they need to think of better techniques. And if they can't, and it turns out they don't know how to solve the problem without hurting innocent people, they aren't entitled to exist, either.
"Unless either tool was actually a cheat, the mistake in both cases was made by the anti-cheat software: a false positive."
No, they should know injecting/hooking into the engine .DLL would trigger this from VAC. It happened to them before. It is well known in the exploit scene you don't go directly-jacking into things, you always proxy or you're going to be found in extremely short order.
AMD has no reason to be doing this. Let the game engine handle timing and latency. Stick to your hardware and driver stack and focus on making those top-class instead of what they are now.
> they should know injecting/hooking into the engine .DLL would trigger this from VAC.
More importantly, Valve should have known that triggering based on only this would cause false positives, and picked a better thing to trigger on, and/or acquired better confirmation that the tool was a cheat, before banning.
> AMD has no reason to be doing this
Maybe, maybe not, but that doesn't justify Valve VAC banning people for cheating who aren't actually cheating.
Two similar bugs over multiple decades is an utterly routine occurrence in software development.
Graphics cards and drivers are a marvel of engineering and maths. They work miracles, and are the product of thousands of specialists along the production chain. It’s hardly a damning indictment that they didn’t place compatibility with the anti cheat engines of competitive multiplayer games at the top of their priority list.
Almost certainly there are quite a few different firmware and software engineers working there now, but I agree, and I recall that one thing AMD and ATI had in common even before the merger was being strong on hardware and weak on software.
Where's the hate for valve's anticheat being buggy and too aggressive and unable to identify benign code from cheating code?
I'd be happy to argue the semantics of the mistakes made by AMD, and I probably could be convinced they fucked up. But the ethics of guilty until proven innocent that comes with anticheat software, are so appalling that I'm angry valve isn't getting roasted for saying "we're not going to do anything until after AMD does.
IMO, if your accusations can "ruin lives" (even if it is just a gaming life) you don't get to make mistakes if you're going to ignore them until it's convenient to.
This isn't unique to anticheat, anti-virus and EDR aren't immune to detect a suspicious behavior that many malwares engage in as a false-positive, and flagged a normal process doing something unusual as malicious by mistake.
https://www.reddit.com/r/Amd/comments/177bdfg/amds_antilag_a...
You can also see this pretty telling forum thread:
https://answers.ea.com/t5/Technical-Issues/Account-Falsely-B...
AMD also openly said that they are patching game engine code, which is just bizarre. Not sure what the thought process was. Even if we assume they were aiming to be whitelisted (I'm not sure hooking into game engine code is even common, apparently it isn't), they have still pushed the updates before the whitelisting happened. What was the plan here?
There are open source projects attempting a similar approach to antilag+ ("patching" the DLLs at runtime) but they all seem to warn you about possible anticheat detection on multiplayer games. Again, this was patching the actual engine DLL, not the rendering or graphics related DLLs that drivers sometimes have to patch for specific games.