Games using anti-cheats and their compatibility with GNU/Linux or Wine/Proton

📝 Discussion Summary (Click to expand)

The three most prevalent themes in this Hacker News discussion revolve around the technical challenges and philosophical implications of anti-cheat software on Linux, the inherent difficulty of achieving perfect cheat prevention, and the viability of server-authoritative versus client-side solutions.

1. Kernel-Level Anti-Cheat (AC) as an Erosion of Linux Security Principles

A major point of contention is the security trade-off required by strict anti-cheat systems, which often demand kernel-level access, fundamentally conflicting with the control and transparency generally expected on Linux. Users expressed strong resistance to this level of system control being mandated by game developers.

Quote: "I had a realization, it's a cold day in hell when someone else is going to tell me what I can run on my computer. All the latest multiplayer games are now requiring secure boot on Win11 as well... I'm actually wary of all these anti-cheats, they're literally hyperinvasive maleware." - "999900000999"
Quote: "I prefer my Linux without rootkits." - "phoronixrly"
Quote: "Linux is resistant to rootkits, which is what these things are, and allows you to remove them, yes. The correct solution is to verify everything server side, or actually have humans watch replays and ban cheaters, but both of those would reduce profits, so will obviously never happen." - "RobotToaster"

2. The Near Impossibility of Unbypassable Anti-Cheat

Many participants agreed that no anti-cheat solution on any platform can be made perfectly unbypassable, suggesting that the goal should be making cheating inconvenient or costly, rather than achieving 100% enforcement through technology alone. Hardware-level and external vision-based cheats were frequently cited as methods that bypass software scrutiny.

Quote: "There is no way to make anticheat that can't be bypassed, regardless of OS. All of the anticheat games today have cheaters." - "63stack"
Quote: "Correct. E.g. you can aimbot by routing the video signal to a capture card on a separate computer and run image recognition software to generate mouse movements spoofed at the hardware level. The only way to reliably prevent cheating is with in-person tournaments played on hardware provided by the organizers." - "mrob"
Quote: "The idea that any (currently realistic) cheat prevention is unbypassable is silly." - "tete"

3. Debate Over Server-Side Authority vs. Client-Side Information Needs

The discussion heavily featured the architecture debate: whether the server should be authoritative and drastically limit client knowledge (to prevent cheats like wallhacks), or if modern fast-paced games inherently require the client to possess data that can be exploited.

Quote: "The best way is to just make private servers, so people can play with their friends and not have to worry about random players... Doing everything server side does prevent cheating." - "soloridindan" (though this claim was immediately challenged)
Quote: "Server side only protects against some types of cheats, such as telling the server that your bullet in an FPS is actually a grenade. It cannot prevent snapping your aim to a target on screen." - "bangaladore"
Quote: "You can’t prevent wall hacks with only server side anti cheat. The client needs that data locally before the enemy is rendered on screen." - "360MustangScope"

🚀 Project Ideas

Hypervisor-Based Game Integrity Monitor (GIM) for Linux

Summary

A mandatory, lightweight hypervisor layer integrated into gaming distros (or system builders like Steam Deck) designed to enforce memory separation for game processes, mitigating kernel-level cheats on Linux.
Core value proposition: Provide a secure execution environment specifically for games, protecting game memory from the host kernel, drivers, and other user-space processes, thereby making traditional Linux kernel module cheats (kmods) ineffective without requiring developers to compromise user freedom via vendor-controlled Secure Boot or Remote Attestation.

Details

Key	Value
Target Audience	Linux Gamers, Gaming Distro Maintainers (e.g., Pop!_OS, Nobara), Game Developers targeting Linux.
Core Feature	Hypervisor intercepts memory access (IOMMU/Nested Paging) to ensure only the running game thread can access its isolated, encrypted memory pages. TPM attestation proves the hypervisor's presence to the game client.
Tech Stack	KVM/QEMU (modified or specialized fork), Libvirt/API for configuration, TPM2 integration, Systemd services for automatic startup/teardown compatible with user sessions.
Difficulty	High
Monetization	Hobby

Notes

