Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never trust the client

gafferongames.com

Post reply on HN
Print view View original

131–140 of 155 posts

Re: Never trust the client

#131

Post by chris_wot »

bcook wrote: post #127
ultramancool wrote: post #119

Earlier quoted context omitted.

The solution is simple: do everything server side. Look at World of Tanks for a great example of this. They pretty much let people run free with mods in multiplayer and even the worst of those mods can barely provide an advantage in online play. They do this by managing absolutely everything server side. Ammo, direction of aim, position, enemy players appearing and disappearing etc. Basically your server should be bu…

World of Tanks is exponentially less reliant on latency than an FPS, right? Honestly, I immediately smell naivete BS when someone says "the solution is simple"...

It might be naive, but then again I don't think games development has ever been easy. I'm constantly amazed by the skills of games devs, they just seem to surpass anything done for business applications.

If a company wants to attract competitive gamers, then they have to develop games you can't cheat in during competitions. Right now, the most reliable way of doing so is server side, with all the challenges that entails. Otherwise, they have to install what essentially amounts to rootkits - which isn't exactly what most gamers want to encourage.

Re: Never trust the client

#132

Post by h_ar »

awalton wrote: post #11

Console port gone horribly wrong? I mean, how else do you violate the most simple of game rules - never trust the client?

Actually, after extraction of data files, it points out that it is likely a PC port to console instead of the usual console port way.

Re: Never trust the client

#133

Post by Kristine1975 »

MBCook wrote: post #7

Since this is a multi-player game this is obviously a big problem but I've always wondered how you'd handle this in a single player game with a leaderboard. Let's say you have a Bejeweled clone/match-3 game and a global high score board. What can you do to prevent fake scores? You can obviously obfuscate things, sign requests, etc but at some point the client needs to sign the score it's sending up so the client has…

Build a community that's honestly interested in skill and frowns on cheating. Then trust that community to detect and flag the (hopefully very few) cheaters. An example would be Dustforce.

Of course this only works with the right community.

Essentially a social instead of a technical solution.

Re: Never trust the client

#134

Post by golergka »

andyburke wrote: post #95
golergka wrote: post #80

Earlier quoted context omitted.

Not every. Right now I'm working on an app where we trust the client. We know that a hacker can compromise a client and send any kind of bogus data, we're just completely OK with it from business perspective.

Can you give any more insight into this product? Curious what kind of product would have that be ok from a business perspective...

Eye training app with server creating parameters of the next training session (based on the whole training history and some data analysis magic). If you want to get a training seasion that doesn't fir your real results — go ahead, we don't care.

Re: Never trust the client

#135

Post by hinkley »

lobotryas wrote: post #52
heartbreak wrote: post #49

Earlier quoted context omitted.

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.

They could, but they can't falsify the game seed - the server determined order for what gems spawn when. This way I can send actions (whether real or hacked) that would be executed in the server against the "real game". If the client's move did not result in a score then no score is recorded, even if the client thinks it should.

But it would mean a bot could get the highest possible score for that seed by going back in time and trying again.

Re: Never trust the client

#136

Post by kybernetikos »

xenadu02 wrote: post #12

"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…

> "Never trust the client" is good advice for every kind of application. Clients are filthy liars.

It's true that you can't trust clients not to lie. However, in some situations, it's the correct decision to accept a constrained number of lies if that brings you benefits.

Like so many other absolute statements in software, in reality it's a trade off, and you need to consider the business context to make the right decision.

Re: Never trust the client

#137

Post by majewsky »

One can easily observe this "server is the actual game" property in Minecraft when running on an underpowered server.

At home, Minecraft runs on my home server (with a small Athlon CPU) and it fails to keep up with the required speed of the game, so the server log will show messages like "server clock running behind, skipping 58 ticks" every so often.

An observable effect of this is that you have to hold the right mouse button just a little bit longer than the actual animation when eating stuff. And when you look at the sun, you will see it moving forward continuously (as calculated by the client), but skipping back a tiny bit every few seconds (when the client adjusts for the server's time drift).

Re: Never trust the client

#138

Post by maccard »

greenail wrote: post #34
amelius wrote: post #24

Earlier quoted context omitted.

Perhaps you can solve this as follows. The client is going to go through a series of states, guided by some inputs. You can compute a hash from these states. Now you let the server go through the same states (using the same inputs), and compute the hash, and compare the hash codes from server and client. This sounds prohibitively complicated (and requires work from the server). But note that the state can be a partia…

from my recollections forever ago, RTS games like the spring engine use checksums on state to prevent manipulation. the game client gets "out of sync" if a client's checksum doesn't match. The state checksum is computed at every tick of the simulation. This makes it so you don't have to run the simulation on the server. Debugging is very hard though, and odd things like FPU precision on different processors can creat…

Those fpu precision issues are a nightmare. The most common way to get Around them is to do integer math instead.

One thing that makes this possible is that many of those games run st much slower update rates (typical games are 30/60hz, many rts games run at 10hz) and they run in lock step. If you have different clients with slightly different views of the world it doesn't work at all

Re: Never trust the client

#139

Post by exDM69 »

ultramancool wrote: post #119
smelendez wrote: post #114

Earlier quoted context omitted.

> Yep, gamers are literally accepting rootkits that allow arbitrary remote code execution on their machines. That's certainly risky and rather horrible, but what's the alternative? Multiplayer games are a huge business and a huge culture, and all that goes down the drain if people cheat. Game companies have millions of people around the world competing for prestige and money. They're running game software on their ow…

The solution is simple: do everything server side. Look at World of Tanks for a great example of this. They pretty much let people run free with mods in multiplayer and even the worst of those mods can barely provide an advantage in online play. They do this by managing absolutely everything server side. Ammo, direction of aim, position, enemy players appearing and disappearing etc. Basically your server should be bu…

Doing everything server-side is not enough to prevent cheating. There are plenty of client-side tricks that can give the player an advantage, starting from simple visual cheats.

E.g. turn the opponent's textures bright purple so you can see them better. Make the walls transparent. Aimbots that spoof mouse input.

The server must be authoritative or all bets are off, but you still do need client side anti-cheat countermeasures (stuff like verifying screenshots).

This stuff can't be made 100% fool proof, so competitive games where big bucks are at stake must still take place with the organizers providing the hardware and the players located in the same room.

Re: Never trust the client

#140

Post by amelius »

maccard wrote: post #138
greenail wrote: post #34

Earlier quoted context omitted.

from my recollections forever ago, RTS games like the spring engine use checksums on state to prevent manipulation. the game client gets "out of sync" if a client's checksum doesn't match. The state checksum is computed at every tick of the simulation. This makes it so you don't have to run the simulation on the server. Debugging is very hard though, and odd things like FPU precision on different processors can creat…

Those fpu precision issues are a nightmare. The most common way to get Around them is to do integer math instead. One thing that makes this possible is that many of those games run st much slower update rates (typical games are 30/60hz, many rts games run at 10hz) and they run in lock step. If you have different clients with slightly different views of the world it doesn't work at all

I thought that IEEE floating point operations were well-defined, and guaranteed to always behave in the same way (but there are a few CPU flags that can influence e.g. rounding).
Post reply on HN