
Why anti-cheat software utilize kernel drivers; a view from RE experts - invokestatic
https://secret.club/2020/04/17/kernel-anticheats.html
======
yellowapple
The arguments in the article seem to be... problematic.

> Unloading kernel drivers is as easy as stopping the registered service for
> them, which you can do by using the command sc stop <driver>. This of course
> relies on the fact that the driver has set its unload routine in kernel.

And if it hasn't? That seems like a glaring issue, and good reason to be
skeptical of installing kernel drivers willy-nilly.

> Almost all commercial anti-cheat solutions, this includes BattlEye and Easy
> Anti Cheat, utilize kernel components to ensure the integrity of the user
> experience, but do not receive the same backlash as Vanguard.

Both of those receive _lots_ of backlash for the exact same reasons that
Vanguard receives backlash.

To my knowledge, Valve Anti-Cheat (VAC) requires no such kernel-level access
(it definitely doesn't on Linux, judging by lsmod, but I can't attest to
Windows since I haven't ran Steam on it in years) and still (last I checked)
manages to be good enough.

> I know that this goes against the current opinion that having a driver load
> on boot is bad, but if you want to prevent widespread hacking, this is
> exactly how you do it.

Sure, until cheaters start running hypervisors and interfering with even in-
kernel anti-cheat approaches. Sure, the vast majority of readily-available
hypervisors (of the sort capable of running Windows) are trivial to detect (as
secret.club's blog already describes: [https://secret.club/2020/04/13/how-
anti-cheats-detect-system...](https://secret.club/2020/04/13/how-anti-cheats-
detect-system-emulation.html)), but it doesn't seem like a stretch to think
that can and will change.

> This [kicking players when they plug in phones] is most likely a bug in
> Vanguard that scans the usage of serial ports, and is not worth of further
> discussion.

What? This is _absolutely_ worth further discussion. That sort of bug gives me
zero confidence that Vanguard is competently-designed, and is also a major red
flag privacy-wise, no matter how much the author assures the reader that
"Vanguard is totally not stealing data off your phone, promise".

> You do not need a boot-loading kernel driver to dump Google Chrome
> passwords, grab banking details or log your keystrokes, so this could be
> said about any usermode application you install on your computer.

A kernel module can do far worse than those things, ranging from making
spyware doing those things impossible to detect/prevent (by interfering with
anti-virus software) to outright bricking one's machine (whether a soft-brick
via making the OS unbootable or a firm/hard brick by tampering with UEFI).

> Right, it is also possible that someone hacks Microsoft, or literally any
> other company that runs code on your computer. This is very odd criticism
> and hard to refute as it is solely hypothetical.

This is not an odd criticism at all; the refutation, rather, is what's odd.
Reducing attack surface is a viable and common approach to computer security,
and this advice - that "oh it's okay that Vanguard's increasing that attack
surface because there's no such thing as perfect security" \- is both wrong
and irresponsible.

And it's _not_ solely hypothetical, specifically because there's no such thing
as perfect security. Vanguard has security-critical exploits that will be
exploited. It ain't a matter of "if", but "when". If even Microsoft with all
its billions upon billions of dollars of manpower can't make Windows' kernel
code bulletproof, what makes

> The last sentence does bother me, though. As I’ve demonstrated in this
> article, this raise is definitely not uncalled for.

This pair of sentences bothers me, given that - as previously mentioned - the
raise [in permissions] is very much uncalled for, and almost certainly
pointless in the long run.

