new | show | ask | jobs Github

hparadiz 4 hours ago

The Linux kernel has eBPF now so if they wanted to start spying on everything you do they can just do it.

▲

hackyhacky 4 hours ago | parent | next [-]

> The Linux kernel has eBPF now so if they wanted to start spying on everything you do they can just do it.

Sure, except that anyone can just compile a Linux kernel that doesn't allow that.

Anti-cheat systems on Windows work because Windows is hard(er) to tamper with.

▲

hparadiz 3 hours ago | parent | next [-]

Well yeah but then eBPF would not work and then the anti cheat could just show that it's not working and lock you out.

This isn't complicated.

Even the Crowdstrike falcon agent has switched to bpf because it lowers the risk that a kernel driver will brick downstream like what happened with windows that one time. I recently configured a corporate single sign on to simply not work if the bpf component was disabled.

▲

swinglock 3 hours ago | parent [-]

Well but then attackers just compile a kernel with a rootkit that hides the hack and itself from the APIs of the BPF program, so it has to deal with that too or it's trivially bypassed.

Anticheat and antivirus are two similar but different games. It's very complicated.

	▲	hparadiz 2 hours ago \| parent [-]
		The bpf api isn't the only telemetry source for an anti cheat module. There's a lot of other things you can look at. A bpf api showing blanks for known pid descendent trees would be a big red flag. You're right that it's very complicated but the toolchain is there if someone wanted to do the hard work of making an attempt. It's really telemetry forensics and what can you do if the cheat is external to the system.

▲

tapoxi 3 hours ago | parent | prev | next [-]

The interesting solution here is secure boot, only allow users to play from a set of trusted kernels.

▲

__MatrixMan__ an hour ago | parent | next [-]

I'd be less antianticheat if I could just select the handcuffs at boot time for the rare occasion where I need them.

Although even then I'd still have qualms about paying for the creation of something that might pave the path for hardware vendors to work with authoritarian governments to restrict users to approved kernel builds. The potential harms are just not in the same league as whatever problems it might solve for gamers.

	▲	digiown 28 minutes ago \| parent [-]
		Once a slave, always a slave. Running an explicitly anti-user proprietary kernel module that does god-knows-what is not something I'd ever be willing to do, games be damned. It might just inject exploits into all of your binaries and you'd be none the wiser. Since it wouldn't work on VMs you'd have to use a dedicated physical machine for it. Seems to high of a price to play just a few games.

▲

monerozcash 3 hours ago | parent | prev | next [-]

Yep, a plenty of prior art on how to implement the necessary attestations. Valve could totally ship their boxes with support for anticheat kernel-attestation.

Is it possible to do this in a relatively hardware-agnostic, but reliable manner? Probably not.

▲

vbezhenar an hour ago | parent | prev | next [-]

What do you mean? Ship computer with preinstalled Linux that you can't tamper? Sounds like Android. For ordinary computers, secure boot is fully configurable, so it won't work: I can disable it, I can install my own keys, etc. Any for any userspace way to check it I'll fool you, if I own the kernel.

▲

tapoxi 34 minutes ago | parent [-]

No, just have the anti-cheat trust kernels signed by the major Linux vendors and use secure boot with remote attestation. Remote attestation can't be fooled from kernel space, that's the entire point of the technology.

That way you could use an official kernel from Fedora, Ubuntu, Debian, Arch etc. A custom one wouldn't be supported but that's significantly better than blocking things universally.

▲

digiown 30 minutes ago | parent [-]

You can't implement remote attestation without a full chain of exploits (from the perspective of the user). Remote attestation works on Android because there is dedicated hardware to directly establish communication with Google's servers that runs independent (as a backchannel). There is no such hardware in PCs. Software based attestation is easily fooled on previous Android/Linux.

▲

tapoxi 20 minutes ago | parent [-]

The call asks the TPM to display the signed boot chain, you can't fake that because it wouldnt be cryptographically valid. The TPM is that independent hardware.

	▲	digiown 13 minutes ago \| parent [-]
		How would that be implemented? I'd be curious to know. I'm not aware that a TPM is capable of hiding a key without the OS being able to access/unseal it at some point. It can display a signed boot chain but what would it be signed with? If it's not signed with a key out of the reach of the system, you can always implement a fake driver pretty easily to spoof it.

▲

fooker 3 hours ago | parent | prev | next [-]

You can switch out the kernel in the running Linux desktop.

▲

znpy 2 hours ago | parent | prev [-]

I wonder if you could use check-point and restore in userspace (https://criu.org/Main_Page) so that after the game boots and passes the checks on a valid system you can move it to an "invalid" system (where you have all the mods and all the tools to tamper with it).

I don't really care about games, but i do care about messing up people and companies that do such heinous crimes against humanity (kernel-level anti-cheat).

	▲	tapoxi 31 minutes ago \| parent [-]
		The war is lost. The most popular game that refuses to use kernel-level anti-cheat is Valve's Counter-Strike 2, so the community implemented it themselves (FaceIT) and requires it for the competitive scene.

▲

ffsm8 3 hours ago | parent | prev [-]

Uh, you'd have to compile a Kernel that doesn't allow it while claiming it does ... And behaves as if it does - otherwise you'd just fail the check, no?

I feel like this is way overstated, it's not that easy to do, and could conceptually be done on windows too via hardware simulation/virtual machines. Both would require significant investments in development to pull of

	▲	zamalek 3 hours ago \| parent \| next [-]
		Right, the very thing that works against AC on Linux also works for it. There are multiple layers (don't forget Wine/Proton) to inject a cheat, but those same layers could also be exploited to detect cheats (especially adding fingerprints over time and issuing massive ban-waves). And then you have BasicallyHomeless on YouTube who is stimulating nerves and using actuators to "cheat." With the likes of the RP2040, even something like an aim-correcting mouse becomes completely cheap and trivial. There is a sweet-spot for AC and I feel like kernel-level might be a bit too far.
	▲	hparadiz 3 hours ago \| parent \| prev [-]
		All it takes is going to cd usr src linux and running make menuconfig. Turning off a few build flags. Hitting save. And then running make to recompile. But that's like saying "well if I remove a fat32 support I can't use fat32". Yea it will lock you out showing you have it disabled. No big deal.

▲

the_hoser 3 hours ago | parent | prev [-]

That would require that they actually make the effort to develop Linux support. The current "it just works" reality is that the games developers don't need to support running on Linux.