0

As far as I understand, usually the game anti-cheat runs in another process from the game client. This makes it obvious to try to simulate anti-cheat, for example, to replace it with your program, which interacts with the game client and the game server in the same way as anti-cheat, but does not perform any actual cheating software detection.

Since it is not so difficult to log all interprocess and network interactions of a particular process, it seems a simple (but tedious) task to reverse engineer the protocols used by anti-cheat for communication and write a mock implementation that would look legitimate from the perspective of the game client and server.

What prevents cheat developers from disabling anti-cheat in this way? How can anti-cheat protect itself from such attacks?

The best idea I came up with is to integrate message signing in all (or some of) anti-cheat communications and make it really difficult to obtain the key via obfuscating. But this would only make it harder to crack communication protocols and is vulnerable to runtime memory expection attacks, since anti-cheat have to assemble the key at some point in runtime and put it in the memory

Improve this question
0

1 Answer 1

Reset to default
0

You're right. There's a lot of ways to make the bypass you describe harder, but there is no way to prevent it completely. That's why even games with super-invasive client-side anti-cheats that do things like run in the kernel and severely compromise your security and privacy still have rampant cheating problems.

Improve this answer
4
  • "severely compromise your security and privacy" there's a ton of speculation in this answer and no proofs whatsoever. There have been issues with anticheats using low level drivers but nothing that has persisted to this day. It's still a whole lot better than application level anticheats which are extremely easy to circumvent.
    – Artem S. Tashkinov
    Mar 26 at 9:15
  • 1
    @ArtemS.Tashkinov It's a matter of principle, especially for legitimate users. I do not consent to give an application developer access to my kernel. I don't see why this is necessary, especially since there are PoCs of so called "no-exec cheats" out there. These work by having a webcam pointed to the game, using ML to detect enemies and using fake USB devices to enter the chested input. In other words, even the host OS can't detect foul play, since it runs on another machine. It's over. Cheaters won.
    – Frittata
    Mar 26 at 20:07
  • Cheaters have not won as evidenced by multiple e-sport titles with massive prize pools reaching tens of millions of dollars (DOTA2). You want to believe that despite running Windows 10/11 which contains a metric ton of telemetry you're better off without kernel level anticheats which you cannot even prove conclusively are used against you in any capacity. Sorry, to me it sounds like you want to believe other players who have ground for thousands (!) of hours are all "cheaters" and you just "wanna play" and believe everyone is a cheater around you.
    – Artem S. Tashkinov
    Mar 26 at 21:01
  • I'm sorry to break it to you but my Steam Profile wall contains literally dozens of accusations of cheating in a certain game but I've never cheated against other players. I do admit that I've cheated offline when I played certain single player campaigns. I always set the difficulty to the highest and sometimes I just don't have it to win over enemies, as I'm not young any more and my reaction times have gotten worse. Cheaters do exist but those "no-exec" cheats are exceedingly vanishingly rare. To think that they are "common" to me sounds like a case of believing in wild conspiracies.
    – Artem S. Tashkinov
    Mar 26 at 21:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .