If you don't know this you should not be working on software. It's a latent risk to customers.
It's a video game, not a life critical system.
Never trust the client
61–70 of 155 posts
Re: Never trust the client
#62I'm still constantly shocked at how many games do this. In the MMOG world it is really easy to do everything right, UO came out in 1997 and the devs outright told everyone working on similar games "never trust the client" and "the client is in the hands of the enemy". Yet games like FFXI and WOW that came out many years later have the client setting the position of the player and the server just blindly accepting it,…
UO had rubberbanding rampant - that is, you'd move on the client, then warp back to an old position after the server said you actually didnt move there.
It was terrible.
Most all MMOs with WSDA movement trust the client to set the player's position and it mostly works. Cheating through warping or speed is easily detectable through other means of post-verification and banning players that fail that verification. It makes the game feel more fluid to the player while still not really allowing cheating.
Everything else is generally handled serverside which is fine because it mostly doesn't need as high a reaction time as movement to feel natural.
If speed/warp hacks are a problem, it's not because the developers that use client-set-movement aren't able to fix it, it's because they don't care.
Re: Never trust the client
#63Does anyone have a mirror for the "this is super bad" video?
Do you refer to the netcode analysis?
https://www.youtube.com/watch?v=oc51gxwvyGc
Or the clientside thrust problem?
Re: Never trust the client
#64Earlier quoted context omitted.
If you have a deterministic game model(RNG seeded properly, pure functions, etc) you can actually just send the user inputs(which are very small compared to the whole game state) and replay the whole game to verify. This is the common model in RTS games called Lock Step since all clients are advancing a number of frames based on all inputs from other clients in "lock step". It's also very common way to implement repl…
Using the Bejeweled example of a single-player game, and assuming it's properly deterministic, could a malicious actor not just falsify the steps taken as well as the score? It would be more difficult, but not that much more difficult considering the challenge is the time limit and lack of undo. Both would be removed if you were simulating steps.
If you don't care about overkill, you could employ machine learning and anormaly detection: send the input sequences, timing and other difficult to fake data (e.g. gyroscope state) to the server and learn the "typical" distribution of those values. A perfect game played by a robot will likely be an outlier in a lot of the values.
(Note that some legit games will also look suspicious, so you'd want to use this to find out which players you should keep an eye on, not as a tool for auto-banning.)
Re: Never trust the client
#65Earlier quoted context omitted.
The irony is that the console versions are the least-impacted, as the client-side hacks are only loadable on the PC version.
Walton's phrasing is kind of ambiguous, Console port could mean port from console or port to console. It could have been developed for console first.
"Console port" in the gaming world unambiguously means "a game that was originally developed for a console, then ported to the PC." The opposite would be "PC port."
Re: Never trust the client
#66Console port gone horribly wrong? I mean, how else do you violate the most simple of game rules - never trust the client?
Generally these days it isn't a port per-se it's simply one codebase compiled for different platforms. So I'm sure they just take the stance of 'this always worked on the console (where it's much harder to run modified code)'.
Re: Never trust the client
#67Earlier quoted context omitted.
With caveats. What you're also implying is that clients should do no processing - because clients can't be trusted to do anything. If you apply this logic to web-browsing, you're asking the server to send the client a bitmap image of what the rendered page should look like.
I think that is misinterpreting what the person you are replying to is saying. They aren't saying "don't let the clients do anything", they are saying "don't trust the values the clients send back" If the client messes up the rendering, the only person affected is the client. There is no 'trust' required, because you are not relying on anything the client has done. The idea of trust only comes into play if there is a…
Exactly. The nuance of every discussion is critical.
When somebody says "Never trust the client" inevitably somebody will find a use case that sounds like trust even though it's not what they're saying here and use that as justification.
The lack of nuance is how things like "never use stored procedures" gain traction when they shouldn't.
Re: Never trust the client
#68"Never trust the client" is good advice for every kind of application. Clients are filthy liars. Clients have bugs. Old clients don't upgrade. Packets arrive out of order. ACKs never make it to clients, causing clients to repeat what the client believes to be a failed operation. All of this is before even considering an attacker actively trying to subvert you. The server should always be the source of truth. It shoul…
I saw a talk where a guy was showing how to cheat at some games. A lot of games will detect and crash you out if they detect a debugger attached to them. Things like Punk Buster, et. al. are more like anti-virus software: they try to find the signatures of known chat clients. So it's best to write you own...and rename your debugging process to "Google Chrome." He got pretty far with his auto-walker in some MMOs. He h…
Don't forget the incident where Punk Buster banned anyone with a certain string in memory...
Re: Never trust the client
#69I think there's a false dichotomy here. You can't simply ignore the client, so no matter what, you have to have a set of server-side checks that ensure the client's inputs are valid.
Part of what this article offers is "you can't fix it by adding server-side checks", guessing that if they haven't done it already, it's impossible to do. I think it's entirely possible that their model is reasonable (takes movement, fire events, etc. instead of position, inventory, etc.), and they simply haven't guarded against malicious inputs. Adding server-side checks is _exactly_ what you need to do to make movement/firing inputs safe!
The existence of a certain class of bug doesn't mean the whole architecture is broken. It may simply mean they shipped the game without trying to detect cheaters. That may be a bad idea, but if the design is right, it's certainly fixable.
Re: Never trust the client
#70Earlier quoted context omitted.
I think that is misinterpreting what the person you are replying to is saying. They aren't saying "don't let the clients do anything", they are saying "don't trust the values the clients send back" If the client messes up the rendering, the only person affected is the client. There is no 'trust' required, because you are not relying on anything the client has done. The idea of trust only comes into play if there is a…
Well, a bank website would want to use this to make sure nobody MITMs them, or that the client does not have malware, etc - which would affect the user.
MITM isn't really relevant for the purposes of this discussion. We're talking about a different application with different threat models.