Live data from Hacker News

/dev/null: Anti-Cheat Kernel Driver (2020)

leagueoflegends.com

81–90 of 142 posts

Re: /dev/null: Anti-Cheat Kernel Driver (2020)

#81
post #79
post #61

Earlier quoted context omitted.

> The hardware isn't banned, the player is banned if the anticheat detects the hardware being used. how? it can report itself as any pci device

The cheat software can report itself as any software, so that is the secret sauce. Can't say I'm privy to how exactly that is. The difference between "reports itself as X" and "reports itself as Y" are the same problem space.

the software actually has to interface with the operating system, which is how it's detected

the PCI card doesn't

it can be a regular perfectly functioning NIC with a different ROM chip

Re: /dev/null: Anti-Cheat Kernel Driver (2020)

#82
post #42

Earlier quoted context omitted.

The hardware isn't banned, the player is banned if the anticheat detects the hardware being used. The hardware might be reprogrammable and self modifying at some point in the future, but until it is and it's widely available a root level anticheat is adequate protection.

The player is not banned. The player's account is banned. It is a free game- they can make as many accounts as they like. The hardware will become widely available once kernel-level anticheat becomes widely used. >if the anticheat detects the hardware being used. The only thing the anticheat will be able to detect is ordinary hardware. My cheating device will capture input from HDMI or PCI, the software sees it as a…

> The player is not banned. The player's account is banned. It is a free game- they can make as many accounts as they like.

You're right and my wording was sloppy. Often account bans come with "hardware" bans which are an attempt at stopping this from happening but like any other form of anticheat they're not 100% effective (and nor do they need to be to be worth having).

> The hardware will become widely available once kernel-level anticheat becomes widely used.

Sure, and then the barrier for entry has been raised to buying the correct hardware, having it and keeping it up to date.

> The only thing the anticheat will be able to detect is ordinary hardware.

That's a very bold claim. There's no reason to assume that the hardware will match exactly - I expect that as the cheaters pick devices to spoof the cheat detectors will look for (and find) discrepancies.

Re: /dev/null: Anti-Cheat Kernel Driver (2020)

#83
post #41

Earlier quoted context omitted.

In both of those cases someone has already hacked your machine and can run arbitrary binaries. They’ve already stolen all of your credentials from browser databases, all of your secret files from your homedir and so on. Besides, Windows LPEs are a dime a dozen anyway.

And if I do banking from one user account and gaming from a different (limited) user account?

Accounts are not a good separation of context already, let alone privilege escalation exploits.

If you’re concerned about one use affecting the other you’re much better off dual-booting two Windows installations, both using BitLocker. They’d use separate keys and AES-XTS means there’s tamper protection as well. One partition could, at worst, destroy the other.

Re: /dev/null: Anti-Cheat Kernel Driver (2020)

#84
This is a pattern I see very often and that I think all of us can see all the time. The developers of software try to control how the users use the software.

This is not just a regular customer or user relationship between the user and the developer. This is something else, some kind of controlling behavior that we need to get rid of.

You can't force someone to stop doing something as long as they do it on their own computer. You have to choose; either people use your computer with your rules or they use their own computer with their rules.

If players want to cheat, that's the player's problem, not the developer's problem.

Re: /dev/null: Anti-Cheat Kernel Driver (2020)

#85
Riot's anti cheat is the only one I've found that causes my KVM virtual machine running Windows to BSoD.

Ironic that the post title indicates Linux-awareness but the post content breaks any chance of playing Riot's games on a Linux computer.

Re: /dev/null: Anti-Cheat Kernel Driver (2020)

#86
post #45

Earlier quoted context omitted.

>DMA cheats keep getting better every day These require buying physical harder instead of someone being able to just download a cheat for free. Also if you are writing memory to cheat / sending weird packets you can detect that and ban them.

they paying a monthly subscription for "undetectable" cheats these days anyway and they're not cheap, $59.99/month would be pretty middle of the road a cheap $30 card is nothing

The video mentions people being willing to pay up to 2k for such devices. With the DMA device itself costing a couple of hundred, plus cheat development time, plus extra hardware, I don't expect these setups become very affordable any time soon.

Re: /dev/null: Anti-Cheat Kernel Driver (2020)

#87

No matter how low-level they get in the OS, this is ultimately a losing battle. Aimbots have gone analog (src: https://hackaday.com/2022/04/30/aimbot-does-it-in-hardware/ ) What can they do next? Demand webcam access with your mouse visible, I guess?

No, but the higher the moat the less cheaters you have. No anti-cheat is perfect or even blocks all cheaters, hell even console has aimbots thanks to console modding. It’s about reducing the amount, making it harder and preemptively banning people who go at it wrong, i.e.: using a known cheat.

Better to have few cheaters than a million of them running baby’s-first-Python-script that just sends plain old WM_MOUSE.

Re: /dev/null: Anti-Cheat Kernel Driver (2020)

#88
post #86
post #45

Earlier quoted context omitted.

they paying a monthly subscription for "undetectable" cheats these days anyway and they're not cheap, $59.99/month would be pretty middle of the road a cheap $30 card is nothing

The video mentions people being willing to pay up to 2k for such devices. With the DMA device itself costing a couple of hundred, plus cheat development time, plus extra hardware, I don't expect these setups become very affordable any time soon.

at the moment they're being assembled by people in their garages

once economies of scale take off they'll be $19.99

Re: /dev/null: Anti-Cheat Kernel Driver (2020)

#89

> Now, while most players might find the idea of a corrupted Windows installation objectionable, a disturbing number of cheaters have shown themselves to be downright enthusiastic about the opportunity to jump onto some guy’s botnet in exchange for the ability to orbwalk. So they acknowledge that running third-party stuff in kernel mode increases the likelihood your machine gets owned by malware, in the very same blo…

> your machine gets owned by malware

That's the whole point, is it not? Anticheat is malicious software burning up CPU cycles and reducing security whether you're cheating or not...

Re: /dev/null: Anti-Cheat Kernel Driver (2020)

#90
post #42

Earlier quoted context omitted.

The hardware isn't banned, the player is banned if the anticheat detects the hardware being used. The hardware might be reprogrammable and self modifying at some point in the future, but until it is and it's widely available a root level anticheat is adequate protection.

The player is not banned. The player's account is banned. It is a free game- they can make as many accounts as they like. The hardware will become widely available once kernel-level anticheat becomes widely used. >if the anticheat detects the hardware being used. The only thing the anticheat will be able to detect is ordinary hardware. My cheating device will capture input from HDMI or PCI, the software sees it as a…

Regarding the hardware detection - there's always way to up the game and make the system totally airgapped.

It is not impossible to have mechanical actuators pressing keys and moving a mouse, and a webcam watching a real monitor. While that's an awful lot of work compared to just reading data off a bus and simulating a HUD device, consider that some decades ago (when the fight was entirely about API hooking and ReadProcessMemory) DMA snooping was considered merely an unrealistic, theoretical possibility.

Post reply on HN