4 ms·

What a load of baloney. It's an open secret that client side cheat detection is a losing battle, and yet many games still persist with these unacceptably hacky

What a load of baloney. It's an open secret that client side cheat detection is a losing battle, and yet many games still persist with these unacceptably hacky half measures. The correct approach has always been to perform the cheat detection on the server side and use statistical analysis to detect and ban cheaters. No brittle assumptions about client environment resulting in potential breakages or false bans. No invasive rootkits that could compromise your users' machines. No opportunity for the client to reverse engineer or instrument the binary to patch out the cheat detection methods.

maccard 4y ago
> yet many games still persist with these unacceptably hacky half measures. Unfortunately what you're suggesting is a hacky half measure. From a servers perspective there is no difference between a client with a shitty connection and a client who is pretending they have a shitty connection to cheat. The reality is that servers trust clients for some cases (and verifies that those things are possible) because it provides a better experience for a large number of players. > No brittle assumptions about client environment resulting in potential breakages or false bans. Let's be honest, server side anticheat is no less susceptible to this than client side. If you're banning on heuristics there's going to be false bans at some point, and you are making assumptions about a perfect client environment with this approach. > No opportunity for the client to reverse engineer or instrument the binary to patch out the cheat detection methods. Except you can analyse the ban rates based on how "aggressive" your cheat is across all your players and adjust the effectiveness to keep it under that threshold. If we're going to make the claim that cheaters can always adapt to client side cheats, we can make the same claim for server side cheats.
- 10000truths 4y ago
  > From a servers perspective there is no difference between a client with a shitty connection and a client who is pretending they have a shitty connection to cheat. The reality is that servers trust clients for some cases (and verifies that those things are possible) because it provides a better experience for a large number of players. Lag switching is only one kind of cheat that applies mainly to multiplayer FPS games, and as I said, it can be mitigated through statistical analysis. A simple method would be to kick players (but not ban) from a match if they have too many latency spikes. A better method would be to analyze how often a player's latency spikes coincide with their kills, and ban them if there is excessive correlation. You are right that preventing any and all forms of cheating is impossible, especially where such methods would negatively impact the player experience. But a perfect solution isn't necessary. Issuing bans after the fact is still effective, as long as the cheaters don't make too much progress or otherwise cause too much impact within that time frame. > Let's be honest, server side anticheat is no less susceptible to this than client side. If you're banning on heuristics there's going to be false bans at some point, and you are making assumptions about a perfect client environment with this approach. But that tradeoff is entirely under your control. With server side heuristics, you are in a better position to understand how it works and document it so that others on your team understand it as well. You can tweak its parameters and specialize it with assumptions specific to your game mechanics, and minimize false positives to some probability interval. You can identify specific cheating patterns (e.g. perfectly tracking an enemy behind walls long since the enemy is last seen) and tailor your heuristic to detect such cases. You can feed it more sample data to increase its accuracy. You can set up processes to verify ambiguous cases with human moderators in the loop. None of this requires any assumptions about the client environment, it only requires analyzing the player inputs received by the server over the network. Client side heuristics, on the other hand, tend to be based on things that serve as rather poor proxies for cheating. Running the game in a virtual machine? Banned. Running the client in WINE on Linux? Banned. Driver signature enforcement disabled? Flagged. User running AutoHotKey or WinDbg or Ghidra? Flagged. New Windows update that breaks some internal NT kernel ABI that my anti-cheat rootkit was relying on? Uh oh. These detection methods are better than nothing, but heavy reliance on them has made it easy for cheaters to circumvent anti-cheats while still causing issues for legitimate players whose setup might deviate slightly from the norm. > Except you can analyse the ban rates based on how "aggressive" your cheat is across all your players and adjust the effectiveness to keep it under that threshold. If we're going to make the claim that cheaters can always adapt to client side cheats, we can make the same claim for server side cheats. While true, this sort of signal carries much less information than what you can gain from reverse engineering client side cheat detection. You can make it more difficult by issuing ban waves at fixed intervals, and slightly varying the thresholds by some small random amount each time. Larger ban wave intervals mean that it takes longer for cheaters to infer the behavior of your server side anti-cheat, at the cost of taking longer to ban cheaters. But again, that tradeoff is under your control.
  - maccard 4y ago
    Every now and again I read things on HN about the area that I work in that reminds me that HN despite being confident doesn't always know what it's talking about. If it's so easy, can you share a prototype of someone doing it? Surely, if you can solve the entire problem of anticheat in one HN post there must be some proof to back it up. > Lag switching is only one kind of cheat that applies mainly to multiplayer FPS games, and as I said, it can be mitigated through statistical analysis <...> These methods are already in use with client side cheat detection. The thing about latency spikes is that there are many things that cause them. To use your example of checking when spikes appear near a kill in an FPs, presumably a kill is associated with a spike in traffic (multiple users shooting, extra movement, etc). So it's far more likely that you see spikes at the point of extra network traffic. Lag spikes wee also only one example. > With server side heuristics, you are in a better position to understand how it works and document it so that others on your team understand it as well You have control over all of these things with client side heuristics and cheat detection too don't forget. > Running the game in a virtual machine? Banned. Running the client in WINE on Linux? Banned. Driver signature enforcement disabled? Flagged. User running AutoHotKey or WinDbg or Ghidra? Flagged. New Windows update that breaks some internal NT kernel ABI that my anti-cheat rootkit was relying on? Firstly, the NT interface is probably the most stable of any software im aware of. I don't personally keep up with kernel breakages but my understanding of them is they're incredibly incredibly rare. They're also very well documented and published on a mostly expected cadence. If an anticheat isn't being kept up to date, it's ineffective, whether or not that's in relation to it's heuristics or its support for OS features. Secondly, there's a reason all of those things are suspicious. (And as an aside many games don't actually ban you for running them, they pop up and tell you to turn them off before killing the game . They _do_ ban if you bypass that check though). > causing issues for legitimate players whose setup might deviate slightly from the norm. Having ghidra or windgb running, or running via wine isn't "slightly" out of the norm, it's a statistical anomaly that would be flagged as "massive outlier" if heuristics were applied. Also, why is it ok for players whose software setup deviates from the norm, but not ok for players with outlying network setups? > You can make it more difficult by issuing ban waves at fixed intervals, and slightly varying the thresholds by some small random amount each time. So exactly the same methods in use right now?

