Way I see it, there’s two ways to address the “cheating” issue in multiplayer online games.
First, let’s establish that game cheats typically involve using another application to modify the game’s running code while it is loaded in memory.
Historically, anti-cheat has largely taken a “reactive” approach. Try to detect the hook / modification taking place, ban the player if it is detected.
These systems and bans were often circumvented. There are entire games that I stopped playing because the experience was ruined for me - GTA Online and the late stages of Titanfall 2 are standouts in my mind.
With how the Windows device security landscape has changed In the 2020s (MacOS has had something similar for ages), there’s now the option of taking a “proactive” approach by preventing application memory from being tapped in the first place.
These technologies, notably Secure Boot and TPM, help mitigate rootkits and malware that might steal sensitive information from application memory, as well as paving the way for other protection measures like disk encryption.
And that’s the main part they’re interested in - by ensuring the entire process up through the kernel cannot be tampered with, the anti-cheat is going to be highly effective at pre-empting anyone from attempting the cheat to begin with.
It really sucks that, in the curent landscape, that means there are a handful of games that I can’t play on my Linux devices. But it also makes sense - Proton runs with many layers beneath it, which would make it trivial to tamper with memory and engage in cheating.
I’m hopeful that we’ll someday see a solution that opens up the opportunity for the same degree of integrity protection in Linux so that anyone can enjoy any game on the operating system of their choosing.
Regardless of what others have to say about EA or the franchise (and boy do they have their issues), Battlefield has always been a beloved series for me.
I’m having a blast in Battlefield 6 and I have yet to encounter any cheaters. Previous entries in the series would see me hopping to a new server whenever I encountered one or, on some occasions, ending my play session out of frustration. Anecdotally, the cheating felt much more prevalent before.
I have a lot less time to game than I used to, so that time is sacred to me. While I’d obviously prefer another way, maintaining a Windows system and enabling two BIOS settings (well, leaving them enabled - they’re on by default) has been worth it for me.
That’s a false dichotomy though. There are ways to prevent cheating that don’t rely on the security of the client against the owner of the device on which the client runs (which is what both of what your ‘ways’ are).
For one thing, it has long been a principle of good security to validate things on the server in a client-server application (which most multi-player games are). If they followed the principle of not sending data to a client that the user is not allowed to see, and not trusting the client (for example, by doing server-side validation, even after the fact, for things which are not allowed according to the rules of the game), they could make it so it is impossible to cheat by modifying the client, even if the client was F/L/OSS.
If they really can’t do that (because their game design relies on low latency revelation of information, and their content distribution strategy doesn’t cut it), they can also use statistical server-side cheat detection. For example, suppose that a player shoots within less than the realistic human reaction time of turning the corner when an enemy is present X out of Y times, but only A out of B times when no enemy is present. It is possible to calculate a p-value for X/Y - A/B (i.e. the probability of such an extreme difference given the player is not cheating). After correcting for multiple comparisons (due to multiple tests over time), it is possible to block cheaters without an unacceptable chance of false positives.
Effectively doing that server-side would substantially increase the bandwidth requirements though.
If we take wallhacks as an example, that takes place entirely in the local rendering pipeline. In a game like Battlefield or Counter Strike, smoke and foliage are used for tactical purposes.
Aimbots read player location data sent from the server and send input commands to the OS to automate headshots.
Preventing local memory from being read and modified outright prevents (well, substantially raises the skill ceiling) for performing these kinds of hacks.
I have a hard time envisioning a server-side solution to those.
security of the client against the owner of the device on which the client runs
Way I see it, there’s two ways to address the “cheating” issue in multiplayer online games.
First, let’s establish that game cheats typically involve using another application to modify the game’s running code while it is loaded in memory.
Historically, anti-cheat has largely taken a “reactive” approach. Try to detect the hook / modification taking place, ban the player if it is detected. These systems and bans were often circumvented. There are entire games that I stopped playing because the experience was ruined for me - GTA Online and the late stages of Titanfall 2 are standouts in my mind.
With how the Windows device security landscape has changed In the 2020s (MacOS has had something similar for ages), there’s now the option of taking a “proactive” approach by preventing application memory from being tapped in the first place. These technologies, notably Secure Boot and TPM, help mitigate rootkits and malware that might steal sensitive information from application memory, as well as paving the way for other protection measures like disk encryption.
And that’s the main part they’re interested in - by ensuring the entire process up through the kernel cannot be tampered with, the anti-cheat is going to be highly effective at pre-empting anyone from attempting the cheat to begin with.
It really sucks that, in the curent landscape, that means there are a handful of games that I can’t play on my Linux devices. But it also makes sense - Proton runs with many layers beneath it, which would make it trivial to tamper with memory and engage in cheating.
I’m hopeful that we’ll someday see a solution that opens up the opportunity for the same degree of integrity protection in Linux so that anyone can enjoy any game on the operating system of their choosing.
Regardless of what others have to say about EA or the franchise (and boy do they have their issues), Battlefield has always been a beloved series for me. I’m having a blast in Battlefield 6 and I have yet to encounter any cheaters. Previous entries in the series would see me hopping to a new server whenever I encountered one or, on some occasions, ending my play session out of frustration. Anecdotally, the cheating felt much more prevalent before.
I have a lot less time to game than I used to, so that time is sacred to me. While I’d obviously prefer another way, maintaining a Windows system and enabling two BIOS settings (well, leaving them enabled - they’re on by default) has been worth it for me.
That’s a false dichotomy though. There are ways to prevent cheating that don’t rely on the security of the client against the owner of the device on which the client runs (which is what both of what your ‘ways’ are).
For one thing, it has long been a principle of good security to validate things on the server in a client-server application (which most multi-player games are). If they followed the principle of not sending data to a client that the user is not allowed to see, and not trusting the client (for example, by doing server-side validation, even after the fact, for things which are not allowed according to the rules of the game), they could make it so it is impossible to cheat by modifying the client, even if the client was F/L/OSS.
If they really can’t do that (because their game design relies on low latency revelation of information, and their content distribution strategy doesn’t cut it), they can also use statistical server-side cheat detection. For example, suppose that a player shoots within less than the realistic human reaction time of turning the corner when an enemy is present X out of Y times, but only A out of B times when no enemy is present. It is possible to calculate a p-value for
X/Y - A/B(i.e. the probability of such an extreme difference given the player is not cheating). After correcting for multiple comparisons (due to multiple tests over time), it is possible to block cheaters without an unacceptable chance of false positives.Effectively doing that server-side would substantially increase the bandwidth requirements though.
If we take wallhacks as an example, that takes place entirely in the local rendering pipeline. In a game like Battlefield or Counter Strike, smoke and foliage are used for tactical purposes.
Aimbots read player location data sent from the server and send input commands to the OS to automate headshots.
Preventing local memory from being read and modified outright prevents (well, substantially raises the skill ceiling) for performing these kinds of hacks. I have a hard time envisioning a server-side solution to those.
That’s exactly who a cheater is though
If the server runs a significantly cut-down rendering model, you can do things like culling player models when you can’t see them. No more wallhacks.