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

71–80 of 155 posts

Re: Never trust the client

#71

Post by turaw »

vvanders wrote: post #38
turaw wrote: post #31

Earlier quoted context omitted.

Recording and playing back input events, at least, shouldn't be that expensive unless you're emulating the entire stack up to the application. If the logic is written in some portable manner (Xamarin [1], etc.) you could just re-execute on the server with the same logic as the client. It requires a fair amount of discipline to keep everything deterministic, too. The real difficulty would be identifying the AI players…

Ah shoot, you beat me to it by 5 minutes :). Yeah, that's how you do it in practice.

Gah, sorry about that :/ fwiw, it looks like your explanation has more upvotes, so it worked out alright! :)

Re: Never trust the client

#72

Post by primigenus »

The server-side network model he describes here is the same architecture Meteor is designed with (see this page: https://www.meteor.com/why-meteor/features). With Meteor, you get client side prediction and latency compensation (they call it "optimistic UI" now) for free. I've always been impressed they decided to build that, because I sure never would have myself. In fact the Meteor team has always said you need this kind of architecture in order to build true real-time applications. But I haven't seen other web-oriented platforms take a similar approach. Did the Meteor team just know something no one else has picked up on (despite it apparently being common practice in the games industry)? What gives?

Re: Never trust the client

#73

Post by kcbanner »

trjordan wrote: post #69

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

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 avatar would say, bump into a wall, preventing it's movement. There would be no input for "my position is now X".

Re: Never trust the client

#74

Post by kaoD »

Cyph0n wrote: post #58
djsumdog wrote: post #54

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…

I'm really interested in game hacking. Do you have a link for the video/talk?

I used to visit Game Deception, the best game hacking technical forum. Unfortunately it closed.

I lost interest in game RE a long time ago, but http://www.unknowncheats.me/ seems to be its successor, though from a cursory glance I see there are a lot more cheats and less technical information.

GD we miss you.

Re: Never trust the client

#75

Post by vvanders »

turaw wrote: post #71
vvanders wrote: post #38

Earlier quoted context omitted.

Ah shoot, you beat me to it by 5 minutes :). Yeah, that's how you do it in practice.

Gah, sorry about that :/ fwiw, it looks like your explanation has more upvotes, so it worked out alright! :)

Nah, not an issue at all :).

FWIW it's a fun domain space, partially these cool technical approaches(lock-step, dead-reckoning) and partially smart user interactions(how you decide to give users immediate feedback when you won't actually know until 100-800ms later).

Re: Never trust the client

#76

Post by TillE »

throwaway13337 wrote: post #62
MustardTiger wrote: post #6

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

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

Movement in UO worked ok most of the time, and that was with clients on 56k modems and servers powered by hamster wheels.

> it's because they don't care

That'd be nearly every company running an MMO then. You're quite right in principle: speed hacks and teleportation should be extremely easy to find by doing basic sanity checks every now and then. But in practice these things go on for months and months.

Re: Never trust the client

#77

Post by emerongi »

primigenus wrote: post #72

The server-side network model he describes here is the same architecture Meteor is designed with (see this page: https://www.meteor.com/why-meteor/features ). With Meteor, you get client side prediction and latency compensation (they call it "optimistic UI" now) for free. I've always been impressed they decided to build that, because I sure never would have myself. In fact the Meteor team has always said you need thi…

Even though I don't use Meteor anymore, I still like DDP[1] a lot. It's simple (can be implemented in 50-100 lines), but it is the core of Meteor. There's a specification for it in their Github repo. Meteor's "optimistic UI" is basically an abstraction on top DDP, IMO.

[1] https://www.meteor.com/ddp

Re: Never trust the client

#78

Post by trjordan »

kcbanner wrote: post #73
trjordan wrote: post #69

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

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 little bit and send some magnitude data as well (FIRE 2, LEFT 50, etc.). It's a little harder to validate, but depending on the specifics of implementation, that could be a win.

Re: Never trust the client

#79

Post by throwaway13337 »

TillE wrote: post #76
throwaway13337 wrote: post #62

Earlier quoted context omitted.

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

Movement in UO worked ok most of the time, and that was with clients on 56k modems and servers powered by hamster wheels. > it's because they don't care That'd be nearly every company running an MMO then. You're quite right in principle: speed hacks and teleportation should be extremely easy to find by doing basic sanity checks every now and then. But in practice these things go on for months and months.

Yes, it's true that they don't care. I know this from experience as one of 'they'. It's I guess oversimplified that we don't care. It's just that I, as a developer, would not be able to justify allotted time to fixing hacks that don't hurt the game much until they do.

Re: Never trust the client

#80

Post by golergka »

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…

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.

Post reply on HN