Valve urges AMD users to disable the Anti-Lag+ feature, due to causing VAC bans.

[grg994]

6 hours ago, RejZoR said:

How is this AMD's fuckup?

6 hours ago, StDragon said:

It's not AMD's fault.

 

I'm sorry but could the user space GPU driver just do it's own fucking job and not to touch anything else?! Like WTF.

 

The shared library (".dll") of the user space GPU driver has to be loaded into the memory address space of every app that needs a graphics context. It's code runs with same full privileges as the app that loads it - i.e. the GPU driver can access every data that the app handles: passwords in a game, secrets in a browser window, banking data, everything... It is crucial trust issue that the GPU driver does not abuse it's position for any reason.

 

Just simply the inclusion of a functionality that AMD did here with "Anti-Lag+" - a GPU driver code part to messes with the host application / game - is unacceptable even without causing any issue with an anti-cheat.

 

I can't believe there are people who are seriously OK with a GPU driver touching private parts of their applications for ANY reason (not to mention for a few ms lower frame latency in a stupid video game).

 

Btw the same goes for what nvidia did not too long ago: Nvidia drivers phones home if you load an LLM

 

I'm so glad I'm on Linux now where we have open-source drivers and none of such bullshit can ever happen.

[Forbidden Wafer]

7 hours ago, Error 52 said:

Astonishing fuck-up from AMD here, frankly. It seems utterly baffling that they didn't consider this a direct possibility from tampering with games that have anti-cheat and didn't even consult Valve about it. And if it's tripping up VAC, god help them with any games that have Ring-0 anti-cheat.

It is actually an anti-cheat fuck-up. How come a driver manufacturer can't touch their drivers and break stuff?

It is up to anti-cheat makers to keep up with driver manufacturers, if they touch low-level stuff they shouldn't be touching in the first place.

[Mark Kaine]

13 minutes ago, Forbidden Wafer said:

It is actually an anti-cheat fuck-up. How come a driver manufacturer can't touch their drivers and break stuff?

It is up to anti-cheat makers to keep up with driver manufacturers, if they touch low-level stuff they shouldn't be touching in the first place.

exactly,  all this does is show how outdated and archaic valve really is... not too surprising if people would actually care about who the owner of this company is and what his background is (truly some of the worst/evil in the business,  albeit successful tbf lol)

[Mark Kaine]

45 minutes ago, grg994 said:

I'm so glad I'm on Linux now where none of such bullshit can ever happen

i mean whatever works for you, i have a pc to mod and emulate games, nothing  else really, and anything but windows is just too much headache for this purpose ... thankfully there are ways to make windows "shut up" (*wink wink*) and make it behave like a normal person  (hint, hint: kill update orchestrator and you're good to go basically,  but make sure he's really dead xD )

 

Spoiler

 

 

[porina]

8 hours ago, Error 52 said:

Well, it's not just Counter-Strike. And I don't understand how companies could possibly whitelist a feature that directly tampers with the game files and, quite clearly, they had not been given any kind of heads-up or warning about.

Thinking about it more widely, any game that uses VAC could be potentially affected.

 

7 hours ago, Mark Kaine said:

i find it kinda funny that a bit of dll tinkering triggers an "anti cheat", but then again i would never play a valve game, play stupid games win stupid prizes, i guess... ¯\_(ツ)_/¯ 

Different games have different tolerances to modifications. For an online multiplayer competitive shooter then fairness is going to be high up on the list of priorities. If you're playing a single player offline game, who cares if you mod?

 

7 hours ago, Mark Kaine said:

its a very stupid system though because you just need to "fix" the CRC thingie and the "anti cheat" will never know  

It's a bit more complicated than that. Even if the anti-cheat isn't perfect, if it works at all in reducing the exploits it is still a net gain.

 

6 hours ago, grg994 said:

I'm sorry but could the user space GPU driver just do it's own fucking job and not to touch anything else?! Like WTF.

 

The shared library (".dll") of the user space GPU driver has to be loaded into the memory address space of every app that needs a graphics context. It's code runs with same full privileges as the app that loads it - i.e. the GPU driver can access every data that the app handles: passwords in a game, secrets in a browser window, banking data, everything... It is crucial trust issue that the GPU driver does not abuse it's position for any reason.

