Why anti-cheat software utilize kernel drivers; a view from RE experts

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