Yes for DRM
Yes for DRM
Posted Aug 9, 2025 6:14 UTC (Sat) by NYKevin (subscriber, #129325)In reply to: Yes for DRM by SLi
Parent article: Don't fear the TPM
The problem with this idea is that most of these games are already using their own kernel drivers to snoop on players and (supposedly) prevent cheating. I'm not sure if Microsoft is willing to sign those drivers - there is a lot of potential for abuse if somebody manages to extract the driver and convince it to behave slightly differently than intended.
Posted Aug 9, 2025 16:07 UTC (Sat)
by excors (subscriber, #95769)
[Link] (17 responses)
They are: "The driver has been signed by Riot’s own EV cert, which has in turn been signed by Microsoft as per their code signing process." (https://www.riotgames.com/en/news/a-message-about-vanguar...)
> there is a lot of potential for abuse if somebody manages to extract the driver and convince it to behave slightly differently than intended
Doesn't the same potential exist for all drivers? I'd have more trust in the security of an anti-cheat driver whose primary goal is to resist hostile adversaries, than a random driver for e.g. my keyboard LEDs where the developers probably had no interest in security and never expected to be attacked.
Posted Aug 9, 2025 16:30 UTC (Sat)
by mb (subscriber, #50428)
[Link] (15 responses)
Sure. That's why such code in the trust chain must be minimized instead of adding code to try to prevent kiddies from cheating.
This chain of trust doesn't work in practice, because there probably are tens of millions of lines of code that must be trusted between the root of the trust in UEFI and the trusting application in userspace.
>I'd have more trust in the security of an anti-cheat driver whose primary goal is to resist hostile adversaries, than a random driver for e.g. my keyboard LEDs where the developers probably had no interest in security and never expected to be attacked.
Yeah, well. The keyboard driver is present regardless of whether there is an anti-cheat driver or not.
Posted Aug 9, 2025 17:05 UTC (Sat)
by SLi (subscriber, #53131)
[Link] (14 responses)
This is different from if there's a fundamentally unpluggable hole that you can exploit by e.g. running a specific EFI binary before booting. In the first case, detecting and fixing this is possible. In the second case, you can exploit weaknesses in the exploit to try to detect it, but those should generally be patchable and (near-)perfection is attainable.
Blacklisting drivers known to be used for cheating is _much_ easier than whitelisting everything that should be allowed.
Posted Aug 10, 2025 2:22 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (13 responses)
This is doubly easier because the rootkit doesn't have to hide from the computer's owner.
And this is not a theory, the current generation of most advanced cheats (e.g. https://blurred.gg/guides/info ) works like this, along with DMA-based RAM snooping. As I understand, the custom rootkit keeps the IOMMU disabled for the DMA engine to work.
Posted Aug 10, 2025 14:02 UTC (Sun)
by SLi (subscriber, #53131)
[Link] (12 responses)
Posted Aug 10, 2025 19:57 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
Windows will happily re-measure the boot chain with the rootkit. The values of TPM registers will be different so you will lose access to any previously sealed secrets, but there's no way for the anti-cheat driver to pre-compute the "correct" values.
It's possible in theory to build a robust DRM system with the TPM, but it requires coordination and periodic updates for all the PC manufacturers.
Posted Aug 10, 2025 20:02 UTC (Sun)
by SLi (subscriber, #53131)
[Link] (10 responses)
Posted Aug 11, 2025 9:40 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (9 responses)
The protection against rogue drivers is via driver signing; if the driver is signed, it's trusted. Once it's loaded, it can rearrange memory so that everything looks plausible for the situation where the driver was never loaded, including resetting logs and changing flags to hide itself.
Posted Aug 11, 2025 14:58 UTC (Mon)
by SLi (subscriber, #53131)
[Link] (8 responses)
1. Client: Please give me access to the game server!
Now of course if nothing else prevents it (i.e. there's no mechanism to, for example, for the game to get a notification if a driver is about to be loaded), the game server can just ask you to periodically reattest that you are still in that state or to provide the logs up to the state where you are.
Now what is logged in those measured logs is of course up to the operating system, but it definitely should contain a hash of the driver and most likely other information about its provenance (if it's signed, who has signed it, size, filename, other metadata, hash). The game server could even theoretically require you to send the unknown driver for analysis (they know its hash).
Posted Aug 11, 2025 15:16 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (7 responses)
The result is that you've correctly proven that the clean system exists and is in the control of the user trying to cheat. But that's not what you wanted to know - you wanted to know that the system you are running on is the clean system, and not the dirty system.
Posted Aug 11, 2025 15:38 UTC (Mon)
by SLi (subscriber, #53131)
[Link] (6 responses)
I think that at least if the game loads a kernel driver, this should be doable, assuming really a "clean system", and I admit that with the current technology that's not really easy if you need to support tons of hardware—but that's where blacklisting bad drivers could come into play. And certainly some kernel APIs could be designed for doing something like this from the user space; at the simplest, something like "execute this binary, protecting its memory from everyone else, and attest to it". The kernel would then have a function `attest(nonce)` that gives the process a signed attest that:
1. This is an .exe with hash $hash
(1) and (2) are guaranteed only by the OS being in a known good state, which is the weakest link. (3) is guaranteed by the TPM.
... but I admit that at this point, speculating about what Windows does or could do, I am a bit out of my depth. I know TPM well enough as a concept to believe that this is something it should enable. I should probably go read about how it's really used by Windows; I only know the period until the bootloader starts pretty well, and I have some idea about how systemd uses it on Linux.
Posted Aug 11, 2025 16:02 UTC (Mon)
by SLi (subscriber, #53131)
[Link]
- Windows really stops the measurement chain mostly early, i.e. what ends up in the PCRs is firmware and bootloader measurements and some info about the OS loader and early kernel init.
So, I would claim that locking down the system at a level where a game vendor can reliably blacklist drivers is doable using a TPM, but it would require a future version of Windows to start measuring all driver loads.
Posted Aug 11, 2025 16:13 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (4 responses)
Underlying this is that as soon as the "bad" driver is loaded, the OS is in a known-bad state, and anything running on that OS can't trust it. Remote attestation, as offered by the TPM, allows you to confirm that the user has access to a clean system, but not that the processes involved in attestation are actually running on that clean system. This is irrespective of the OS; once you have an untrusted system that has full userspace access to a clean system, you can get the attestations from the clean system, and send them back in place of the attestations that you can get from your "dirty" system.
The fix is to not support general systems; either the "dirty" system's kernel space must be locked down so that you cannot run "unwanted" but signed drivers (games console model), or the "clean" system's user and kernel space must be locked down so that the "dirty" system can't run arbitrary userspace on it to get attestation answers from the clean system.
Posted Aug 13, 2025 0:53 UTC (Wed)
by SLi (subscriber, #53131)
[Link] (3 responses)
Yes, this is true. But I think there's another fix besides what you suggest. The remote is now able to encrypt secrets so that only the clean system can access them. Because it's a clean system, it presumably won't leak them to the unclean system. This can be used for DRM (and is the common way to do DRM, I would claim). Typically you give the clean system a key to access encrypted secrets.
Posted Aug 13, 2025 1:17 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link]
Posted Aug 13, 2025 9:38 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (1 responses)
More generally, given that I can buy TPMs off the shelf (e.g. this TPM 2.0 evaluation board), what stops me from having a custom device that gets sent the same sequence of TPM 2.0 commands as a "real" TPM on a motherboard (hence has the "correct" hash values - all I need is a motherboard with an external TPM, such as the ASUS ROG STRIX TRX40-XE GAMING, where I can intercept the SPI bus to a discrete TPM and see what happens), but isn't actually reflecting the state of the "dirty" system?
Or, for even more sophistication, my hardware device sits between the discrete TPM on my gaming motherboard and the mobo connector, and simply filters out TPM commands that would show that my cheat driver is present - relying on my cheat driver modifying kernel data structures like the log to agree with the TPM.
Posted Aug 13, 2025 13:13 UTC (Wed)
by pizza (subscriber, #46)
[Link]
There's a lot of precedent here; most so-called console "modchips" work this way.
Posted Aug 28, 2025 15:21 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link]
It’s not designed to resist hostile adversaries in a general sense, it’s designed to resist abuse within the game. The anti cheat devs would not care less about all the other ways their driver could be abused.
Yes for DRM
Yes for DRM
IMO this technique is fundamentally flawed.
Adding an anti-cheat driver can only weaken the system as a whole, if it contains a bug.
Yes for DRM
Yes for DRM
Yes for DRM
Yes for DRM
Yes for DRM
The problem is that such a log could be truncated by the rogue driver - you remove the last entry when you load (which you can do, since you're in kernel space - albeit you may need a helper app to tell you what the log "should" look like without you), and now it's impossible to distinguish this attested log from one on a system without the rogue driver.
Yes for DRM
Yes for DRM
2. Remote: Ok, let's see. Tell me who you are and show me your TPM logs. Here's a challenge nonce.
3. Client: I'm a TPM by FooCorp. Here's the certificate from FooCorp for my public key. And here's your challenge nonce to prove that this is not a replay. Here's the TPM logs. I have attached a signed attestation with your nonce from the TPM that my PCRs correspond to what the log says.
4. Remote: Excellent, looks clean. You are welcome.
If the cheat system really wants to push the limits, you have two systems; one is clean, and can answer all the TPM queries you want answered. The second runs the dirty driver, which redirects your TPM log request across to the clean system, gets you a verified answer (which passes, since the cheat code is in userspace on the second system) and returns it as-if it came from the dirty system.
Yes for DRM
Yes for DRM
2. I started it so that its memory is not accessible from outside
3. The TPM state is $state (signed by the TPM, nonced by the nonce)
Yes for DRM (but possibly not on Windows, at least in the current state)
- Crucially, I think it *doesn't* routinely post-boot driver loads, which obviously breaks the chain if you can load your own driver (so you can only reliably attest to what happened in early boot).
- Device Health Attestation (DHA) apparently can attest to: 1) if Secure Boot is on or off; 2) BitLocker status; 3) Code integrity policy (whether kernel-mode driver signing is enforced); but it does not give you a hash of every loaded driver.
- Anti-cheat vendors rely more on the driver signing enforcement and their own kernel driver scanning, not PCR measurements (and that obviously can be subverted by drivers loaded before the anti-cheat driver, even if not easy), plus hardware identity (from TPM) for bans.
The core problem is that, having loaded a "bad" driver, the bad driver can lie through its teeth to the game client. Once the bad driver is loaded, it is, for all reasonable purposes, part of the kernel, and can (for example) redirect the "execute this binary, protecting its memory from everyone else, and attest to it" API to let it launch the binary on the clean system, and attest to the signed attest from the clean system.
Yes for DRM
Yes for DRM
Yes for DRM
The userspace on the clean system is under attacker control; kernelspace (and thus userspace) on the dirty system is under attacker control. How do you propose to allow the userspace code on the dirty system to ask for a secret in such a way that the kernelspace on the dirty system can't proxy the request to a userspace process under its control on the clean system, and proxy the result back?
Yes for DRM
Yes for DRM
Yes for DRM