Kernel level anticheat and Linux: how it works?

Ask Fedora
, ,
1

First of all I know that using Linux and then having a game with a Kernel Level anticheat is like controversial thing to do, but I am sending this question because I am really curious to know how an anticheat works, considering especially gaming on Steam.

On Windows is pretty simple, you install the game with the anticheat, then you authorize the anticheat to get Kernel level access, and that’s it, anticheat knows exactly what you are doing on your PC and who knows which entity/person knows it as well.

But, on Linux the story it might be slighly different. Yes, the process is the same, but which Kernel the anticheat gets access to is the thing that I am not really sure. On Linux, you install Steam, Steam then creates a Wine environment that looks like a Windows partition and then you install the game inside that, but what about the anticheat? It uses the Wine (Windows) Kernel or instead goes up outside Wine/Steam directly into the Linux Kernel? Does anyone tested/proved how an anticheat works under Linux?

2

That’s a very interesting topic you mention. In Linux, there are no kernel-level anti-cheats; not because they can’t exist, but because, due to the nature of Linux, it would be potentially “easy” to bypass any checks that could be made.

For Linux, common anti-cheats (such as Easy Anti Cheat or BattlEye) have native versions for Linux, but in user mode (i.e., binaries like any other binary you can run on your distribution, such as firefox or curl and shared objects (.so files)).

For Windows games on Linux, the situation is similar: Games you run on Proton use something called “runtimes”, which are basically a bridge between the “Windows” client (Proton) and the native Linux client.

It is very important to clarify that throughout the installation and execution process, the anti-cheat does NOT have kernel-level access and uses various user-mode techniques to try to detect cheaters. For this reason, anti-cheats are less effective on Linux, and many game developers choose not to enable Linux support, as it would be easier for a cheater to cheat on Linux.

In summary, anti-cheats on Linux have the same privileges as any other binary running under your user account. If you run anti-cheats as root, then anti-cheats will have root privileges.

1 Like
3

So, does it mean that, even tho you are installing the game and the anticheat through out Steam, that goes with Proton/Wine, the anticheat will ends up on the Linux kernel regardless? I put it in a very simplistic way, but is just to get an idea of this behaviour.

I am very well aware that most anticheat doesn’t work on linux (well, let’s say out of the box at least) but others it seems they do fine, but what kind of privileges they have and security concerns they might cause, it’s the thing I am trying to understand

4

Where in my response did you interpret that?

At no point did I that the anti-cheat will “end up in the kernel”, and I explicitly stated that it will NOT have access to the kernel.

Just to clarify again: Anti-cheats on Linux (at least EAC and BE) run at the user level and will have the same permissions as your user, but at no point will they “end up in the kernel”. They are NOT kernel modules and CANNOT be loaded into the Linux kernel!

5

Kernel code designed for the Windows kernel cannot be loaded into the linux kernel. It’s simply impossible.

The game would need native linux kernel code.

6

That’s why I was asking the question, to be sure I understood it correctly or not, it’s nothing against what you have said or the way you have said, no reason to escalate it :slightly_smiling_face:

On contrary, I really appreciate your time on explaining this, I am still new in Linux and I am trying to understand more about this OS, so I might ask stupid or useless questions, but is just because I want to learn more!

In conclusion, also by connecting to what @barryascott said, is that, if you will be successfully on installing a game with an anticheat under Steam proton/wine environment, the anticheat will only gets access to the proton/wine folder (so as User gives it authorization) but nothing will be touched on Linux kernel side. This also means the Anticheat cannot see what it is stored on the memory of the machine, but it will be able to only see what that proton/wine folder, right?

I want also be very specific that I am not asking this because I do want to cheat, or I want these game badly, but is only that, in case I might have a chance to play a game with an anticheat, I can be secure that the integrity and the privacy of my computer won’t be compromised by a 3rd party kernel level software. That’s all there is to it!

7

I’m sorry if you felt that way, but at no point did I “escalate” it. I simply asked you where you interpreted that, so that I could correct myself if at any point I implied that they were executed at the kernel level. But at no point did I disrespect you.

8

That is my understanding.

9

I’ll try to rephrase it to avoid any confusion that I’m being disrespectful: The anti-cheat (or the game itself that you run in Wine/Proton) will run with the same privileges as your current user, since your current user is running it. This is exactly the same as opening, for example, Firefox.

Wine/Proton does not provide a sandbox (nor is it intended to), so it does not isolate your Linux environment from that “fake Windows environment”. Any program you run in Wine can access any file or folder that your current (Linux) user has, for example your directory in /home.

1 Like
10

Which it also means that is able to see any process that is currently running on Linux (outside of Steam) correct?

But once you close Steam proton/wine envirnoment, the anticheat goes off, right? Because I have heard many reports that some anticheat doesn’t turn off when the game is closed (on windows) but it is still running as background process, the moment you turn on your machine until you turn it off.

Because, with what I am understanding is that, on Linux, even tho the anticheat is pretty invasive software, is still more secure to run it rather than on windows (if you are able to install a game with the anticheat, that’s clear). I think you can have more control and more secure environment rather than what you can get on Windows, correct me if I am wrong

11

In principle yes. But remember that you are talking about code designed for the Windows environment. Unless it’s explicitly coded to use the Windows API to access file sand processes output of Proton it will be aware of files and processes outside of Proton.

12

As I mentioned earlier, if your game does not support native Linux (and therefore you are running it with Wine/Proton), Steam provides a “bridge” to communicate between the “Windows” anti-cheat and the native Linux anti-cheat. In other words, the anti-cheat itself does not even run on Wine.