Not a programmer but while part of the driver may run at the same privilege level as the code it is talking to, does follow it has complete access to all the associated data? Was thinking it has access to whatever it is given as part of normal operation.

 

Other parts of the driver may have lower level access.

 

5 hours ago, Forbidden Wafer said:

It is actually an anti-cheat fuck-up. How come a driver manufacturer can't touch their drivers and break stuff?

It is up to anti-cheat makers to keep up with driver manufacturers, if they touch low-level stuff they shouldn't be touching in the first place.

If AMD stuck to touching their own stuff this wouldn't have happened. They poked around where the game said no. Going forward, both devs (in general) and AMD would have to get a common understanding of exactly what is ok or not, and what access is needed to implement new driver features. This may result in a new interface specifically for that type function without opening holes for exploits.

[grg994]

1 hour ago, porina said:

the driver [...] Was thinking it has access to whatever it is given as part of normal operation.

The loaded ".dll" of the GPU driver has exactly the same access to everything inside the memory address space of the process as the ".exe" itself that load the ".dll"s.

 

It is not possible* to have separation there. This is why fixing errors by downloading ".dll"s form untrusted sources is so dangerous, as it has exactly the same security implication as changing or patching the ".exe" itself and then running it.

 

(*: -browsers separate their gpu driver-using rendering functionality to a separate process, but that is to protect the cannot-be-sandboxed rendering code from an exploited javascript browser content process as a last line of defense.

-there are some cpu architecture specific exploit protections... - not of them meant to or can prevent tampering done from a rouge ".dll" )

 

Among this everything in the process that the gpu driver has access to - there are some essential data structures that describe how the code from the ".exe" or a ".dll" can find functions provided from other ".dll"s (such as the global offset table / GOT). Manipulating these data structures is a common way of "[sic] detouring engine dll functions". These data structures should normally only be touched by the operating system that assembles the program form the ".exe" and the ".dll"s. Manipulating it form the program has no legitimate use under normal conditions - other than debugging or hacking (or game modding).

 

I must say I don't know and I didn't research what exactly AMD is doing by "detouring engine dll functions", but as it can be interpreted by common sense as a programmer it is something that one should never expects from a legitimate runtime dependency (eg. gpu driver) of its program to ever be done.

 

AMD is effectively modding Valve's game. Now, what are the rules if you want to mod a competitive multiplayer game? (I leave this question open...)

[Mark Kaine]

3 hours ago, porina said:

Different games have different tolerances to modifications. For an online multiplayer competitive shooter then fairness is going to be high up on the list of priorities. If you're playing a single player offline game, who cares if you mod?

yes, and i admit i don't know all the details,  but what im saying vac has a long standing history of "false bans" and is also relatively easy to trick into thinking there aren't any cheats running...

 

also the games i was thinking about where indeed mostly multiplayer,  tekken, monster hunter, etc, just like vac their anti cheat isnt very good and can be easily manipulated (mind you i don't use this to cheat, even though some mods could be seen as such,  like more damage at certain framerates,  but then again there are games that do this without any modification already) 

 

 

i don't really have a solution i just think valve should update how their ac works.

 

 

3 hours ago, porina said:

It's a bit more complicated than that. Even if the anti-cheat isn't perfect, if it works at all in reducing the exploits it is still a net gain.

two edged sword tho, if there are too many false detections... like edit ini, dll, etc, shouldn't really get you banned imho (and it doesn't in many games)

 

like in this example,  yes amd effed up, but it wasn't anything malicious, and its also not as dramatic because its a big gpu vendor,  other smaller such cases will just be put under the rug as "obvious cheaters"

[Doobeedoo]

It's rather interesting though, yet it is a driver, anticheat should have better knowhow and differentiation for it vs anything else by default at this point. 

[Zodiark1593]

While bans as a result of the new driver should absolutely be reversed, I have to question if routing around application .dlls is something that a driver, the software with highly privileged access to the computer, should be doing. I would prefer a driver not to touch anything else, unless absolutely necessary. 

[Kisai]

On 10/13/2023 at 11:12 AM, Error 52 said:

 

