Live data from Hacker News

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

leagueoflegends.com

41–50 of 142 posts

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

#41
post #16

Earlier quoted context omitted.

> So they acknowledge that running third-party stuff in kernel mode increases the likelihood your machine gets owned by malware Which is utter nonsense. Nothing will touch this kernel mode stuff unless they’ve already owned your machine. All the data you care about is accessible from usermode anyway. The risks of kernel mode anticheat have been wildly overstated, Riot is engaging in the same to spread silly FUD regar…

> The risks of kernel mode anticheat have been wildly overstated How many things like https://github.com/Luohuayu/evil-mhyprot-cli and https://mobile.twitter.com/TheWack0lian/status/7793978407622... have to happen before you'll believe that there really is a significant amount of risk here?

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.

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

#42
post #15

Earlier quoted context omitted.

The difference in effort, for a cheater, between installing a cheat as a user process and a kernel driver is about one button click. I can decide to cheat, stick my CC info into a website and download a program in less than 5 minutes. To get hardware I need to provide my shipping info and wait a couple of days. If the hardware is banned, I need to wait a few days before my replacement hardware is there, or with softw…

How could the cheating hardware be banned? it is general-purpose, there is no change in the programming of the host computer that couldn't be combated by reprogramming the cheating device. Security-by-obscurity is a game of cat-and-mouse where the cat is blind and the mouse is invulnerable.

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.

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

#43
After spending enough years fighting spammers and fraudsters, short of having an aggressive anti-cheating operations team (which can work great, but is of course expensive to operate), our spam strategies pointing to really one solution: making it more expensive to lose an account. This is why I think consoles are winning (too expensive to get banned) and why I thought VAC secure made a lot of sense (as long as the game isn't free - precisely why TF2 is now a bot haven). There needs to be some skin in the game that the cheater will lose if they get banned. Even the chance that they'll get detected deters them (which is absolutely fantastic when you consider the battle from an OODA loops perspective).

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

#44
post #16

Earlier quoted context omitted.

> So they acknowledge that running third-party stuff in kernel mode increases the likelihood your machine gets owned by malware Which is utter nonsense. Nothing will touch this kernel mode stuff unless they’ve already owned your machine. All the data you care about is accessible from usermode anyway. The risks of kernel mode anticheat have been wildly overstated, Riot is engaging in the same to spread silly FUD regar…

At least on Linux, a bug on the kernel module could lead to injection of other kernel modules, packages being installed, core binaries being tampered with, which are not impossible to do in userland but require deceiving the user in entering its credentials. I think on Windows, such actions lead to an overlay that ask for authorization and can't be auto-clicked ? If so, I think having such a prompt when not expected…

> At least on Linux, a bug on the kernel module could lead to injection of other kernel modules, packages being installed, core binaries being tampered with, which are not impossible to do in userland but require deceiving the user in entering its credentials

None of this matters, because all the files you care about live in your homedir anyway. In a desktop environment, the malware can tamper with your .profile to replace e.g. the sudo binary and gain root access without any exploits.

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

#45
post #3

Of course, this is just a blog post by a gaming company for their gamer audience, but lots of this stuff is downright dishonest. For example: > 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 Kernel…

>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

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

#46
post #25

Earlier quoted context omitted.

Not to mention them saying "if you use AAA games, you may already have such a thing running already so one more won't kill you." whereas, in real life, it increases the odds that a system will get hacked due to it since the attack surface increases (The number of bugs in "EA+Riot" could not be less than "EA", but could be higher, and the other way around)

> whereas, in real life, it increases the odds that a system will get hacked due to it since the attack surface increases Bullshit. In real life nobody will hack you with a videogame anticheat kernel driver exploit. They will hack you with a browser exploit, a ms office exploit, or just because you downloaded a malicious executable and decided to run it.

I agree that getting hacked through a browser is a far higher risk. However, the said browser is hopefully running with admin privileges, and if it is needed by the malware, it will need something else to exploit. If it was some small editor, it would serve no purpose for this. But we're talking about Riot Games, whose software is installed on hundreds of millions of machines and thus have a non-neglictible odd of being on the target's computer.

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

#47

This is very concerning. Installers on Windows in 2022 should not even require admin permission (only elevating if a user wants to install for all users). What if Riot had a supply chain attack and someone attached something far more malicious to the kernel?

What damage do you expect they will do with kernel access that they won't do with admin access?

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

#48
post #37

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.

> instead of someone being able to just download a cheat for free Decent hacks are already rather expensive, it’s not unusual for people to pay above $100/mo. > Also if you are writing memory to cheat […] you can detect that and ban them. There is no generic way to detect this.

Many are around $50/mo too so people are spending $600/year on a subscription to keep the cheats up to date and patched.

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

#49
What a load of baloney. It's an open secret that client side cheat detection is a losing battle, and yet many games still persist with these unacceptably hacky half measures. The correct approach has always been to perform the cheat detection on the server side and use statistical analysis to detect and ban cheaters. No brittle assumptions about client environment resulting in potential breakages or false bans. No invasive rootkits that could compromise your users' machines. No opportunity for the client to reverse engineer or instrument the binary to patch out the cheat detection methods.

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

#50
post #15

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?

The difference in effort, for a cheater, between installing a cheat as a user process and a kernel driver is about one button click. I can decide to cheat, stick my CC info into a website and download a program in less than 5 minutes. To get hardware I need to provide my shipping info and wait a couple of days. If the hardware is banned, I need to wait a few days before my replacement hardware is there, or with softw…

That's why I have to qualify it with ultimately

Right now, the analog option is out of reach except to those with the right skills. But the hardware isn't that expensive even now, and will only get cheaper. All it takes is someone to commodify it.

Post reply on HN