zlacker

[return to "Valve reveals it’s the architect behind a push to bring Windows games to Arm"]
1. jchw+UO2[view] [source] 2025-12-03 17:27:25
>>evolve+(OP)
> and modern multiplayer games with anti-cheat simply do not work through a translation layer, something Valve hopes will change in the future.

Although this is true for most games it is worth noting that it isn't universally true. Usermode anti-cheat does sometimes work verbatim in Wine, and some anti-cheat software has Proton support, though not all developers elect to enable it.

◧◩
2. ZiiS+TR2[view] [source] 2025-12-03 17:41:08
>>jchw+UO2
It works in the sense it allows you to run the game; but it does not prevent cheating. Obviously, Window's kernel anti-cheet is also only partially effective anyway, but the point of open-source is to give you control which includes cheating if you want to. Linux's profiling is just too good; full well documented sources for all libraries and kernel, even the graphics are running through easier to understand translation layers rather than signed blobs.
◧◩◪
3. jchw+R13[view] [source] 2025-12-03 18:29:57
>>ZiiS+TR2
Anti-cheat is a misnomer; it's much more about detecting cheats more than it is preventing them. For people who are familiar with how modern anti-cheat systems work, actually cheating is really the easy part; trying to remain undetected is the challenge.

Because of that, usermode anti-cheat is definitely far from useless in Wine; it can still function insofar as it tries to monitor the process space of the game itself. It can't really do a ton to ensure the integrity of Wine directly, but usermode anti-cheat running on Windows can't do much to ensure the integrity of Windows directly either, without going the route of requiring attestation. In fact, for the latest anti-cheat software I've ever attempted to mess with, which to be fair was circa 2016, it is still possible to work around anti-cheat mechanisms by detouring the Windows API calls themselves, to the extent that you can. (If you be somewhat clever it can be pretty useful, and has the bonus of being much harder to detect obviously.)

The limitation is obviously that inside Wine you can't see most Linux resources directly using the same APIs, so you can't go and try to find cheat software directly. But let's be honest, that approach isn't really terribly relevant anymore since it is a horribly fragile and limited way to detect cheats.

For more invasive anti-cheat software, well. We'll see. But just because Windows is closed source hasn't stopped people from patching Windows itself or writing their own kernel drivers. If that really was a significant barrier, Secure Boot and TPM-based attestation wouldn't be on the radar for anti-cheat vendors. Valve however doesn't seem keen to support this approach at all on its hardware, and if that forces anti-cheat vendors to go another way it is probably all the better. I think the secure boot approach has a limited shelf life anyways.

◧◩◪◨
4. buildb+463[view] [source] 2025-12-03 18:49:52
>>jchw+R13
Speaking of Anti-Cheat and secure boot, you need SB for Battlefield 6. The game won't start without it. So it's happening!

I don't hate the lack of cheating compared to older Battlefield games if I am going to be honest.

◧◩◪◨⬒
5. koutei+883[view] [source] 2025-12-03 18:59:11
>>buildb+463
> Speaking of Anti-Cheat and secure boot, you need SB for Battlefield 6. The game won't start without it. So it's happening!

I'm curious, does anyone know how exactly they check for this? How was it actually made unspoofable?

◧◩◪◨⬒⬓
6. kbolin+zi3[view] [source] 2025-12-03 19:51:05
>>koutei+883
Disclaimer: This is only an educated guess based upon public info. Also, it's impossible to make something truly unspoofable, but it isn't that hard to raise the bar for spoofing pretty high.

There are two additional concepts built upon the TPM and Secure Boot that matter here, known as Trusted Boot [1,2] and Remote Attestation [2].

Importantly, every TPM has an Endorsement Key (EK) built into it, which is really an asymmetric keypair, and the private key cannot be extracted through any normal means. The EK is accompanied by a certificate, which is signed by the hardware manufacturer and identifies the TPM model. The major manufacturers publish their certificate authorities [3].

So you can get the TPM to digitally sign a difficult-to-forge, time-stamped statement using its EK. Providing this statement along with the TPM's EK certificate on demand attests to a remote party that the system currently has a valid TPM and that the boot process wasn't tampered with.

Common spoofing techniques get defeated in various ways:

- Stale attestations will fail a simple timestamp check

- Forged attestations will have invalid signatures

- A fake TPM will not have a valid EK certificate, or its EK certificate will be self-signed, or its EK certificate will not have a widely recognized issuer

- Trusted Boot will generally expose the presence of obvious defeat mechanisms like virtualization and unsigned drivers

- DMA attacks can be thwarted by an IOMMU, the existence/lack of which can be exposed through Trusted Boot data as well

- If someone manages to extract an EK but shares it online, it will be obvious when it gets reused by multiple users

- If someone finds a vulnerability in a TPM model and shares it online, the model can be blacklisted

Even so, I can still think of an avenue of attack, which is to proxy RA requests to a different, uncompromised system's TPM. The tricky parts are figuring out how to intercept these requests on the compromised system, how to obtain them from the uncompromised system without running any suspicious software, and knowing what other details to spoof that might be obtained through other means but which would contradict the TPM's statement.

[1]: https://learn.microsoft.com/en-us/windows/security/operating...

[2]: https://docs.system-transparency.org/st-1.3.0/docs/selected-...

[3]: https://en.wikipedia.org/wiki/Trusted_Platform_Module#Endors...

[go to top]