I dunno, I remember old 2000's anti-cheats being giant piles of shit that would kick you for looking at them funny.

Most anti-cheat software doesn't do anything about trampolines. Most software isn't written well enough to avoid patching into the C runtime. 

 

If you want a game to be "unhackable" within reason it can't have a directory full of DLL files. There should be a single binary for the game and the assets need to be broken up accross multiple packages and checksum'd at load time.

 

But your average game can be tampered with by dropping a dll file into it's directory of the same name as an OS DLL, and pass all the functionality to the real DLL, but also adding it's own instructions to hijack the anti-cheat so the game thinks it's still running. 

 

Point is, most older anti-cheats didn't try to protect the game runtime environment, it only made attempts to protect the connection integrity (eg against aim-proxies and such.) You only achieve a perfect uncheatable game by streaming the game as a video to the end user, so there is no "data" for the end user to tamper with. Even then, AI is good enough now that you could simply "Train" an AI on footage to do things that you'd normally be able too hook into the game about. A lot of extra wasted processing power in doing all this, but if a game has to be perfectly uncheatable, that's the cost. It throttles down "AI bot" players to the speed of a regular player, rather than a player that knows where everything is at any moment.

 

 

[Albal_156]

With how quick AMD responded to this issue (the responded the same day in fact, plus they've pulled the driver from beig downloaded) I'd expect this to get resolved fairly quickly and by then it will have been forgotten about.

I also don't play CS2.

And AntiLag+ was marketed more towards reducing Latency brought about by FSR3/AFMF anyway.

Unless they are also saying that Regular AntiLag is also doing this.
The worst part of this is the fact that HYPR-RX and Quality mode auto enables this though.

[LorenzoS89]

I think that the discussion should be a little bit expanded by taking this event as a starting point.

 

First question is, does this AMD "hack" does really give an advantage to the players who activate it? how does it compare to the effect of the Nvidia sibling software?

Second point, and is what I think is most important, shall we allow these GPU companies to implement additional software, and release them only on specific series of products, that influences so much the game experience?

Of course on single player games doesn't really matter (unless there is some sort of record one can achieve) but on multiplayer games it is imperative that every player must have the same chances to compete with others. Of course you can tweak the game options (like lower resolution for more FPS) but anything external of the game should be banned i think.

Neither Nvidia or AMD drivers should "hack" the game...

[StDragon]

7 hours ago, Kisai said:

Even then, AI is good enough now that you could simply "Train" an AI on footage to do things that you'd normally be able too hook into the game about. A lot of extra wasted processing power in doing all this, but if a game has to be perfectly uncheatable, that's the cost. It throttles down "AI bot" players to the speed of a regular player, rather than a player that knows where everything is at any moment.

Give it 5 years or so. It won't be long belong before video and HID is piped to another computer that's run by AI. A true bot playing.

Goals could be to grief, give aid to a team, or some other financial gain. The only remedy is LAN party play, invite, or public voting to kick/ban the offending bot. 

[Zodiark1593]

14 hours ago, Kisai said:

 

 

Point is, most older anti-cheats didn't try to protect the game runtime environment, it only made attempts to protect the connection integrity (eg against aim-proxies and such.) You only achieve a perfect uncheatable game by streaming the game as a video to the end user, so there is no "data" for the end user to tamper with. Even then, AI is good enough now that you could simply "Train" an AI on footage to do things that you'd normally be able too hook into the game about. A lot of extra wasted processing power in doing all this, but if a game has to be perfectly uncheatable, that's the cost. It throttles down "AI bot" players to the speed of a regular player, rather than a player that knows where everything is at any moment.

 

 

A hybrid cloud approach would also do the job. Run a VM on the server for all the players, which will handle all the logic, and send back only the data required for the client to render a frame. Perhaps some visual-only physics effects can also be performed client side. 
 

This will reduce bandwidth demands, and lower server costs, vs a full cloud solution with rendering. 

[porina]

8 hours ago, LorenzoS89 said:

shall we allow these GPU companies to implement additional software, and release them only on specific series of products, that influences so much the game experience?

This is an easy one at least - yes! One way to say why is to imagine the reverse. If a new feature had to work on all hardware, how far would you have to go back? There will be a point where it doesn't make sense for the feature because the hardware is obsolete. So they could never make it universal support regardless and have to choose what hardware to support.

 

They will start with the newest, and then work out how far back makes practical sense to go back. I haven't followed if there is a reason why anti-lag+ requires current gen AMD. Either it requires a hardware feature not present on older models, or, they simply haven't had time to validate a release for older GPUs yet. I suspect it may be the latter, and they might expand support looking forwards. 

 

8 hours ago, LorenzoS89 said:

Of course you can tweak the game options (like lower resolution for more FPS) but anything external of the game should be banned i think.

Players seeking an advantage do have options outside of the game. Compare a normal mouse vs gaming mouse, or 60 Hz display vs 240 Hz displays.

 

My mouse is running at 125 Hz, but supports 1000 Hz. If I change the setting, that reduces the interval between checks for input from 8ms to 1ms. Why don't I change that setting? Two reasons. 1, I don't play games where up to 7ms reduction in worst case latency would really make a difference. My reactions are so bad now it is on geological timescales. The other: some games actually break at high polling rates. Vigorous mouse movement in those games would result in a severe drop in fps. I think they get overwhelmed with all the data coming in.

 

In a competitive environment, then everyone will get the best they can. The advantage is more like a paywall but it is accessible to all. Once everyone has it, does anyone have an advantage any more?

[Sauron]

On 10/13/2023 at 8:03 PM, Error 52 said:

Astonishing fuck-up from AMD here, frankly.

I would posit that AMD is under no obligation to anticipate every possible anti-cheat method that gives a false positive when doing something completely harmless...

On 10/14/2023 at 1:42 AM, MarkPol88 said:

Any tamper with game's DLL's is a big "no no" for anticheats for well over a decade - that's how.

Maybe it's the most effective, or the only, way of achieving the performance improvement they were targeting. It's valve who should whitelist this since it's a completely legitimate thing to do.

[hishnash]

40 minutes ago, Sauron said:

Maybe it's the most effective, or the only, way of achieving the performance improvement they were targeting. It's valve who should whitelist this since it's a completely legitimate thing to do.

Its not always easy to whitelist DLL mutations without opening up a pathways for attackers.

It will depend on how AMDs driver is patching the DLL and at what stage of the runtime they are doing it.  Since the solution they have attempts to target many games I might well not be a very deterministic patch (each time you apply it the result much per other different (from a digital signature persecutive).  If each time it patches it the memory signature is differnt then detecting that this was AMD and not someone else is very very difficult. 
 

[hishnash]

5 hours ago, Zodiark1593 said:

A hybrid cloud approach would also do the job. Run a VM on the server for all the players, which will handle all the logic, and send back only the data required for the client to render a frame. Perhaps some visual-only physics effects can also be performed client side. 
 

This will reduce bandwidth demands, and lower server costs, vs a full cloud solution with rendering. 

You need to also do some server side culling here to ensure clients are not doing hacked like having see-through walls... and even then what is stopping a cheater form having a local patch that just makes all hostels render bright pink and be ultra visible, or having softare locally that provides an auto aim based on the location of the enemy in frame. 

The only solution to not need client side anti cheat is either a full secure boot chain (aka macOS with device check) or a mile high stack of (cat and mouse) anti cheat tools that have a good number of false positives..   the secure boot chain option were you have a secure enclave that can sign and attach the boot chains crefeicates of the kernel, and all the user space libs your app has loaded and the app itself and return these to the server for you to validate as being legit is a valid option but would require decided HW (I expect MS Pluton chip will offer something like Apple device check api)

[leadeater]

On 10/14/2023 at 2:24 PM, grg994 said:

 

I'm sorry but could the user space GPU driver just do it's own fucking job and not to touch anything else?! Like WTF.

 

The shared library (".dll") of the user space GPU driver has to be loaded into the memory address space of every app that needs a graphics context. It's code runs with same full privileges as the app that loads it - i.e. the GPU driver can access every data that the app handles: passwords in a game, secrets in a browser window, banking data, everything... It is crucial trust issue that the GPU driver does not abuse it's position for any reason.

 

Just simply the inclusion of a functionality that AMD did here with "Anti-Lag+" - a GPU driver code part to messes with the host application / game - is unacceptable even without causing any issue with an anti-cheat.

 

I can't believe there are people who are seriously OK with a GPU driver touching private parts of their applications for ANY reason (not to mention for a few ms lower frame latency in a stupid video game).

 

Btw the same goes for what nvidia did not too long ago: Nvidia drivers phones home if you load an LLM

 

I'm so glad I'm on Linux now where we have open-source drivers and none of such bullshit can ever happen.

I think you are confused about what Anti Lag+ is and how it works. Anti Lag+ is not globally supported and games have to support, 12 at feature release, and only RX 7000 support it as well. It's not breaking in to memory or doing anything that is not completely normal for any game engine integrated GPU feature or any external third party library that a game/game engine loads in.

 

Would you say the exact same thing about a third party physics library, Physx for example? Since that's what is was/and or still is.

 

However how it works is actually understandable for an Anti Cheat protection to get triggered over since an external input from the game itself is happening in the render/draw call since Anti Lag+ purpose is to delay dispatch to the CPU pipeline ensuring the CPU is not overloaded allowing a little more CPU resources to be used for existing in progress draw calls.

 

Quote

Optimizing draw calls

To draw geometry on the screen, Unity issues draw calls to the graphics API. A draw call tells the graphics API what to draw and how to draw it. Each draw call contains all the information the graphics API needs to draw on the screen, such as information about textures, shaders, and buffers. Draw calls can be resource intensive, but often the preparation for a draw call is more resource intensive than the draw call itself.

https://docs.unity3d.com/Manual/optimizing-draw-calls.html

 

All Anti Lag+ is doing is blocking this as it sees fit, which is a potential violation of Anti Cheat engines if they have not been updated to be aware of this.

 

The "Should we be doing this" is perfectly valid, all the fearmongering not so much.

[LAwLz]

There seems to be a lot of confusion regarding these news right now.

 

 

Here are some things I would like to know.

1) What's the difference between Anti-Lag and Anti-Lag+? From what I understand, Anti-Lag is something where AMD basically hijacks a game and modifies it, while Anti-Lag+ is a library that the game developers implement into the game. 

 

2) Are people being banned because of Anti-Lag, Anti-Lag+ or both?

