Yep. The article even smugly tries to boast about how they're adults and understand these things:
> We haven’t needed both arms yet, primarily because we have the advantage of steady paychecks and the lack of strict bedtimes at our immediate disposal. But as much as we might like the idea of an ever-escalating appsec war with teenagers,
And yet they fail to realize that they're playing in to the very cat-and-mouse game they deride. I can't wait until this escalates into "ok, well, now you need Intel TSX with Secure Enclave to verify that you're using the League video driver, and our proprietary USB dongle to play our game."
Spoilers: the teenagers will always win; you can never trust a client no matter how many technical barriers you erect. Look to the entire legacy of DRM for how this strategy has been tried and has failed. Server-side statistics are the only hope against serial cheaters - they're barking up the wrong tree here.
That's correct. The ability to cheat relies on the fact that servers don't actually model the client's view of the world to any fidelity. The server sends you information about the world you can't see so it doesn't have to do the culling. It accepts clearly impossible input that is obviously not human because statistical analysis would require some data scientists who are quite difficult to hire at the bargain-basement rates game companies pay.
You don't even need a hypervisor to bypass this, just a driver that pretends to be their kernel driver.
Servers usually try to do culling, if only to optimize network traffic. But they can't cull in real time, because the visual lag from round-trip to the server would be too much; and if the client doesn't wait for the server, then the player would see gaps in the world if they move around fast enough that server can't catch up. So they pessimistically provide more data than the client "should "know about.
I'm getting the same vibes from this article that I got from when LifeLock's CEO posted his SSN to taunt people / promote their own service... and frankly, I'm looking forward to the same schadenfreude. Never underestimate the resourcefulness of teenagers powered by spite and boredom.
That seems to be Riot's phylosophy for everything these days, unfortunately. They treat their playerbase with this incredibly smug and patronizing attitude, which is what personally drove me away from the game.
Seriously, no voice chat after a decade because of "toxicity"?
> Spoilers: the teenagers will always win; you can never trust a client no matter how many technical barriers you erect.
This type of battle can't be won, but if you do it right, you can push most of the cheaters somewhere else. Of course, if you do it wrong, you push legitimate players out too.
> Spoilers: the teenagers will always win; you can never trust a client no matter how many technical barriers you erect.
I think if we accept sgx type technology onto our systems then they can at some stage win this battle, at least theoretically. This is assuming that the sgx-like tech cant be practicably attacked, which isnt currently a valid assumption but could, at least theoretically, be in the future.
This differs from non-hardware drm which is basically just obfuscation, and which the method they're currently describing is merely an extension of.
SGX is theoretically strong, but the implementation matters. If the motivation and budget is there, SGX enabled chips could be decapped and reverse engineered. It would be an immense challenge though, so I doubt the budget would be there for cheating. Implementation errors are a more realistic target.
But, assuming you can't cheat on the system itself, you can probably cheat with the video/audio signal and generating USB inputs. It's harder than reading ram, but it's not feasible to stop it. At that point, you have to depend on behavioral targeting and what not (which they're already doing)
You could do DMA on the video-game memory, you could plug the monitor HDMI cable into a raspberry pi 5 or 6 camera input and do framebuffer based aimbot, you could stealthily modify the GPU drivers to give you data before some processing stages (you could probably do that without leaving anything in CPU RAM for too long), and so on.
The SGX won't allow you do this as the memory is encrypted
> plug the monitor HDMI cable into a raspberry pi 5 or 6
I don't know if the pi is powerful enough for that or not, and a HDCP type extension to what's coming out of the SGX could stop it, but ultimately yeah, you could have a robot play the game for you.
> stealthily modify the GPU drivers
Again, SGX type systems aren't going to allow that. This side of SGX type systems is all about trying to make your computer act how the developer wanted it to, regardless of your wishes or a malicious actor's wishes.
For better or worse, anti-cheat and DRM kernel drivers have been a thing since WinXP (and would have been before then, if Win9x required that for full system access).
Probably only because most hypervisors don't bother to hide themselves. There's no reason you couldn't prevent detection.
Not to mention some people are creating FPGA boards that use DMA to read memory, something no one is setup to prevent (would require an IOMMU and an OS that bothered to configure it properly; also very difficult to differentiate legit cards from cheating cards and an area game developers have zero experience with right now).
> some people are creating FPGA boards that use DMA to read memory
Do you have any links handy where one could read more about this? I'm really curious about the kinds of projects people are doing which requires this kind of hardware.
It's pretty easy to detect an hypervisor. There was an article recently on using CPUID timing to that effect. It takes a few cycles on bare metal, but hundreds when virtualized.
There are ways to defeat the time measurement, but it gets complicated fast, and the counter-measure itself is trivial to detect.
this would be the case if there wasn't an external entity with its own timesource (i.e. the game server) interrogating your machine while the game in underway
if there's a VMEXIT it will be measurable, and you have no ability to virtualise the server's clock
there's so many ways to detect a hypervisor, particurarly so if you want your VM to be of sufficiently high performance to play competitively
and then there's the statistical methods (measuring anything that causes a VMEXIT is a good candidate)
modern OSes already support the IOMMU (macOS enables it on by default apparently), however outside of that hardware support is patchy at best
ultimately if they're trying to guard the top of the ladder (say the top 0.05%), they could demand you use a certain set of hardware, and the hardcore would put up with it
I've actually done it, for a purpose unrelated to this topic.
Although if you're trying to circumvent something in the kernel, using a Docker container isn't going to work. Docker containers share the host kernel.
> We haven’t needed both arms yet, primarily because we have the advantage of steady paychecks and the lack of strict bedtimes at our immediate disposal. But as much as we might like the idea of an ever-escalating appsec war with teenagers,
And yet they fail to realize that they're playing in to the very cat-and-mouse game they deride. I can't wait until this escalates into "ok, well, now you need Intel TSX with Secure Enclave to verify that you're using the League video driver, and our proprietary USB dongle to play our game."
Spoilers: the teenagers will always win; you can never trust a client no matter how many technical barriers you erect. Look to the entire legacy of DRM for how this strategy has been tried and has failed. Server-side statistics are the only hope against serial cheaters - they're barking up the wrong tree here.