AMD's Anti-Lag feature is getting gamers banned from Counter-Strike 2
theverge.com
theverge.com
AMD literally made an "internal cheat" for cs2. This is a widely known guaranteed ban and likely among most people (if you modify the game engine then you get banned). Even with weak anticheat like VAC.
This means AMD didn't work with valve at all on this feature, a feature I assume both parties would be interested in. This would be one of the biggest esport games for the anti-lag feature that amd could advertise as supporting.
On top of not contacting valve, they had the expertise to do this, but somehow didn't realize they would get banned?
Somewhat hilariously there's no way they did this for valorant - that game wont even launch if you have debug tools open (unless amd is so dense they worked around that).
This is the third false-VAC since the cs2 beta. First was a unprotected yaw command (no commands should get you vacced unless they're protected by sv_cheats), windows 7 users, and now amd anti-lag+.
Although in the case of AMD, this is definitely not valve's fault. They detected exactly what they're supposed to.
reflex and antilag basically work by flipping the vsync model around. instead of "render a frame -> wait for the monitor to be ready to draw", it's "wait -> render". And by dynamically adjusting the wait time, you can have the frame ready at the last possible moment before the monitor is ready. This means game state is $WAIT_TIME milliseconds fresher, and you've reduced latency by that amount.
well, that means you have to have some method to control when the game starts doing the game loop. So you have to be inside the engine somehow - either you have a WAIT_FOR_REFLEX() in the code, or you grab control of the frame queue and don't return control until you're ready, and you just block until the right moment.
AMD injected that part.
I’m very interested to know what they did beyond standard low latency frame scheduling, and why it required hooking into games to the point of triggering anti cheat
isn't this pretty much exactly what graphics drivers have been for years now though? game-specific behavior, day-one driver updates, and all that. the only (unfortunately) novel thing here is doing this without the express consent and cooperation of the game's developer.
Nvidia did it "properly" and worked with valve to develop it in-engine. I could definitely be wrong but I think many of the game-specific optimizations have to to with how they handle the draw-calls, not modifying the actual games themselves.
The ban system detects the method, not the effect and certainly not the motive.
Reading yes (antivirus).
Writing no, that's rare and generally purposeful.
I have no idea what processes you have that do that unless they're specialty tools like reshade, autohotkey, etc.
Programs do hook the screen for the overlay but that's outside of the game's logic.
It's not at all unusual.
You would have to be manually looking for it then? Also if you do this to the main engine.dll you WILL be banned.
Most of the things you're mentioning you wouldn't hook the main engine.dll, you'd be hooking the system api's, directx, etc.
I'm not sure many people commenting here play competitive games, it's a ruthless cat-mouse war with cheaters. Anticheat is NOT friendly to modding any of the game code. Yes some anti-cheats will ban you for use autohotkey.
From my understanding the newer api's have built in methods to negotiate these optimizations.
And the gpu driver is free to do whatever it likes after the api calls.
So the game tells the driver what to render, which they can reorder/optimize/modify/cache/compile as they like.
What they can't do is hijack the game, and modify it's internal logic.
NVIDIA's Reflex actually requires that it be integrated into the game code by developers (which they then provide) rather than trying to inject itself dynamically, but AMD wanted to have "works in every game!" as a selling point.
Which would also be fine if they had talked to any of the developers and gotten their "cheat" whitelisted, but they didn't do that. Which is the bizarre part. OK, you have a cool thing you can inject into the game code... but you can't inject anything without bringing developers/anticheat in on the release.
And literally everyone from the most basic modder upwards knows this. Gotta be real, real careful about what you inject into games with anticheat, or you'll eat a ban. Even stuff like reshade is a no-no - it's perfectly harmless, but the anticheat doesn't know that. This is basically "reflex as reshade" and has all the same problems around anticheat.
you make it sound like this is a bad thing?
it's also a very rookie mistake, like, you have to think it's either someone brand new they hired in, or someone more experienced really dropped the ball on devrel/etc. This is a situation where they absolutely should have known that they should talk to the gamedevs in advance.
Wrangling all game developers is arguably an impossible task. Building a one size fits all solution is not. Just because it flagged by some anticheat doesn't mean it's failed.
You start off with:
>The people whos entire steam collections are worthless with a lifetime VAC ban are just justifiable collateral in the name of a better future?
But end with the exact opposite conclusion:
>Valve says they'll roll them all back
So... In the end, no steam libraries are worthless and no one got a VAC ban because of it. It seems like the shoot first and ask questions later approach was somewhat successful again.
Which is to say that their anticheat system is defective because the method it uses has false positives -- as exemplified by this case, which is not an attempt to cheat.
Is it? The ToS explicitly says that you will be banned if you inject any code into the game or otherwise modify it, and this injects code into the game resulting in bans. To me it seems more like a business choice to not differentiate between harmless mods and cheats rather than a technical issue with the system.
It's like running across the DMZ. Your intentions don't matter - ALL anticheat will ban you on sight.
You MUST collaborate with the developers to not get banned. This is widely known.
It is expected that _any_ software that does this will be banned, that's how anticheat works. They can't tell what your intentions are and they don't need to.
If AMD worked with valve they wouldn't have to cross the DMZ at all, instead the engine would call the amd driver without any modifications at all.
It's claiming someone cheated when that person did not cheat.
> It's like running across the DMZ.
It's like installing land mines in a residential neighborhood and then blaming the residents for stepping on one. It's not even reasonable if you warn them.
> They can't tell what your intentions are and they don't need to.
They kind of do need to though, because otherwise they punish the innocent. Which is bad. Regardless of whether or not they threaten you with it ahead of time.
> If AMD worked with valve they wouldn't have to cross the DMZ at all, instead the engine would call the amd driver without any modifications at all.
How is that supposed to work with existing games? There are games where the developers no longer even exist but people still play them.
No this is seriously a DMZ. I cannot stress this enough. Seriously any game with anticheat this is an automatic ban. This is not something unexpected whatsoever, this is what anticheat does.
Try this exact same stunt with R6, battlefield, OW, gta, valorant, whatever and you'll get banned almost instantly unless you work with the game developers.
It is very literally anti-cheats job to lay down land mines.
> How is that supposed to work with existing games? There are games where the developers no longer even exist but people still play them.
If there's no anti-cheat there's no problem. If there is anticheat then expect a ban if you try. Anticheat is not mod friendly. You cannot go around modifying the game all you want in online games with anticheat.
> It's claiming someone cheated when that person did not cheat.
This is correct however Anticheat doesn't allow _any_ modifications to the main game code. Seriously test any anticheat in any online game and this will be a ban. There's very, very, very few exceptions ever made to this.
This is not a false positive. What AMD did is identical to what cheats do. You cannot modify the game logic without disabling the anticheat period.
Depending on how AMD did it, VAC may not have any idea _what_ modified the game, just that it was modified in an unintended way.
It's not the anti-cheat's job to decide "oh they hijacked the game engine but they're good guys so its okay".
I cannot stress enough that what they did is IDENTICAL to how cheats work, they just happened to be one of the few with innocent intentions which is irrelevant - nobody may tresspass the game logic.
Generally you cannot do this at all - AMD likely won't be whitelisted - valve will add support in-engine instead.
The anti-lag system is not a cheat. The anti-cheat system thinks it is. By definition, it's a false positive.
Yes but this is not a false positive you fix.
This is a DMZ - you do not cross it no matter what your intentions are. The resolution here will be valve adding in-engine support, and AMD won't modify the game at all.
There is no anti-cheat that will let you cross this DMZ, it's what they do. (technically you could whitelist them but then the drivers become an attack vector).
This is widely known, without collaborating with valve, this is like looking at a mousetrap and knowingly stepping on it barefoot.
It's a feature of the GPU and driver not the game.
Developers of games add api calls to their game engines for things like antilag/nvidia reflex, that if enabled will notify the driver and allow them to do their thing before returning back to an unmodified game.
You do not modify the internal game state - that's a straight red line.
There's lots of places you _can_ generally hijack, such as the final rendering calls which is how most overlays work.
I don't think whitelisting drivers is common either for the same reason cs2 doesn't allow userland applications to be whitelisted - you can potentially hijack that application instead and then your cheats will be whitelisted.
That's strange to me. Why care at all about what individual games do? A GPU driver includes a shader compiler anyway, why can't it do a good enough job at optimizing the shader for the particular GPU architecture? It's kinda the same reason almost no one writes assembly any more, because modern compilers are so good at generating optimized machine code.
They modified where methods returned to so they could run their own code before returning to the game.
VAC cannot determine if this was a bhop-wallhack or an anti-lag feature.
It just sees that someone modified the game.
This is like walking up to someone's building and spray painting a mural without permission. No matter how innocent or well intentioned it is - internal modification is a red line.
What AMD did was like crossing the DMZ. It doesn't matter who you are or what your intentions are. It's not possible for normal applications to do this unless they're specifically trying to.
You cannot cross the DMZ without special permission, and even then it's more likely valve adds it directly to the engine instead.
There's more "accidental" type of detections which would be false positives too - but this is a clear line in the sand AMD crossed.
---
There is no anti-cheat that will let you do this. You contact valve and work with them to add support in engine. What AMD did was insane.
Shit happens and will be fixed. Still better than splitting the community. They need to work with AMD and resolve the issue.
I'm guessing a scheduling thing, but have absolutely no data. This is on Fedora Linux with a very recent kernel, Mesa, and gamescope
It should theoretically be possible to get the tear-free smoothness of vsync combined with even lower latency than vsync disabled, but in reality is it is difficult to predict how long a frame will take to render
It’s not clear how they solved this, or why it required hooking into games more than graphics drivers already do
If you don't underestimate the render time (and miss the refresh) then the frame will be fresher.
What Anti-Lag does is throttle the CPU work to reduce this delay to as low as sub-frame, so it doesn't process input and begin frame processing until closer to display time -- so the game starts frame updates with fresher input and gets those frames out with less delay. Graphics APIs often only allow setting the frame queue length in an integer number of frames and it can be difficult to reliably tell when frames present and control frame queuing, especially with a compositor involved. This has the graphics driver involved, so it knows the absolute truth of when frames hit the output.
Wouldn't the game limit that to 2-3 frames at most?
> Graphics APIs often only allow setting the frame queue length in an integer number of frames and it can be difficult to reliably tell when frames present and control frame queuing, especially with a compositor involved.
I'm pretty sure you can control the swap chain using DXGI:
> Use DXGI 1.3 to reduce the effective frame latency by waiting for the swap chain to signal the appropriate time to begin rendering a new frame.
https://learn.microsoft.com/en-us/windows/uwp/gaming/reduce-...