maccard 4y ago

> yet many games still persist with these unacceptably hacky half measures. Unfortunately what you're suggesting is a hacky half measure. From a servers perspective there is no difference between a client with a shitty connection and a client who is pretending they have a shitty connection to cheat. The reality is that servers trust clients for some cases (and verifies that those things are possible) because it provides a better experience for a large number of players. > No brittle assumptions about client environment resulting in potential breakages or false bans. Let's be honest, server side anticheat is no less susceptible to this than client side. If you're banning on heuristics there's going to be false bans at some point, and you are making assumptions about a perfect client environment with this approach. > No opportunity for the client to reverse engineer or instrument the binary to patch out the cheat detection methods. Except you can analyse the ban rates based on how "aggressive" your cheat is across all your players and adjust the effectiveness to keep it under that threshold. If we're going to make the claim that cheaters can always adapt to client side cheats, we can make the same claim for server side cheats.

10000truths 4y ago
> From a servers perspective there is no difference between a client with a shitty connection and a client who is pretending they have a shitty connection to cheat. The reality is that servers trust clients for some cases (and verifies that those things are possible) because it provides a better experience for a large number of players. Lag switching is only one kind of cheat that applies mainly to multiplayer FPS games, and as I said, it can be mitigated through statistical analysis. A simple method would be to kick players (but not ban) from a match if they have too many latency spikes. A better method would be to analyze how often a player's latency spikes coincide with their kills, and ban them if there is excessive correlation. You are right that preventing any and all forms of cheating is impossible, especially where such methods would negatively impact the player experience. But a perfect solution isn't necessary. Issuing bans after the fact is still effective, as long as the cheaters don't make too much progress or otherwise cause too much impact within that time frame. > Let's be honest, server side anticheat is no less susceptible to this than client side. If you're banning on heuristics there's going to be false bans at some point, and you are making assumptions about a perfect client environment with this approach. But that tradeoff is entirely under your control. With server side heuristics, you are in a better position to understand how it works and document it so that others on your team understand it as well. You can tweak its parameters and specialize it with assumptions specific to your game mechanics, and minimize false positives to some probability interval. You can identify specific cheating patterns (e.g. perfectly tracking an enemy behind walls long since the enemy is last seen) and tailor your heuristic to detect such cases. You can feed it more sample data to increase its accuracy. You can set up processes to verify ambiguous cases with human moderators in the loop. None of this requires any assumptions about the client environment, it only requires analyzing the player inputs received by the server over the network. Client side heuristics, on the other hand, tend to be based on things that serve as rather poor proxies for cheating. Running the game in a virtual machine? Banned. Running the client in WINE on Linux? Banned. Driver signature enforcement disabled? Flagged. User running AutoHotKey or WinDbg or Ghidra? Flagged. New Windows update that breaks some internal NT kernel ABI that my anti-cheat rootkit was relying on? Uh oh. These detection methods are better than nothing, but heavy reliance on them has made it easy for cheaters to circumvent anti-cheats while still causing issues for legitimate players whose setup might deviate slightly from the norm. > Except you can analyse the ban rates based on how "aggressive" your cheat is across all your players and adjust the effectiveness to keep it under that threshold. If we're going to make the claim that cheaters can always adapt to client side cheats, we can make the same claim for server side cheats. While true, this sort of signal carries much less information than what you can gain from reverse engineering client side cheat detection. You can make it more difficult by issuing ban waves at fixed intervals, and slightly varying the thresholds by some small random amount each time. Larger ban wave intervals mean that it takes longer for cheaters to infer the behavior of your server side anti-cheat, at the cost of taking longer to ban cheaters. But again, that tradeoff is under your control.
- maccard 4y ago
  Every now and again I read things on HN about the area that I work in that reminds me that HN despite being confident doesn't always know what it's talking about. If it's so easy, can you share a prototype of someone doing it? Surely, if you can solve the entire problem of anticheat in one HN post there must be some proof to back it up. > Lag switching is only one kind of cheat that applies mainly to multiplayer FPS games, and as I said, it can be mitigated through statistical analysis <...> These methods are already in use with client side cheat detection. The thing about latency spikes is that there are many things that cause them. To use your example of checking when spikes appear near a kill in an FPs, presumably a kill is associated with a spike in traffic (multiple users shooting, extra movement, etc). So it's far more likely that you see spikes at the point of extra network traffic. Lag spikes wee also only one example. > With server side heuristics, you are in a better position to understand how it works and document it so that others on your team understand it as well You have control over all of these things with client side heuristics and cheat detection too don't forget. > Running the game in a virtual machine? Banned. Running the client in WINE on Linux? Banned. Driver signature enforcement disabled? Flagged. User running AutoHotKey or WinDbg or Ghidra? Flagged. New Windows update that breaks some internal NT kernel ABI that my anti-cheat rootkit was relying on? Firstly, the NT interface is probably the most stable of any software im aware of. I don't personally keep up with kernel breakages but my understanding of them is they're incredibly incredibly rare. They're also very well documented and published on a mostly expected cadence. If an anticheat isn't being kept up to date, it's ineffective, whether or not that's in relation to it's heuristics or its support for OS features. Secondly, there's a reason all of those things are suspicious. (And as an aside many games don't actually ban you for running them, they pop up and tell you to turn them off before killing the game . They _do_ ban if you bypass that check though). > causing issues for legitimate players whose setup might deviate slightly from the norm. Having ghidra or windgb running, or running via wine isn't "slightly" out of the norm, it's a statistical anomaly that would be flagged as "massive outlier" if heuristics were applied. Also, why is it ok for players whose software setup deviates from the norm, but not ok for players with outlying network setups? > You can make it more difficult by issuing ban waves at fixed intervals, and slightly varying the thresholds by some small random amount each time. So exactly the same methods in use right now?