Why HN commenters would love it: Directly addresses the core technical challenge raised by kachapopopow ("making a cheat for a proton supported game that no anticheat has any hopes of detecting are in 100 lines of a kmod driver") and the concept proposed by HALtheWise. It attempts to enforce integrity under the kernel, preserving the user's right to run an arbitrary kernel while protecting the game's memory space.
Potential for discussion or practical utility: This shifts the conversation from "we must control the user's Secure Boot keys" (Ziggy, Zak) to a localized, on-demand security envelope for the application, which aligns with the desire for user control (RobotToaster, zeta0134) while addressing cheats that rely on kernel access.

Server-Side Game State Validation Heuristics Service (GSVHS)

Summary

A centralized, scalable microservice layer that ingests raw, unfiltered client input data (inputs, movement vectors, timing events) and applies advanced statistical anomaly detection models to flag impossible or superhuman performance patterns in near real-time.
Core value proposition: Reduce reliance on invasive client-side anti-cheat drivers by creating a dynamic, server-authoritative baseline for "human performance" across various game genres, enabling effective, batched bans without rootkits.

Details

Key	Value
Target Audience	Game Studios (especially those porting competitive titles), Server operators for community servers.
Core Feature	Statistical modeling (ML/AI) to detect deviation from human reaction times, input precision, and consistency (e.g., perfect turn rates, impossible click timing, impossible physics interactions). It models "humanized" cheat profiles.
Tech Stack	Python/TensorFlow/PyTorch for modeling, Kafka/Redis Streams for high-throughput data ingestion, Golang/Rust for high-speed validation logic, Database (e.g., ClickHouse) for long-term analysis of flagged behavior.
Difficulty	Medium
Monetization	Hobby

Notes

Why HN commenters would love it: This system is server-authoritative (RobotToaster, thaxll) and based on heuristic detection that cannot be easily reverse-engineered by cheaters, as the models are server-side and constantly evolving. It addresses the debate that server-side validation is insufficient for reaction-based cheats (jsheard, vkou), by proving it can be done statistically after the fact.
Potential for discussion or practical utility: It provides a middle ground between pure server authority (which struggles with input latency) and invasive client-side checks. It directly tackles the "humanization" of cheats: "Aimbots will just add delay and variance then" (Hikikomori)—the service is designed to catch that variance statistically.

Flexible Gaming Environment Manager (FGEM)

Summary

A command-line/GUI tool focused on streamlining the setup, configuration, and session management of trusted, isolated runtime environments (like VMs or securely configured containers) specifically for games requiring high-security anti-cheat, offering an opt-in "Gaming Mode."
Core value proposition: Allow privacy-conscious users to dedicate a known, isolated OS/environment for high-risk gaming, protecting their main system from kernel anti-cheat spyware, while still leveraging the security benefits of Linux for general use. Aligns with users who use dual-booting but want a more agile solution (Cu3PO42, progbits).

Details

Key	Value
Target Audience	Linux users hesitant to run kernel anti-cheat on their primary system, Users already leveraging VMs for security boundaries.
Core Feature	Automated provisioning and configuration (e.g., using QEMU/KVM with specific hardware passthrough settings) for a minimalist Guest OS. It handles passing necessary secure boot/TPM attestations (if required by the game) from the isolated environment back to the host/game launcher in a controlled manner.
Tech Stack	Bash/Python scripting interface, Libvirt/KVM for VM management, SELinux/AppArmor profiles for sandboxing the VM process on the host.
Difficulty	Medium
Monetization	Hobby

Notes

Why HN commenters would love it: It directly facilitates the "run the game in a VM sandbox" approach mentioned by CuriouslyC and donatj, solving the practical setup hurdles. It acknowledges the trade-off: if you must accept invasive checks, do it in a disposable, dedicated environment that cannot compromise your primary desktop/workstation.
Potential for discussion or practical utility: This project would spark discussion on the configuration best practices for secure VM gaming (e.g., defeating GPU passthrough detection or handling required hardware identifiers securely). It offers an immediate, practical tool for users who want to protect their personal data while still playing proprietary titles.