AMD Counter-Strikes itself, pulls driver after anti-lag feature causes CS2 bans
tomshardware.com
tomshardware.com
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.
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.
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!
IMHO the people who OKed this have some issues.
https://devblogs.microsoft.com/oldnewthing/20040115-00/?p=41...
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
I guess if NVIDIA does it, then it must help. How odd.
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.
Why? Because even if software doing this is legitimate it's can still be used by actual cheaters by patching it.
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.
Iirc, Warzone also sends information about non-existing players to suspected cheaters to attempt detecting aimbots.
Not just that, you can even chuck a flashbang/grenade far outside your visibility range and get someone this way too.
- https://technology.riotgames.com/news/demolishing-wallhacks-...
- https://technology.riotgames.com/news/peeking-valorants-netc...
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.
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.
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 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 does not actually use a queue, but rather two buffer swaps, which means a frame is allowed to skip ahead if completed early.
https://abload.de/img/untitled-2022-06-05-2amey2.png
Anti lag is implementable at the driver level but Anti-lag+ requires code at the game loop level.
They claim to never make mistakes, but that's obviously bullshit since they make mistakes time and time again.
(They killed all community servers two weeks ago btw)
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?
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.
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.
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.
Have you played TF2 recently?
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.
https://www.floridasafetycouncil.org/ClassName/ignition-inte....
And yes, I think that's okay.
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.
Wait that's exactly what you say is wrong?
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.
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.
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.
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.
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.
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"
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.