If the two technologies work like I understand them, then I would say the blame is 100% on AMD if people get banned for using Anti-Lag.

If I understand the two technologies correctly and people are being banned because of Anti-Lag+, then I would say the blame is on the game developers and AMD, but mostly on the game developers. 

 

 

My stance is usually that it's the one who makes changes to the code that is responsible for what happens because of the changes. If this started happening because of a driver update from AMD, and no chance has been made to the game itself, then I think it's really hard to put the blame on the game developers, since everything worked before AMD made changes.

However, if this is something the developers put into their games then the responsibility falls on both the game devs and AMD. The game devs for validating how their game works after implementing it, and AMD for making sure that their new product (Anti-Lag(+) is a product they provide to a business) actually works as intended in games. 

 

 

 

 

I think it's important to note that Anti-Lag and Anti-Lag+ are two separate things before we continue this conversation.

It doesn't help that news articles about this seem to use Anti-Lag and Anti-Lag+ interchangeably when it seems like the two are very different.

 

 

 

It's also worth noting that it's not just CS 2 and Valve's anti-cheat system that seems to be having issues. People have been reporting issues with Apex Legends (bans) and COD Warzone (performance issues and crashes) as well.

 

 

I guess it's best to just leave it off for now and give it a few weeks so that AMD and/or game devs get some time to iron out the issues. 

