An ioctl() call to detect memory writes

Posted Aug 10, 2023 14:41 UTC (Thu) by delroth (subscriber, #110092)
Parent article: An ioctl() call to detect memory writes

This has more potential use cases than the "dubious" anti-cheat technique described in this article. For example, emulation of guest systems that have unified memory on host systems that don't. Back when I worked on the Dolphin Emulator (for GameCube/Wii) we spent a ton of CPU time hashing texture data which is shared in RAM between CPU/GPU on the original system, but has to be explicitly uploaded to the GPU on PC. It's not trivial to detect writes because that would happen in emulated PowerPC code, which gets JITed and which is very performance sensitive (so you can't "just" keep a list of tracked pages and do a hashtable lookup on each memory write to invalidate ranges). In a time pre-userfaultfd we tried to implement something like this using mmap(PROT_READ) and a SEGV handler, but this ended up not being much faster than simply re-hashing all shared memory resources before GPU command submission. We've wanted a feature like this for a while!

An ioctl() call to detect memory writes

Posted Aug 10, 2023 15:53 UTC (Thu) by DemiMarie (subscriber, #164188) [Link]

The ideal solution would be to use the hardware accessed/dirty bits.

An ioctl() call to detect memory writes

Posted Aug 10, 2023 19:37 UTC (Thu) by dullfire (guest, #111432) [Link] (10 responses)

Yeah, I agree the anti-cheat this is of dubious value.

I can understand the frustration of a gamer who's game is malicious. However I don't think a reasonable solution to that is help game developers be more abusive[1].

However the use for dolphin sounds awesome.

[1] Authors of software have no business tell the owners of a computer system what memory regions/values they can write to. And to be honest, unless there is net play, one person cheating... is irrelevant. It's like cheating at solitaire.

If there is net play, and your game isn't designed such that the server alone is sufficient to detect and prevent cheating... then you have always lost.

An ioctl() call to detect memory writes

Posted Aug 10, 2023 23:03 UTC (Thu) by edeloget (subscriber, #88392) [Link] (7 responses)

There's a common misconception here. When you design a network-played game you want the player to have the best possible experience. If you want to always verify everything on the server, you won't be able to get that for all players -- and, as a game developper, expecting that only those who have the highest bandwidth and the lowest latency will buy your game is both naive (people expect Cyberpunk 2077 to run fast on old CPUs with a dated GPU) and stupid (why would you want to purposedly avoid sells?).

There's also the fact that not all cheating techniques rely on /checks/. Some only rely on informations that must be displayed by the client. For example, when an ennemy is visible on your screen then an auto-aim can get it and help you to get a kill. Auto-aiming might not be easy to catch on the server side (if your kill stats does a visible jump then there is a problem ; but if you're already a good player who wants to win more (for various reasons: fame, ranking... ; for this, see the unusually high number of already very good streamers that were caught red handed. At some pint, competitive gaiming is really... competitive).

(Frankly, if I ever had to device an aimbot, I would market it as 'progressive', giving you better and better results as you use it in order to mimic a real player progression. How would a server detect that without risking to ban players that are really progressing fast?)

Moreover, some cheats /are/ playing with the network. Some small variation in the rate at which your game clients send packets might not be detected by the server (because of natural jitter) but may provide you important advantages in some situations. This was the case in Minecraft for example, where a slight acceleration of the packet sending speed would allow you to run a bit faster -- nothing dramatic, but since all players are running at the same speed... This can be detected if overused but it's very difficult to detect if used in a clever way (for example to get a small boost during a few seconds here and there) unless you want to detect a lot of false positives.

Expecting a server to always catch dubious things and rapidly act on them is not going to work well in practice. Game clients will always have to do some important checks in order to be usable, and of course they will always need to display information to the user.

An ioctl() call to detect memory writes

Posted Aug 11, 2023 1:27 UTC (Fri) by KJ7RRV (subscriber, #153595) [Link] (4 responses)

Isn't a real, non-cheating player suddenly getting better possible? For example, I became much better at keeping my plane in FlightGear straight and level when I realized I was overcorrecting for minor deviations. Since I recognized that and started making smaller corrections, I have been flying a lot better. I'm assuming this could happen with most video games?

An ioctl() call to detect memory writes

Posted Aug 11, 2023 3:34 UTC (Fri) by farnz (subscriber, #17727) [Link]

This is the ultimate end state of a lot of game cheats; the cheat acts to make you suddenly get much better in a way that's humanly plausible. It's thus impossible to distinguish cheaters from humans who learn from their mistakes, since the cheat improves your play over time in exactly the same way as would happen if you learnt over time.

In the really extreme case, someone builds a machine that operates the same controls as you, in parallel to you, and that has machine vision and listening - this is now undetectable from within the game, since the inputs and outputs are the same as used by the human player.

An ioctl() call to detect memory writes

Posted Aug 11, 2023 8:22 UTC (Fri) by edeloget (subscriber, #88392) [Link] (2 responses)

> Isn't a real, non-cheating player suddenly getting better possible?

Yes, of course.

Anyone can have a gotcha moment when playing a video game, resulting in a detectable jump in their playing abilities. Some players might just change their glasses and become suddenly better. Or you might start playing a game while being temporarily disabled (broken arm for example) and then become visibly better when that condition disapear.

There are tons of reasons why a player might legitimately become better so the game server cannot act on this information alone (and in most case, that's only what it gets).

An ioctl() call to detect memory writes

Posted Aug 11, 2023 10:22 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

And how is a local memory watch thing going to do this any better? (beyond the very short term)

An ioctl() call to detect memory writes

Posted Aug 11, 2023 13:40 UTC (Fri) by rincebrain (subscriber, #69638) [Link]

Not the person you were replying to, but I think it's somewhat analogous to why modern games use copy-protecting DRM for the initial release and drop it after like 3-6 months.

You aren't going to stop everything - if there's an enormous market for your project, people are going to throw themselves at it and eventually some portion are going to find ways around your mitigations.

But if you, say, filter out 95% of the people trying to circumvent you by making the barrier high enough, that may result in a good enough result that the thing you're trying to optimize for (protecting the huge upfront hump of initial sales, preventing your multiplayer experience from having a reputation for being instakill aimbots with no stopping them) might be achievable.

Of course, unlike that kind of use-until-burned DRM, cheat detection becomes an ongoing cat and mouse game for the game's lifecycle even if you are doing deeply invasive monitoring, so at some point you're (probably) going to end up having a tradeoff between using it as a varyingly weak signal to get human attention to look at a player and go "...are they obviously doing impossible things" and playing whack-a-mole with even more weird heuristics (and then, if you scale enough that you can't justify humans to do a priori review, just ban on the signal and clean up reports of false positives...).

I'm not, to be clear, claiming that any of the above invasive monitoring is good, nor that even the arguments about using e.g. Denuvo for protecting week 1 sales are accurate, but that that is my understanding of the rationales and tradeoffs involved.

An ioctl() call to detect memory writes

Posted Aug 11, 2023 12:07 UTC (Fri) by dullfire (guest, #111432) [Link] (1 responses)

I understand exactly why many modern games use client side anti-cheat. However I think my point was not conveyed. If anti-cheat has to be enforced on "not your hardware" then you have always lost.

For example, unless your going to require people never use USB devices (somehow... seems immensely impractical to me), it will always be trivial (especially $$$-cost wise, but also in low in engineering effort) to simple stand up a beaglebone black (or any of the other oodles of commodity hardware out there) as a "normal"[1] input gadget. And that's just one way. There are endless way to circumvent that... because the "hostile"(cheating) party controls the whole system of relevance.

My point is: if your game design requires some amount of anti-cheat be done client size, then your game is very fragile. You have no way to actually enforce that.

[1] Or a normal game pad, or microphone, or what ever else you are expecting that uses standard hid drivers.

An ioctl() call to detect memory writes

Posted Aug 11, 2023 14:29 UTC (Fri) by excors (subscriber, #95769) [Link]

> My point is: if your game design requires some amount of anti-cheat be done client size, then your game is very fragile. You have no way to actually enforce that.

Sure, but there are different options for responding to that situation:

1) Stop making games like that.
2) Keep making the games but give up trying to prevent cheats.
3) Put a substantial amount of effort into trying to imperfectly reduce cheating.

The problem with option 1 is that it includes basically all competitive action games (since they're inherently susceptible to client-side aimbots etc), which are some of the most popular games, with hundreds of millions of players and tens of billions of dollars of revenue. Players want those games and developers want to make those games.

The problem with option 2 is that rampant cheating will kill a multiplayer game. If you're in a match with 12 or 24 or 100 players, and even one of them is cheating, it's usually no fun. A small percentage cheating can mean you'll encounter one in almost every match, and then you'll stop playing the game. And that makes the cheater-to-non-cheater ratio worse for the remaining non-cheaters, so they're increasingly likely to quit too. We don't want the games to die for the same reason as point 1.

In practice, option 3 works. There are popular competitive action games on PC where cheating is rare enough that typical players won't be bothered by it. They use a combination of server-side and client-side techniques, plus other design techniques (like requiring a substantial investment of money and/or time before an account is allowed into competitive modes, so people can't trivially start cheating on a new account whenever their old one gets banned), and lawsuits against people selling cheats, etc. It's fragile and messy but it seems to be good enough, and I don't think I've seen any better ideas.

An ioctl() call to detect memory writes

Posted Aug 11, 2023 8:50 UTC (Fri) by excors (subscriber, #95769) [Link] (1 responses)

> If there is net play, and your game isn't designed such that the server alone is sufficient to detect and prevent cheating... then you have always lost.

For many types of game, that's simply impossible. Of course the server can and should prevent the player teleporting or giving themselves infinite ammo (and some games even fail at that step, which is just bad design), but there's no way the server can prevent aimbots (where the client analyses the video output and simulates mouse movements to more accurately aim at enemies) or wall-hacks (where the client messes with the rendering so they can see enemies through solid walls), which can be a serious problem for competitive shooters.

(Well, the server could avoid telling the clients about enemies that are meant to be completely obscured - but if the enemy has a nose or a shadow that's barely visible around the wall, or is making footstep sounds, then the client really needs to know about their position and cheat developers can make that enemy unnaturally visible. Some games do that and it helps but it's not perfect. See e.g. https://technology.riotgames.com/news/demolishing-wallhac...)

Game developers can add player reporting mechanisms and server-side heuristics to detect unnatural movements, but there's a significant risk of false positives, and cheat developers can make their cheats behave much more subtly and barely distinguishable from a highly skilled player. After that, it's just an arms race between client-side cheat detection and cheat-detection-avoidance. Game developers can't win that race, but they don't need to, they just need to make it sufficiently expensive for cheat developers to keep up that they have to charge large amounts of money for their cheats, so the total number of cheaters remains low enough that regular players are able to tolerate it and still enjoy the game.

An ioctl() call to detect memory writes

Posted Aug 11, 2023 12:04 UTC (Fri) by excors (subscriber, #95769) [Link]

> they just need to make it sufficiently expensive for cheat developers to keep up that they have to charge large amounts of money for their cheats, so the total number of cheaters remains low enough that regular players are able to tolerate it and still enjoy the game.

To add some actual numbers here: there was a Destiny 2 cheat seller who charged $13-$19 per day or $105-$169 per month, justifying the prices based on "the complex anti-cheat this game has . . . which means that high-quality cheats are expensive to create and maintain". They made about $150K over two years from 5,848 transactions, while the game developer claims to have "spent more than $2,000,000 on cheat mitigation (including staffing and software)" (though the mitigations were for all cheat sellers, not just this one). (https://thegamepost.com/wp-content/uploads/2023/02/bungie...)

Another seller charged $90 per month or $500 for lifetime access to Valorant cheats, and was believed to have sold "tens or hundreds of thousands of dollars". (https://www.polygon.com/2021/1/11/22224696/riot-bungie-de...)

Those sound like quite high prices that will discourage many players from casually cheating, and reasonable but not huge incomes for cheat developers. It seems plausible that a modest increase in the difficulty of defeating anti-cheat techniques will change the economics enough for some of the cheat developers to give up and find something more valuable to spend their time on.