The Issue of Anti-Cheat on Linux (2024)

The problem is that server-side occlusion is only a small piece of the puzzle. A naïve implementation means hundreds of thousands of raycasts per second, which doesn’t scale. Real engines rely on precomputed visibility sets, spatial partitioning, and still have to leak some data client-side for responsiveness.

Basically - the kernel level check is not laziness, but for unsolvable problems without huge compute costs or latency.

I think you already know the answer. Yes, it's bottlenecked by latency and jitter (of the laggiest player, no less), and in addition to that the maximum possible movement velocity makes it much much worse in fast paced games. It's been attempted a few times since at least late 90's, with predictable results.

In other words, complete server-side calculations are a fantasy. Besides, they won't even remotely make cheating impossible or even harder! Even complete hardware lockdown won't.

The naive raycast from player camera to other player would be fine for perf but may count partially visible as invisible, so its unacceptable. You'd have to raycast every pixel of the potentially visible player model to stay conservative. With movement + latency this expands to every pixel the player model could potentially occupy during your max latency period, and you need to consider the viewer moving too!

In practice this expands to a visibility test between two spheres with radius max_latency*max_movespeed + player_model_radius. Now, you could theoretically do a bunch of random raycasts between the spheres and get an answer that is right some of the time, but it would be a serious violation of our conservativeness criteria and the performance would get worse with more rays/better results. Also keep in mind that we need to do this for every single player/player pair a few dozen times per second, so it needs to be fast!

To do this, you need a dedicated data structure that maps volumes to other volumes visible from said volume. There are a few, and they are all non-trivial and/or slow to build well. (google for eg. potentially visible set, cell-portal graph + occlusion). You also trade performance for precision, and in practice you walls might become 'transparent' a bit too early. With all this being done, we can actually "do occlusion calculations server-side".

There's just one problem with this that I still don't know a solution for, namely precision. With fast players and imprecise conservative visibility, things you care about are going to count as visible pretty often, including stuff like enemies peeking from behind a corner (because they could have moved at full sprint for 100ms and the end of the wall is rounded away in your acceleration structure anyway) so all this complexity might not get you that much, particularly if your game is fast paced. You'd prevent some wallhacks but not the ones that really matter.

TLDR yes, it's actually hard and might not be good enough anyway

The first is "never trust the client", i.e. realtime validation and having the server be the sole authority on the current game state. This is the straightforward solution to think of for programmers, but it's also practically infeasible due to latency, etc.

But what the server could do is a "trust but verify" approach: accept data from the clients when they submit it, but have some background processes that can analyze the data for anomalies and, if too much of it was detected, trigger a ban.

The only problem I see with this approach is that cheaters might react by repeatedly making new accounts and playing as them until the verification process has caught up and bans the account.

Cheating would be more obvious - as cheaters would have to start over with a beginner character every time - but it could still be annoying.

So the problem of ban evasion would become even more important. And I don't really see how a purely server-side solution could work there.

I'd argue the potential for abuse is a perfectly reasonable discussion to have, and doesn't have much bearing on the effectiveness of anticheat, but I understand that's not the point you are trying to make.

As does Valorant and virtually every other first person shooter. The cheats aren't people flying around or nocliping, it's wallhacks and aim assists/bots.

For instance, a common cheat in Street Fighter 6 is to trigger a drive impact in response to the startup of a move that is unsafe to a drive impact. That is recognizing the opponent's animation and triggering an input. There's no part of that which cares where the game simulation is being done. In fact, this kind of cheating can only be detected statistically. And the cheats have tools to combat that by adding random triggering chances and delays. It's pretty easy to tune a cheat to be approximately as effective as a high-level player.

Kernel-level anticheat isn't a perfect solution, but there are people asking for it. It would make cheating a lot harder, at least.

Yes, game publishers are trying to turn PCs into a gaming console, which IMO will always be a futile effort, and is quite frankly annoying. I don't game on PC to have a locked down console-like experience.

Just embrace the PC for what it is and stop trying to turn it into a trusted execution platform with spyware and rootkits.

Look at BF6 - for all the secure boot and TPM required anti-cheat they stuffed it with, there were cheaters day 1, so why abuse your users when it's clearly ineffective anyway.

Microsoft doesn't do any auditing besides "is this the most obvious malware?"

I oppose kernel-level anticheat because once it's in place, it will proliferate, even to single player games, just as it has in Windows.

In other words, once it's broadly supported, the number of games available to me (assuming I want to avoid kernel-level anticheat) will actually _shrink _.

Obviously, our personal priorities differ. That's fine, but yours don't invalidate my earlier point.

By the way, it's never just one determined cheater. Once discovered, circumvention techniques get shared, just as with mod chips and exploit scripts. It's only a matter of time before anyone willing to do a little reading or buy a little hardware can use them. And they do. (Often on alt accounts, with no fear of getting banned.)

In other words, any relief from game cheaters is bound to be temporary, while harm from spyware or exploit is irreparable to anyone who values the privacy of their data.

This is why kernel-level anti-cheat systems are so widely criticized. They might make sense on dedicated gaming machines, where the risks are low, but the situation is very different on general-purpose computers.

Even if the game itself doesn't grant me that freedom, my OS and drivers should not prevent me from attaching a debugger to the game without it noticing.

My computer, and the software on it, should obey me, and me alone. Never should they obey a developer's desire to restrict what I can and cannot do.

That is the ideological basis of the free software movement, and as you may have noticed, incompatible with client side anticheat.

We can run tasks on them that only produces valid output if the boot chains is verified.