Live data from Hacker News

Never trust the client

gafferongames.com

101–110 of 155 posts

Re: Never trust the client

#101

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

More modern anti-cheat software seem to have a trend to move to kernel space[1] and block user-mode access. So it's not just signature checking, but some generic attack prevention as well. (Cheats also move to kernel space, of course.)

Wonder how soon there will be a market of PCI-e cheat rigs for DMA attacks...

____

[1] Yep, gamers are literally accepting rootkits that allow arbitrary remote code execution on their machines.

Re: Never trust the client

#103
post #96

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

> If the client messes up the rendering, the only person affected is the client. No, just google "wallhack".

Arguably the client was trusted with information that was not needed.

Re: Never trust the client

#104
post #98
post #15

I doubt that the developer's didn't know not to trust the client - they likely made a business decision. I (used to a lot more) play Elite: Dangerous. A space sim that has multi-player. They made the decision to use (mostly) p2p/client networking to save money - they wouldn't need nearly as many servers. This has caused other issues in addition to cheating - a low limit on the number of players in the same "instance"…

Yea and I'll go out on a limb and say it was the correct one. The shelf life of a popular game like this is probably shorter than most people think so it makes sense to offer an amazing experience that you couldn't necessarily achieve with an authoritative server model and then by the time hackers have defeated the game players have probably moved on to the next.

Initial Release Date: March 8, 2016

Re: Never trust the client

#105

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...

What I'm trying to figure out isn't the business option where it's ok, but the business where you actively are avoiding doing it.

I mean why not just do it the right way?

Re: Never trust the client

#106

Earlier quoted context omitted.

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…

More modern anti-cheat software seem to have a trend to move to kernel space[1] and block user-mode access. So it's not just signature checking, but some generic attack prevention as well. (Cheats also move to kernel space, of course.) Wonder how soon there will be a market of PCI-e cheat rigs for DMA attacks... ____ [1] Yep, gamers are literally accepting rootkits that allow arbitrary remote code execution on their…

How does the server know you are running the anti-cheat software, and not your own fake?

(Alternatively, run game in VM? I guess performance would suffer too much with that approach?)

Re: Never trust the client

#107
post #103
post #96

Earlier quoted context omitted.

> If the client messes up the rendering, the only person affected is the client. No, just google "wallhack".

Arguably the client was trusted with information that was not needed.

Alas, performance trade-offs might make this mandatory.

Re: Never trust the client

#108

I'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,…

WoW has some mild checks against this stuff. In WotLK they triggered all the time if you jumped or turned on a corner of several polygons, and you'd get disconnected :(

Re: Never trust the client

#109
post #98
post #15

I doubt that the developer's didn't know not to trust the client - they likely made a business decision. I (used to a lot more) play Elite: Dangerous. A space sim that has multi-player. They made the decision to use (mostly) p2p/client networking to save money - they wouldn't need nearly as many servers. This has caused other issues in addition to cheating - a low limit on the number of players in the same "instance"…

Yea and I'll go out on a limb and say it was the correct one. The shelf life of a popular game like this is probably shorter than most people think so it makes sense to offer an amazing experience that you couldn't necessarily achieve with an authoritative server model and then by the time hackers have defeated the game players have probably moved on to the next.

Guaranteeing your multiplayer blockbuster game designed to have "infinite gameplay" will be dead in the water the instant hackers discover its highly flawed networking model doesn't sound like a "correct business decision".

Re: Never trust the client

#110

Earlier quoted context omitted.

I think you might be misunderstanding the scope of an "input". It's something like "the player pressed the key/button that maps to move forward", not "move to position X". Teleport hacks wouldn't be possible in the former case because the player has to actually move their avatar to the desired position by traversing the game world through a series of inputs. The server would then process the movement inputs, and the…

Is an input always valid? "Firing once" is an input: you have to validate that it's been long enough since last firing that you should act on it (limit the rate). "Moving left" is an input, but by how much? Can I send "Left, 9999999" and replicate a teleport hack by pre-calculating these inputs? You could bound the inputs to a simple stream of enums (FIRE, LEFT, RIGHT, etc.), but it wouldn't be crazy to batch it up a…

Another way to look at it: the game simulation runs in a certain number of frames per second. Each frame you send to the server the state of your input devices (holding left arrow key, left mouse button is clicked, etc) and this is translated to moving, firing weapons, etc according to the rules of the game.

You can't teleport hack by sending "left 9999" because your inputs only serve to tell the server what direction you want to move towards. Your maximum movement speed depends on the game rules and should not be under your control.

Post reply on HN