[porina]

26 minutes ago, LAwLz said:

Here are some things I would like to know.

1) What's the difference between Anti-Lag and Anti-Lag+?

2) Are people being banned because of Anti-Lag, Anti-Lag+ or both?

Good questions. Note I trimmed the quote a bit. I suppose a 3rd question is, how do these compare to the competition? Not that it helps AMD users.

 

I refer back to the tweet from CS as an official source, which stated:

Quote

AMD's latest driver has made their "Anti-Lag/+" feature available for CS2, which is implemented by detouring engine dll functions. If you are an AMD customer and play CS2, DO NOT ENABLE ANTI-LAG/+; any tampering with CS code will result in a VAC ban.

The way they write /+ doesn't really help clear things up. I read it as both versions are affected. I'm not sure that makes any sense since Anti-lag without + has been around since 2019.

[leadeater]

14 hours ago, LAwLz said:

What's the difference between Anti-Lag and Anti-Lag+? From what I understand, Anti-Lag is something where AMD basically hijacks a game and modifies

Anti Lag is the game agnostic one that doesn't actually touch the game at all. The GPU driver artificially limits the amount of CPU work that is allowed to be queued up or actively dispatched and running (not sure exactly which but overall I don't think matters here) but this doesn't interact or synchronize with the game so it's not the most 'efficient' method.

 

