Summary of “Anti Cheat at Embark Studios” prensentation by Embark Studios Senior Software Engineer Tom van Dijck, at devcom in Germany on August 24.

… Linux presents an even worse situation. Because users can custom-build the OS kernel, embedding a cheat directly into the kernel and compiling it makes it nearly impossible for a game to detect its existence. “How do you detect that?” van Dijck asked, adding that while support for SteamOS and Proton will remain, platform requirements will become stricter.

Though he mentions anti-cheat on Linux being more challenging to implement that on Windows, he doesn’t seem to think that it’s impossible. He goes on to talk about “undetectable” cheating hardware becoming cheaper, which sounds like a bigger problem, but he sounds optimistic about being able to detect those as well.

IMO “platform requirements will become stricter” could mean something like only allowing signed kernels with anti-cheat module built in + secure boot.

  • dillekant@slrpnk.net
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 days ago

    No one has mentioned the thing they’re doing right here:

    This led to a shift in hiring strategy. “We had focused almost entirely on software engineering, but we had no one who actually understood this data,” he recalled. “We completely pivoted our hiring toward data scientists, and today we spend far more effort analyzing data than reverse-engineering programs.”

    A huge part of the argument from us Linux users has been: These companies say a bunch of stuff, but from the words it seems pretty clear that the maths is off. It would be nice if they actually shared some of the maths, but actually having someone who studied statistics on the payroll is at least some measure of trust.

    Having said that, the inflated sense of importance of these companies thinking they deserve root is pretty astonishing:

    Kernel-level anti-cheat operates at the innermost layer of the operating system, allowing it to inspect the entire PC. While this offers a broad detection scope, it presents significant privacy and security concerns for users. Introducing this topic as a “controversial slide,” van Dijck acknowledged, “It is invasive, and we agree.”

    However, he argued that it is an unavoidable necessity at present: “Cheat software is already doing the exact same thing, reaching the point where cheaters boot via USB drives to hijack the system before the kernel even loads.” He also noted that while Microsoft is enhancing platform security, those measures do not apply to older Windows versions used by many players.

    OK, but people who aren’t cheating aren’t doing that. They have banking information on their computers. The kernel code could be exfiltrating that in the normal telemetry (which makes servers a target), or be hacking your invasive kernel module (which is a honeypot). The fact that they’re not even considering that some other game’s anti-cheat could be used as a vector for cheats is, like I said, astonishing.

    The cherry on top is the admission that this highly risky kernel module is vibe coded.

    He also noted that AI coding assistants influenced their approach. “Thanks to tools like Claude and Codex, solutions that used to take years can now be built in a short time,” van Dijck explained. “The barrier to building custom solutions in-house has dropped significantly.”

    Just use the data scientists bro.