Live data from Hacker News

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

leagueoflegends.com

51–60 of 142 posts

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

#51
post #27
post #20

Earlier quoted context omitted.

> If the hardware is banned, I need to wait a few days before my replacement hardware is there, or with software I just update and restart. Except perhaps the first few iterations, the hardware won’t be banned. You’ll just have to load a software update for your DMA hardware.

Great, so for the first few iterations hardware bans are effevtive!

Those first few iterations are already happening.

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

#52

Earlier quoted context omitted.

Okay, but you couldn't just have a linux computer procedurally generating that video, then exposing itself to the host computer as a webcam over usb gadget driver? Not to mention that you would have to comb through all this footage to detect cheaters... It is honestly a laughable solution.

Yes, but writing a program to synthetically generate correct images will take a while to come out in which players can play without cheaters ruining games.

Creating a system to automatically verify correct videos will take a while to come out, not to mention that it is extremely invasive for the end user and requires that they own all this extra equipment and bandwidth.

The cheater does not even really need to generate fake video like I've described. Aimbots can be as subtle as the cheater wants them to be, offering <5% precision adjustments which won't be visible on a webcam. Not to mention that half of cheating is just information assistance like wallhacks which this doesn't even cover.

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

#53
post #41

Earlier quoted context omitted.

> 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.

[deleted]

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

#55
post #33

You basically can't have a PC game in 2022 without a kernel rootkit to detect cheating.

They’ve never actually rolled this out for League. I’ve played hundreds if not thousands of hours of competitive matches over a decade and never seen a blatant cheater (maybe 1-2 cass botters, but couldn’t be sure). Given that it’s one of the biggest online PvP games around, I don’t think you or Riot are really making a strong case here.

I believe this is referring to Vanguard, the anti-cheat Valorant uses that at some point is supposed to come to League.

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

#56
post #25

Earlier quoted context omitted.

> 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 be…

Admin privileges don’t matter, all the stuff you care about lives in your homedir.

Have you ever seen a real world example of super common and super insecure AV drivers being exploited for LPE? Probably not, it’s not worth the trouble.

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

#57
post #41

Earlier quoted context omitted.

> 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.

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

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

#58
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?

Literally nobody does that. That riots anticheat driver might interfere with your incredibly niche use case is fundamentally not a very compelling argument.

Besides, Windows LPEs are a dime a dozen anyway.

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

#59
post #23

Does Microsoft have to approve these drivers? I would argue Microsoft should not allow this kind of thing if they really want to provide security. Apple would never approve such a mechanism, for sure.

For Microsoft you need a code signing certificate [0], shell out about $500 and to follow some instructions. Apple do allow this through kernel extensions, but its very much opt in from users. [0] https://docs.microsoft.com/en-us/windows-hardware/drivers/de...

While i'm not sure if it works for device drivers, Microsoft is working on Azure Code Signing, which moves it from third-party vendors to MS directly.

For Apple, kexts have been deprecated for a while, with more modern APIs available for ensuring privacy and security in device drivers[1].

1: https://developer.apple.com/support/kernel-extensions/

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

#60
post #42

Earlier quoted context omitted.

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.

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 graphics card or a display. My cheating device lets me inspect memory directly, the motherboard just sees a normal stick of RAM. My cheating device lets me bhop and aimbot- the OS just sees an ordinary USB keyboard and mouse

Post reply on HN