←back to thread

379 points mobeigi | 3 comments | | HN request time: 0s | source
Show context
snarfy ◴[] No.41862807[source]
For UT2004, you can ban by player GUID (a hash of the CD key) or IP. With the game abandoned by Epic, a number of key generators have cropped up, which makes GUID bans useless. IP bans only go so far with VPNs costing $2 these days.

The main solutions we have today are IP ban + VPN blocking using a database of known VPN subnets and adding them all to the firewall, and a similar fingerprinting technique which scans their folder structure of certain system folders.

replies(12): >>41862963 #>>41863123 #>>41863371 #>>41864302 #>>41864313 #>>41864340 #>>41864577 #>>41865500 #>>41865762 #>>41866999 #>>41867262 #>>41885146 #
project2501a ◴[] No.41864340[source]
sorry for the not-so-smart question.

the cheats are software, software has certain quirks, like the way it aims or the way it tracks. And I'm willing to bet it has enough distinctiveness from human aiming to be classified. Couldn't a classifier work on the behavior of the cheating software itself, rather than use IP bans?

replies(4): >>41864387 #>>41864451 #>>41864518 #>>41865760 #
derefr ◴[] No.41864518[source]
In order to actually catch a cheater mid-match rather than long after the match is already over, you'd need the servers that players are interacting through to have enough CPU grunt-force to do that kind of analysis "faster than realtime" — i.e. for the server's CPU to be able to run the game's physics faster than any client can, so it can run the physics with extra math in the same time it takes the clients to just run the physics.

Which might be something you could guarantee, if the game were locked to wimpy console hardware; or if the game had minimal CPU physics such that it was effectively never running CPU-bottlenecked and there were massive gaps in frame-time where even the client CPUs are sitting idle, that a server running in lockstep could cram that kind of analysis into.

But gaming is a race-to-the-top, hardware-wise. The CPU in a gaming rig might not have as many cores as your average server CPU, but it's almost certainly going to have higher single-core perf.

And part of the reason for that, is that games really do try to use your whole CPU (and GPU), with AAA studios especially being factories for constant innovation in new ways to make even the minimum requirements just to run a game's physics, higher and higher every year.

And if the server can't do "faster than realtime" analysis of the streams of inputs of the players, then by queuing theory, it'll inevitably get infinitely backlogged — the server will keep receiving new analysis work to do every timestep, and will fall further and further behind, never catching up until new work stops being generated — i.e. until the match is over. And then it'll have to probably sit there for five more minutes thinking really hard before spitting out a "hey, wait just a minute..." about any given match.

Which is fine if there's a big central lobby server that the game is forced to connect to, and your goal is to ensure that some central statistic that that central server relies upon (e.g. match-rank ELO) gets calculated correctly, such that cheaters are prevented from climbing the leaderboards / winning their way into high-ranked play. (And that's exactly the situation the big eSports games companies are in.)

But in the context of older games that use arbitrary hosted servers and random-pairing (or manual lobby-based match selection) — or in modern, but "dead", games, that only persist due to being modded to accept private servers — this "after-the-fact" punishment is useless, as most servers have no incentive to do this analysis, especially when cheaters can just hop around between servers. So there's nothing preventing people from being matched with cheaters, sometimes over and over again, if the cheaters can just tell their clients to roll up with a new key+IP for every match.

...and that's assuming there even are servers. You can forget about any of this working in a p2p context. (Think about what a Sybil attack means in the context of a federated set of individual tiny disconnected p2p networks.)

replies(4): >>41864782 #>>41865005 #>>41865108 #>>41866506 #
1. IPTN ◴[] No.41865005[source]
You should be able to limit analysis for this type of detection to only the input leading up to a kill/hit and ignoring everything else. The majority of the time players are not shooting could be used to do the analysis with plenty of time to boot midway in a round let alone a full game.

Also simple analysis of only the input streams as you stated really doesn't have to do with the phys rate of the game server and should be alot cheaper computationally. It can be offloaded to another process even if it was found to be too impactful to run alongside the game server directly. Something all those extra cores might be good for.

replies(1): >>41865607 #
2. Xss3 ◴[] No.41865607[source]
Cheats nowadays can and do

a) run on 2nd pc passively capturing the screen and commands to a fake mouse device plugged into both machines,

b) "humanise" the aim with ai models trained on professional players

c) add random variances within the limits of human reaction times

So it doesn't solve things, really it'd still be playing catchup.

replies(1): >>41866988 #
3. IPTN ◴[] No.41866988[source]
And I'm not refuting that. I was just pointing out a solution to a problem the GP proposed as intractable when trying to analyze player input data streams for cheating. The points you made are valid as far as the evolution of this cat and mouse game is progressing (probably still closer to the end end of can then do for now).

That being said, the vast majority of cheats are not that sophisticated. "Simple" analysis of player input should still be used to make low effort cheats less or ineffective. Especially if used to compare consistency of mechanical play by a player. I doubt most cheaters want to just turn on a full bot that plays by itself for the whole game. You can build a model of play customized for an individual player to look for changes in mechanical skill during critical plays. Then even if that was incorporated into the cheat client so that its 'actions' can't be definitevly detected against the players baseline, it would at least be limited to cheating as that player always playing like it's their best day. Either that or the cheater would have to go fully hands off for that account which I imagine is not as appealing for most cheaters.

Input analysis, even much simpleler approaches, can still be a valuable tool to make cheating more difficult and less opportunistic. The goal would be to raise the barrier of entry to cheating without immediately getting banned beyond downloading and running a client. If people who consider cheating in a game have to: order, wait for, and setup additional hardware then aquire models trained for the latest version of the game that are also trained on pro play in a way that lets the cheating be humanly plausible to remain undetected; it will reduce the total number of people who cheat in that title. Will needing to aquire additional hardware stop all cheating? No, I had a friend as a kid that owned a GameShark that I used and ended up corrupting the save on one of my Pokemon games. But if all of that is what is required to be able to successfully and consistently cheat, it will raise both the cost of development of cheats as well as their price to cheaters.

For top level professional play, in person tournaments on managed setups will remain the gold standard for the forseeable future (and besides they are attractive as events for their own sake). And for the rest of us, we will continue to be trapped in the labyrinth with both the cat and the mice.