Anticheat runs like any other application in Linux. If an application (such as ps) can read /proc, then anticheat can too.

I will try to be as clear as possible: Regardless of whether your game runs on Wine or not, the anti-cheat runs natively on Linux and will have all the permissions that your current user has. If your current user can run ps, or even sudo without a password, the anti-cheat can too. This is NO different from, for example, installing any other closed-source program on Linux.

1 Like
13

The anticheat itself is a native linux shared object (example), so the “code” is designed to be executed on Linux.

1 Like
14

Here is a script I use to access the Proton environment to run regedit to fix games.
Save the following as steam-run-win-cmd.sh.

#!/bin/bash
STEAM_LIBRARY="${HOME}/.local/share/Steam/steamapps"
PROTON_BIN_PATH="${STEAM_LIBRARY}/common/Proton Hotfix/files/bin/wine64"

case "$1" in
--list)
    find ~/.local/share/Steam/steamapps -name '*appmanifest*' -exec grep '"name"' {} + \
        | grep -v -e '"Steam Linux ' -e '"Proton ' \
        | grep -i -e "${2:-.}" \
        | cut -d _ -f 2 | cut -d '"' -f1,4
    ;;

[0-9]*)
    STEAM_APPID=$1
    shift
    export WINEPREFIX="${STEAM_LIBRARY}/compatdata/${STEAM_APPID}/pfx"
    if [[ "$1" = "" ]]
    then
        "$PROTON_BIN_PATH" regedit
    else
        "$PROTON_BIN_PATH" "$@"
    fi
    ;;

*)
    echo "Usage: $0 --list|<appid> [cmd]"
    ;;
esac

You can list all your games with ./steam-run-win-cmd.sh --list.
Here is what I see (truncated).

$ steam-run-win-cmd.sh --list
1182310.acf:	"The Excavation of Hob's Barrow
921800.acf:	"Encased
107100.acf:	"Bastion
489830.acf:	"The Elder Scrolls V: Skyrim Special Edition

Now just pick on one to get its APPID for example for Bastion the APPID is 107100..
Now you can start a CMD shell like this:

$ steam-run-win-cmd.sh 238010 cmd
wineserver: using server-side synchronization.
Microsoft Windows 10.0.19043

Z:\home\barry>

You will see that a dir \ will show up the same files and folders as ls /.
In other words the Windows games could look at all the files your user has access to.

1 Like
15

In conclusion: both the game and the anti-cheat will be able to inspect your Linux system with the same level of access as your current user (for example, both will be able to inspect your $HOME or list the running processes).

If you want to further restrict how the game and the anti-cheat interact with your system, you can run the game inside Flatpak.

For example, if your game is available on Steam, you can use Steam’s Flatpak: https://flathub.org/apps/com.valvesoftware.Steam.

If your game is not on Steam, you can use a launcher such as Heroic: https://flathub.org/apps/com.heroicgameslauncher.hgl.

Keep in mind that anti-cheat systems can detect that you are in a sandbox (for example, within Flatpak) and prevent their own execution, which would make it impossible to play the game, as the anti-cheat system would not be running. I can’t really confirm whether this is the case with, for example, BattlEye or Easy Anti Cheat, although I seem to remember that EAC has no major issues with Flatpak.

However, keep in mind that Flatpak cannot protect you from certain things, such as X11 “security flaws”, so even within Flatpak, the anti-cheat could escape the sandbox if it really wants to. To prevent this, you should modify the permissions of those flatpaks to prevent them from using X11, and then remove access to any non-essential folders.

Please note that a sandbox is not considered inherently secure, and you should never execute potentially malicious code (or code you do not trust) within a sandbox.

In my personal opinion, I believe that by modifying the permissions of, for example, Steam’s Flatpak, the risk is “acceptable” since Flatpak significantly restricts the level of access (thanks to bubblewrap). But really, the only “viable” solution is to use a virtual machine if you are truly concerned that the anti-cheat could access your system.

I hope this information is useful to you, and again, I apologize if at any point you felt that I disrespected you or treated you incorrectly. I’m happy to see new people who want to join the world of Linux, like you!

Please do not hesitate to ask again if you have any further questions on this matter.

1 Like
16

Thank you so much for your deep and detailed explanation, and don’t worry, you weren’t disrespectful at all :slightly_smiling_face:

I will consider to follow your guidance in case I want to test some game with the anti-cheat. I did also consider running a VM, but since I have only one GPU, making a passthrough is not something achievable, thus running a game inside a VM is basically not an option for me.

Thanks a lot for your kindness and time!

17

Yes*

With wine, any active processes get terminated when the prefix is shutdown (wineserver -k), so anti-cheat running within that Wine prefix would be closed.

Hypothetically if NTSync was somehow usable as anti-cheat or a component of it, some distros have it as a loadable kernel module that does stick around regardless of the Wine prefix. You’d have to have another way to unload the module (udev or manual). Custom Wine builds and Proton might also differ.

1 Like
18

I did try to run the game “The First Descendant” by Steam inside a VirtualBox VM Windows 11 but EAC doesn’t allow Virtual Machines.

19

You cannot simply open games protected by anti-cheats in a VM. Anti-cheats (at least BatlEye and Easy Anti-Cheat) use various techniques to detect virtual machines (like rdtsc checks).

20

says who exactly. the linux kernel devs, the distribution makers, the OS itself through the kernel? (or the kernel through the OS?)

are the cheats beholden to the same limitations? user mode only?