Anti Lag+ is leveraged by the GPU game profiles, where the game support requirement comes from as QA testing is required, that is used to load in the Anti Lag+ dll in to the game executable or inject code in to an exiting dll/exe at run time (not sure, probably the second?) i.e. not persistent. Anti Lag+ synchronizes with the game to know the current and future rendering demands and uses that to limit what is allowed in to the CPU workload queue.

 

Normally only the game (and utilized game engine) would be loading in dlls or code however Anti Lag+ is loading in 'game unaware'. The loading in of a dll isn't any more or less trusted than any other dll and I'd challenge anyone to know what dlls they know are being loaded in for any application they run and how trusted they are. That's why we have code signing  and digital signatures so something smarter (the OS) than us to determine at some level if it is 'safe' or not.

 

I think the bigger issue is, and not for me personally really, that should we be loading dlls or code in to executables without the executable asking for it? I don't think there is a completely solid yes/no on that. I wouldn't want to stand in the way of some actually good feature or technology because "always no" but to be honest Anti Lag+ ain't it.

 

14 hours ago, LAwLz said:

Are people being banned because of Anti-Lag, Anti-Lag+ or both?

Anti Lag+ only. Also only Valve's anti cheat, no other is banning due to it so far in online competitive games.

 

Surprisingly the technical details on Anti Lag+ are essentially non-existent. 

[leadeater]

19 minutes ago, porina said:

Good questions. Note I trimmed the quote a bit. I suppose a 3rd question is, how do these compare to the competition? Not that it helps AMD users.

Nvidia Reflex is an engine plugin so it's part of the build of the game, meaning it's not external to the game or executable and is being loaded on demand by the game itself, so less likely to be hit by anti cheat. It's the technically more proper way to do it but also the harder or really less broad approach that will never give retroactive support.

[Zodiark1593]

4 hours ago, hishnash said:

You need to also do some server side culling here to ensure clients are not doing hacked like having see-through walls... and even then what is stopping a cheater form having a local patch that just makes all hostels render bright pink and be ultra visible, or having softare locally that provides an auto aim based on the location of the enemy in frame. 

The only solution to not need client side anti cheat is either a full secure boot chain (aka macOS with device check) or a mile high stack of (cat and mouse) anti cheat tools that have a good number of false positives..   the secure boot chain option were you have a secure enclave that can sign and attach the boot chains crefeicates of the kernel, and all the user space libs your app has loaded and the app itself and return these to the server for you to validate as being legit is a valid option but would require decided HW (I expect MS Pluton chip will offer something like Apple device check api)

To avert wall-hacks, any information not visible to the player, would simply not be sent to the client. In this case, anything on the other side of an opaque wall is not going to be rendered, nor even exist client-side. 
 

Hypothetically, the client can throw whatever wall hacks they want, but because they don’t actually have the data of the player locations, it won’t do much useful. 

[BabaGanuche]

1 hour ago, Zodiark1593 said:

To avert wall-hacks, any information not visible to the player, would simply not be sent to the client. In this case, anything on the other side of an opaque wall is not going to be rendered, nor even exist client-side. 
 

Hypothetically, the client can throw whatever wall hacks they want, but because they don’t actually have the data of the player locations, it won’t do much useful. 

That would prevent such this as players emitting directional sound. You have to know where the opponent is to have directional sound being emitted from them.