This is a hill I'm willing to die on: Failure to do proper server side checking is carelessness in the face of making a quick buck.
I distinctly remember being a kid bypassing this type of software back when it was just Game Guard at the top. There's nothing that's going to stop kids from doing it today.
It's an arms race doomed to failure until these game devs stop being lazy and just put in the sweat required to get their houses in order.
Server side checks. That's it. User input is tainted evil and you can't trust it. Anything less than server side checking is insecure.
This is the question that anti-cheat conveniently dodges.
The real problem is that "cheating" is practically undefinable. What players really need is moderation. There is no relevant difference, from a player's perspective, between playing against a cheater or playing against a legitimately skilled person. If someone is not fun to play with, then that needs to be managed somehow.
The most effective strategy is for players to moderate the servers they play on. This has recently become impossible, because game studios have chosen to monopolize server hosting while also abdicating the responsibility of moderation. Anti-cheat is nothing more than a lazy implementation of automated moderation.
There's a reason that Battlefield 4 is still going strong, while Battlefield One (which came out just after 4) is unplayable. That reason is player-hosted servers.
Moderation is a fine suggestion. This idea could actually be implemented in such a way that other player clients do detection and reporting behind the scenes. Suppose a ton of clients see one user violating rules of the physics engine. Automated reporting on that can be observed as a trend and a ban would make sense.
Having argued about this specific topic in the past, I agree that going so far as to do checks on player movement is difficult and even expensive if you're validating physics for every user.
What concerns me more is the increased risk of RCEs when developers skip fundamental security practices because "the anti-cheat handles it" for them.
My dude, we are at the point where AI's are trained on images resembling the enemy player (you know the ones appearing on your screen, good luck not showing those) and a little programme rolls a mouse around and clicks heads.
We ONLY have this problem BECAUSE the game publishers want to OWN the server infrastructure themselves.
In the old days you had dedicated servers where one of the players, at least, had full control over that server. Any sus behaviour would be met with rods from god right into the cheater's home router location. I'm being really theatrical here but really this worked, and was sustainable. Mods were able to fight the criminals in their small servers. A distributed cyber police if you will.
Today, we rely on a singular company (the one who published or developed the game) to be able to automagically pinpoint sus behaviour across a million servers and NOT have collaterals.
We had the perfect scheme to handle them, we have just lost to greed. No amount of client or server side shenanigans will ever be enough to fight cheaters. You need actual humans in there.
Genuine question, why are people confused on what user input is here?
Suppose the game is a solo game primarily with additional multiplayer features. The agreement there is simply that they enter multiplayer with a valid game state (edit: you validate on join).
Upon entering multiplayer, monitoring begins. Player moves, is it valid? Player shoots gun. Is this valid? Ray cast reached target and does damage. Was that valid?
Did you track the player state during the replication streaming? If no, then there are user input validation gaps.
To be completely fair, most people aren't out writing their own game engine to account for this stuff and it's a lot of work to do that. None of the major game engines on the market do this.
In large database systems, log replication occurs all over the place and validation takes place (some systems better than others for sure). Difficult to implement, sure, but when you know, track, and monitor the state; you can validate and respond.
The problem isn't whether or not it's valid. It is whether or not it is a human doing it, or an aimbot. This isn't unique to games, websites/browsers do the same thing: scraper and other bots all give valid inputs, but not always human ones. That's why captchas exist, and those only detect "only-bots", not a bot assisted by a human or vice-versa.
> Ray cast reached target and does damage. Was that valid?
This one is very hard to replicate because of latency. By the time I see and shoot at an opponent at position A, on the server the opponent will be at position B. And on the opponent's computer, position C. In the time it takes for my packet to reach the server, the opponent is now at position D.
So my "shoot gun" network message not only has to include my current timestamp, but also my current position of the opponent. Because of latency, my opponent's position on my client wouldn't even be the last packet I got (A-1), but rather A-1 interpolated based on how long it took for the packet to reach my client. You have to trust the client on what it thinks is a valid position for the opponent, because no one wants to play a game where you can't hit the opponent. This leeway gives you a lot of room to fudge inputs.
These differing game states also leads to peaker's advantage in games.
Everything other than the isHuman part is absolutely detectable. It's just a matter of building a system for it.
The ability to detect isHuman just seems to be on chopping block as far as I can tell. There is little to no barrier remaining today to prevent people from leveraging AI to get around this entire problem. There's a few outlier solutions that work for now, but AI does two things really well given time: solving classification and regression problems.
What can still be done is maintaining short lived replication logs and pattern analysis in this space. There is no reason that a player's actions can't be logged, analyzed, and responded to. It doesn't even need to be real time, it can just be latent. The server doesn't need to rely on reported timestamps for the analysis part, because the server can use it's own timestamping upon arrival to at least see how far apart the order of operations occur.
I know it's not an easy problem space to be in, I don't envy it, but I can't agree with the sentiment that it's impossible knowing how these systems are already designed in larger engines.
> the server can use it's own timestamping upon arrival to at least see how far apart the order of operations occur.
The server's timestamp isn't going to be representative of the user's actual input when you're using UDP. Especially over consumer wifi which is hardly the most consistent network, but is still used by a majority.
It sure doesn't. Any reason you couldn't just slap a TCP connection on top of it to make your replication log for analysis though?
As I mentioned in my last comment, someone would need to design a system to better deal with this type of stuff. The way things are stem from decades of decisions made, starting with more design constraints than we have today.
TCP still doesn't solve timing of packets not matching the timing of the inputs because of jitter, retransmission, and other overheads. You would still have to rely on user client reported timestamps to tell how far apart actions are taking place.
Seems like a non issue to me, time is just relative. Analysis on receipt is still possible, because you can calculate latency.
I'd recommend checking out Leslie Lamport's work, you can probably derive some ideas. I'm not be prescriptive here because this isn't a space I plan to work in to solve problems since it's just games. Entertainment isn't really my thing, I tend to lean heavily into systems and security knowledge which has served me well broadly.
>Server side checks. That's it. User input is tainted evil and you can't trust it. Anything less than server side checking is insecure.
Cool. Noone will play your game. Every single thing that makes a game feel not even just good, but playable, like basic prediction no longer works. Peeker's advantage gets multiplied tenfold. Players with high sensitivity get rolled back because you decided that their .1s flick was not right.
And the funniest of all that ? The cheaters that are just sending mouse & keyboard events still get to play, because they can pretend to play exactly like you want them to.
>I distinctly remember being a kid bypassing this type of software back when it was just Game Guard at the top. There's nothing that's going to stop kids from doing it today.
With none of the respect: ok grandpa, time to get you a chamomile and time to go to bed. It's not kids pulling out cheat engine, it's physical hardware that does DMA with $100/month subscriptions. The most basic, not-even-officially-considered-a-cheat piece of hardware is something like a Cronus, that does recoil control and scripting, on console. That's not a rare piece of equipment: a large part of the higher ranked players are using one or similar. That's the _basic_ cheating device now. Nobody is talking about shitty spinbots.
EDIT: editing to not fall into a deep thread with you whining:
>you resign to insults
no, I called you old because you're referring to an anti cheat that runs on Rappelz and MapleStory (and that is notoriously known for being terrible). The only way it could have been more telling would have been referring to WON or QuakeWorld.
>can't because you lack the skills required.
sorry, who's doing insults ?
I've enumerated a short list as to why it doesn't work. But if you want more: here: nothing on that article works any more with server side verification of everything: https://developer.valvesoftware.com/wiki/Source_Multiplayer_.... Rollback ? Lagcomp ? Basic hitreg? Nope, broken, because you just wanted to verify everything server side instead of assuming a set of known good information. You don't acknowledge either _what_ you verify server side. I'll give a quick little hint: it's because there's nothing useful you can verify. The basic stuff is already verified: player state is kept in sync, and you can't say that you have 300 bullets in your 20 bullets magazine.
Trusting the client is necessary, because even a 10ms ping means that you're a frame behind, and nobody will play that.
> Trusting the client is necessary, because even a 10ms ping means that you're a frame behind, and nobody will play that.
Your entire argument against this being a possibility falls apart when you realize the simple fact that full 100% server side verification does not actually need to happen in real time, only close to real time.
Does it really matter that a server takes 10 minutes to realize something was invalid if the cheater gets caught and banned in the end? You can easily load the bulk of this processing to inbetween ingame rounds when they server is already not processing real time events or offload it to another server if it's still too intensive.
> ok grandpa, time to get you a chamomile and time to go to bed
So you resign to insults because you're either incompetent in code or think you know something I don't. You would be better served to make a case for a counter argument, but can't because you lack the skills required.
Edit: Good developers figure out how to make better code, while some developers are just doomed to mediocrity. ¯\_(ツ)_/¯
I distinctly remember being a kid bypassing this type of software back when it was just Game Guard at the top. There's nothing that's going to stop kids from doing it today.
It's an arms race doomed to failure until these game devs stop being lazy and just put in the sweat required to get their houses in order.
Server side checks. That's it. User input is tainted evil and you can't trust it. Anything less than server side checking is insecure.