Anticheat check - which competitive games actually work on Linux?
Anticheat check - which competitive games actually work on Linux?
Want to switch from Windows to Linux / SteamOS but concerned about games with anti-cheat on Linux? Here's all you need to know on what you can play.Liam Squires-Hand (GamingOnLinux)
like this
asudox
in reply to cm0002 • • •like this
Sexy Animal Fucker y yessikg like this.
MrSoup
in reply to cm0002 • • •like this
Sexy Animal Fucker likes this.
Carlos Solís
in reply to MrSoup • •like this
yessikg likes this.
Gloomy
in reply to Carlos Solís • • •But... why?
like this
yessikg likes this.
Carlos Solís
in reply to Gloomy • •Lemmchen
in reply to cm0002 • • •Good guy Embark Studios
Eggymatrix
in reply to cm0002 • • •like this
yessikg likes this.
andyburke
in reply to cm0002 • • •Anticheat code belongs on the server, where the environment can be controlled and trusted.
You can never trust the client. Never.
like this
RandomStickman, Carlos Solís y yessikg like this.
9point6
in reply to andyburke • • •One of the big problems is stuff that a server wouldn't know is happening
A simple example is wallhacks in FPS games, if you can somehow get the client computer to not render walls properly, the player can see where everyone else is in the level.
You don't need to mess with the game client here if you're clever about it, you mess with the operating system and graphics drivers so that a signed binary can continue to connect and behaves entirely legitimately from the server's perspective.
Of course there are mitigations we could come up with for this, but you're just in a game of cat and mouse. If it was a solved problem, kernel level anti-cheat just wouldn't be a thing for the most part. Yet it's what the competitors demand in the top flight competitions, because there isn't a better way to prevent a whole class of cheating.
To be clear, not defending it and I personally avoid games that use it, but I understand why it exists
renegadespork
in reply to 9point6 • • •This is definitely solvable, though. The server can only send the client location updates of players they should be able to see.
If someone tried to wall hack, they’d only see the last known location before line of sight was broken.
Giving the client that data at all is like playing Battleship side-by-side and telling the player not to look at the other board.
like this
yessikg likes this.
9point6
in reply to renegadespork • • •This is what I mean by obvious mitigations
You could definitely hide far players, but as soon as a player is near enough they could be seen, particularly when dealing with humans making unpredictable input, that player's model will need to be placed in the world before either of them are supposed to see each other because the game has no way of knowing what that unpredictable input might be.
You can't have every permutation of a given player model being obscured by every possible combination of angles of scenery as distinct models in the GPU memory, so something client side will need to do that slicing, so a player's obscured origin location will need to be known by the client. This could give a player seconds of time to react depending on their opponent's strategy
A few milliseconds is the only advantage a player needs at the top level of these games to shift the balance in a given contest.
renegadespork
in reply to 9point6 • • •But the server is the authority on player location. It can tell if a player is visible to another because it knows their locations (as well as any obfuscations) at any given instant. It doesn’t need to know what they’re going to do next until it gets that next input from the client.
Obviously calculating this requires more work on the server’s part, but in smaller competitive matches this is totally doable. We’re talking basic wireframe vectors.
9point6
in reply to renegadespork • • •Right, but as I mentioned unless you have an actual infinite number of variations of every player model (impossible, you can't store infinite variations in fixed storage), you're going to need the full player model in GPU memory and something client side will need to do the chopping with knowledge of the players origin coordinates, it's impossible to determine the shape of and position the chopped shape without sending that information to the client. Streaming graphics data from a server into even a top of the line GPU would be a prohibitive hit to game performance when milliseconds matter.
It's not processing power that's the problem, it's the speed of light
renegadespork
in reply to 9point6 • • •I think you're overthinking it. You don't need to render every skin. You just need a box that's the maximum bounds for that player model. Again, we're talking really low poly wireframes.
These bounds are standardized across every client, so the server already knows this information.
Games already do this with hurt boxes.
ulterno
in reply to renegadespork • • •You seem to not be taking into consideration:
- lag
- extra information required for graphics stuff, like shadows
The reason your client computer needs to know the opponent's location when they are still 1m on the other side of the wall, is because, within the next 100ms, you might make a jump+move action which lets you see their shadow or the tip of their weapon.
The shadows and reflections need to be calculated on your system or the server would be doing too much work and if you find the opponent pop up where they clearly were not, 50ms ago (because the server just told you now), you won't be particularly happy either (I know I won't).
zlatko
in reply to 9point6 • • •I thought kernel-level is needed more because windows has such architecture that you basically need kernel level access to ensure stuff is correct.
As for it being a solved problem, even games with it enabled have cheaters, so I don't think it's solved either way.
9point6
in reply to zlatko • • •It needs to be kernel level (on any OS with remotely modern security design) because a userspace application (quite rightly) would not have the ability to monitor all hardware at a low level and probe semi-arbitrary memory locations. It's the same reason enterprise security software often has a kernel module of some kind.
That's the level that is necessary to protect the integrity of top flight eSports. It's worth highlighting the anti-cheat bundled with retail games it's often a less severe version of what I'm talking about, the competitions where you can ultimately win money almost always use an additional heavier invasive anticheat than is typical for a casual player.
The companies proving those third party anticheat systems would risk losing their business and reputation if a cheater was able to evade it in any competition scenario. The reason you see cheaters in public servers, is regular users (also quite rightly) wouldn't put up with the super invasive versions of these systems that provide the strongest guarantee, so you're seeing the effects of that compromise.
mkwt
in reply to andyburke • • •renegadespork
in reply to mkwt • • •🇰 🌀 🇱 🇦 🇳 🇦 🇰 🇮
in reply to andyburke • • •Can't stop aimbots and wallhacks server side.
I always thought a good way to handle a huge swath of cheating would be to see what the limits a real human could actually do, and if it's impossible (like having a reaction speed faster than 2 miliseconds) it's flagged. Though the one game I know for sure has done this also had a huge problem with false positives. I guess no one working on Planetside 2 thought you could ever kill 1000 people with a single grenade; despite it being a clusterfuck of an MMO with plenty of people getting stuck in a doorway for that to be entirely possible and not even too hard to pull off.
And even that wouldn't necessarily stop wallhacks and aimbots.
Now a days, I am convinced the only way to really mitigate (and not even fully stop) cheating would be to have a human referee. Like CS's Overwatch program. And you might also need it to use an AI agent to analyze everything for pattern recognition because it can be really easy to hide cheating from actual people.
StrikeForceZero
in reply to andyburke • • •This always grinds my gears. When I was hosting custom Minecraft servers back in 2011 we had so many anti cheat measures in place. Prevented people from moving too fast. Randomized blocks until you exposed them so xray wouldn't work. Logblock to identify griefers and do immediate rollbacks.
I remember this one time we had a group get on and grief someone that didn't set up a claim yet and they thought they were so sneaky by distributing the loot amongst friends and chests. We just followed the stacks in the logs and restored everything then banned them. We actually had more people end up joining because how much auditing we could do, they probably felt like they could invest time into the server.
Now it's like "oh we can't ban them until the next ban wave because we don't want them to know how we caught them". It's lazy. Back in the pubg days I remember seeing someone get 75 kills in a matter of 3 minutes. They didn't get banned. They didn't even have line of sight. Ban waves still allow peoples experiences to be compromised.
like this
yessikg likes this.
teawrecks
in reply to andyburke • • •This is unfortunately easier said than done. This defcon talk from 14y ago comes to mind.
If 100% of the game state is server authoritative, then there are always exploits in the netcode. Because either you have netcode that is so rigid that the first time a packet is late, or some floating point math doesn't add up right, you don't know what to do and break; or you have netcode that makes up for little discrepancies, and hackers eventually find them and abuse them.
It would be nice if the client isn't told about player locations they don't see yet, but now the server has to calculate occlusion for every player vs every opponent on every server tick. And let's say you find a magically optimized way to do this, now how do you attenuate sounds like footstep or gunshot dynamics?
Anticheat is always an arms race. There is no "just do X, and you've defeated the cheaters". Contrary to popular belief, hundreds of very smart people have been working at solving these problems for literally decades, and the arms race always ends up on the client.
DEFCON 19: Hacking MMORPGs for Fun and Mostly Profit
Christiaan008 (YouTube)Creat
in reply to cm0002 • • •Predecessor also works (3rd person moba, free to play).
It uses easy anti chat, but the existing Linux compatibility in that is clearly turned on, which isn't to common unfortunately.
Baggie
in reply to cm0002 • • •