36

In video games, most anticheat software is run clientside (e.g. PunkBuster or Valve Anti-Cheat)- but isn't one of the first rules of security to never trust the client? If so, then why do these companies not offer server side verification for video games, but rather continue to insist on trusting the client?

user189790
  • 463
  • 1
  • 4
  • 6
  • 21
    How do you detect wallhack serverside? – Agent_L Feb 22 '16 at 12:30
  • 21
    Why assume there's no server side validation? – Kos Feb 22 '16 at 15:37
  • 7
    @Agent_L : By not sending any information to the client that the wallhack would be able to use. Imagine if you ran absolutely NO game code on client, eg, client sends input directly to server, server renders the scene server-side and send a MPEG stream of the game to client. Then it would be impossible to cheat. – sebastian nielsen Feb 22 '16 at 16:14
  • 4
    @sebastiannielsen that way, server (and client- I can't stream 480p on super-fast (.s) Turkish internet) requirements will go way higher. – ave Feb 22 '16 at 17:51
  • @sebastiannielsen that's how for example Sony's Playstation Now -service works. They bought OnLive which had pc games playable streamed over the network. It worked surprisingly well, totally playable with full graphics. – Kimmo Lehto Feb 22 '16 at 18:25
  • 4
    There's also the latency issue. Here in New Zealand, your ping time to just about anywhere will be around 300ms. Have fun playing any fast-paced shooter with 300ms of input lag. (300ms of lag with client-side rendering can be quite playable, depending on the game's lag compensation algorithms) – user253751 Feb 22 '16 at 21:26
  • Also note that some games (e.g. Source-based ones) *do* try to only send the client information about other players they can see, but it's not perfect. – user253751 Feb 22 '16 at 21:28
  • @immibis CS:GO specifically recently implemented a type of anti-wallhack that does something with line-of-sight. There were many, *many* implementation bugs at first (especially with sound) and even now we have cases of people failing to appear, or appearing to 'teleport' on-screen. SMAC is another implementation with similar issues. A competitive shooter is not fun when people start teleporting around corners. – Bob Feb 23 '16 at 00:28
  • The real issue is that VAC is trying to find VALID input that was made by either a computer, or a computer assisted human. The server has already VALIDATED the input. You are misapplying the quote. – Aron Feb 23 '16 at 06:26
  • @sebastiannielsen. OK. I misworded my question. It should be: "How do you **practically** detect wallhack serverside?". Remember that we're talking about pro-level gaming, where 60Hz refresh is too slow to be acceptable. – Agent_L Feb 23 '16 at 08:39
  • `where 60Hz refresh is imagined to be too slow to be acceptable` – Vegard Feb 23 '16 at 14:03
  • Clients can be, to a certain extent, trusted in **consensus**. Also, if they didn't at least *try* to secure the clients, you'd see so much more hacking and cheating and would be asking the opposite of this question. – earthmeLon Feb 23 '16 at 18:05
  • Anti-Cheating technology doesn't search for random stuff you do. It searches for predefined variables that could be used for cheating ( Health, speed, etc ), and if they go over a limit, then the system would go into effect. This does not apply for all anti-cheating systems, but most on them rely on it. – Xavier Feb 23 '16 at 02:27

9 Answers9

47

If so, then why do these companies not offer server side verification for video games, but rather continue to insist on trusting the client?

It's less about insisting on trusting the client and more that there is no other viable anti-cheat model. Like DRM, and in fact, anti-cheat software like PB use a form of DRM, there's little that can be done.

DRM software has mitigations in place to keep the client from poking too much, but it has to be put on the client to try to prevent the client from doing things that the media companies don't want the client doing.

Anti-cheat technology relies on similar methodology. Information about the client is gathered, sent to the server, and if a client is seen as misbehaving, through whatever series of checks are done for the specific software, it can be banned at the server.

At the end of the day, it comes down to risk management. Yes, don't trust the client is one of the first tenets of security. But for mitigating risks that occur at the client, there's a cost-benefit analysis, which is what risk management is. Is the cost of letting clients continue to bot and cheat worth losing customers who want a fair and fun game? Or should some mitigations be put in to place? PB and other software packages aren't there to entirely stop cheating, but aim to make it more expensive to cheat.

Also there is another more subtle way of limiting the clients to cheat (wall hacks,...), mostly implicated by online only games but not limited to. This is achieved by not feeding the client side all data. For example unreal engine 3 has checks if an actor is in your vicinity of visibility, if this check is positive, the server sends YOU the exact location as well as your opponent YOURS. So to say, only the server knows all positions, actions and movements of all actors on the gaming instance.

This can be read in the documentation of the unreal engine 3 / Client Server Model in the paragraph cheating, to be found here: https://udn.epicgames.com/Three/ClientServerModel.html

So to say, with advanced engines/network code and Client Server models, it is not necessarily needed to trust the client 100%. The Server can decide beforehand what the client should know, effectively LIMITING the possibilities of hacks. To go even further, the server can decide what it SHOULD know itself, not to get distracted or confused by clients sending forged packets.

JSD
  • 3
  • 1
h4ckNinja
  • 3,006
  • 15
  • 24
  • 2
    Cheating CAN be prevented by doing everything on server, including rendering. If you would make the game so the player sends input to the server, server runs ALL game code and renders the scene on server-side, and then sends a MPEG stream back to client, then its basically impossible to cheat. Yes, you could propably create a playing bot, but that bot would face the same problem as decoding captchas, because the objects on-screen would not have any metadata, it would simply bne a flat MPEG frame picture. – sebastian nielsen Feb 22 '16 at 16:18
  • 5
    @sebastiannielsen My guess is that your approach falls outside of the set of "viable" approaches. That requires a lot more processing power for the gaming service (it must now run every single client, in addition to the server). Valve has decided, I guess, that it's easier to write anti-cheat code and tolerate some cheating than to supply the extra processing power to run the game client for every single player simultaneously. – apsillers Feb 22 '16 at 16:26
  • 2
    Onlive did just this, with rendering on-server. So its not really "un-viable". I think as servers get more powerful, maybe server-side gaming will become the best method to fight cheating. – sebastian nielsen Feb 22 '16 at 16:28
  • @sebastiannielsen Sure, there are services that do this; Valve simply isn't one of them. Maybe "viable" isn't the right word, or at least it should be understood to mean "viable in the context of a particular vendor's constraints." As costs for processing power become globally less burdensome, this approach becomes increasingly viable for more people. – apsillers Feb 22 '16 at 16:29
  • 8
    @sebastiannielsen: Of course you could still cheat with server-side rendering, but things like aim-hacks would have to do visual analysis instead of just reading player-positions from memory. Where there's a will there's a way. – BlueRaja - Danny Pflughoeft Feb 22 '16 at 17:37
  • 7
    Also onlive has also been dead for nearly a year due to lack of people wanting to use it, partially because of unavoidable issues with streaming games like input and display lag. (Also due to it being really expensive to host that much rendering power and streaming capabillity) – Elva Feb 22 '16 at 17:55
  • 7
    @sebastiannielsen Not everyone has multi-megabit connections that can handle such streaming with acceptable latency. There are still plenty of people in the US on 3mbit or slower DSL connections, not to mention the rest of the world. This is not an acceptable solution and will not be unless some altruistic company begins magically deploying fiber to users all over the world. – Doktor J Feb 22 '16 at 19:50
  • 2
    @DoktorJ: The main issue with streaming games is latency, not bandwidth. You can stream HD with only 5mbps _(Netflix's highest 1080p stream is only 8mbps)_, so even "only" 3mbps is fine. The real issue is latency, which is bounded by physical limits. The only solution is for a company to spatially distribute their servers. – BlueRaja - Danny Pflughoeft Feb 22 '16 at 23:27
  • 1
    This is a very good answer. Let's add to that another point: Not all cheats are wall-hack or ESP style cheats. There are also aim-bot style hacks, certain movement scripts etc. which are considered cheating in many games. And these cannot be detected server-side. Even if we opted to go all the way down that unrealistic "Render all on server, send view over wire." path, the client will still be able to employ these kind of hacks, and all the server will see will be the action commands output by the hack. That means even in that case, we'll need a cheat detection service running on the client. – uygar.raf Feb 23 '16 at 10:05
22

Client side anticheat software in and of itself isn't about security, it's about the gameplay (and customer) experience.

Thus, security rules aren't nearly as applicable. Trusting the client "hit pixel 1056 by 1723" is very different than trusting the client "can transfer $1000 to Nigera", or that the client "can access Bob's email".

Note that I am specifically excluding financial transactions, just gameplay cheats like aimbots, big head cheats, etc.

Anti-weakpasswords
  • 9,785
  • 2
  • 23
  • 51
  • 9
    I hear some people spend considerable amounts of money inside games... – user541686 Feb 22 '16 at 05:15
  • 22
    @Mehrdad - and the monetary transactions themselves are unrelated to the anti-cheat software that is the focus of the OP's question. Those monetary transactions will be subject to server side - and financial institution - checks. – Anti-weakpasswords Feb 22 '16 at 06:36
  • 5
    What I meant was that if people lose money because of other players' cheating then they will be ticked off; it wouldn't seem very different from genuine monetary fraud for them, so anti-cheat actually does have a security role. – user541686 Feb 22 '16 at 06:40
  • Also I don't realy get the argument why this isn't aplicable here. Even more, especially here it is aplicable. its a scheme. so the field of "client" is irrelevant – Zaibis Feb 22 '16 at 08:12
  • 7
    @Mehrdad: Unless you're playing gambling games or playing competitive matches with monetary prizes, those money are paid to the game company, so you don't actually lose more money than you would have when someone else is cheating. The cheating might degrade the subjective value of the game, but the money is amount that you've already spent anyway. – Lie Ryan Feb 22 '16 at 09:52
  • @LieRyan: Except it kind of *is* money. [*"Items in games like Team Fortress 2 and Counter-Strike: GO can be worth a lot of real money on the secondary market, not to mention the inexplicably popular virtual trading cards floating around the Steam social network."*](http://arstechnica.com/gaming/2015/12/steam-tightens-trading-security-amid-77000-monthly-account-hijackings/) – user541686 Feb 22 '16 at 09:59
  • 9
    @Mehrdad: if an aimbot-using cheater keeps killing you in a public server, did you lose your hats? If you bet your hat in a match, then that's gambling and I've touched briefly that gambling games is kinda an exception. However, got the specific game, as far as I can tell, you can't actually be forced to part with your hats in TF2, so if you suspect someone you're betting your hat against is cheating, you can just not give your hat to them when the match is over. – Lie Ryan Feb 22 '16 at 10:07
  • 3
    @Mehrdad: in most games, playing with cheaters would ruin your gameplay experience, and if you have bad experience in a game, you become less likely to spend money in it. That's why preventing cheating is important for game devs. But while aimbot-using cheaters probably would ruin your day, it wouldn't actually make you financially poorer. I believe that is why most games doesn't need to be designed to eliminate cheating entirely. OTOH, real money gambling **are** usually designed to eliminate the possibility of client side cheating, and prized competitive games are usually played in-person. – Lie Ryan Feb 22 '16 at 10:20
  • 1
    This answer is nonsense: by saying `Trusting the client "hit pixel 1056 by 1723"`It's admitting a concern for integrity of the message. And integrity is one of the properties which security aims to provide. The fact that anticheat improves user experience is not mutually exclusive with having a security scope – berdario Feb 22 '16 at 11:22
  • 2
    I disagree with you. Security of a system has little to do with what the system is protecting. Eg: a security of my tertiary bank account, which never holds more than $100 is much less important than integrity of Starcraft World Tournament qualifications, worth over $1M in prizes. Bank client and game client require pretty much same security, the real difference here is that bank server CAN verify everything, while game server can not. – Agent_L Feb 22 '16 at 12:35
19

First: There are many games, which use 100% server side validation and don't trust the client. One example: Online Poker

You simply do not send the value of any cards to the client which he cannot know. So even if he hacks the client and reads the matrix, there is nothing hidden which he can reveal and no moves he can make which he couldn't do with the regular client.

But many modern games are a lot more complex. A first person shooter for example. Here it is not so easy to decide if and how good you can see another player. You might say it is easy, if there is a wall between you two you cannot see him. And for these simple cases modern games can already cull the enemy player from your view, so you won't get the position where he is. But as soon as the enemy is in a dark corner and only barely visible the game has still to send his position to you, so you graphics device can paint him there. If you use a cheat, which paints him in bright colors you can easily spot him and cheat. This is hard to prevent, because the logic which paints him in dark colors in the shadow is very complex for games with good graphics - so rending the picture on the server and only sending you the final picture would make cheating a lot harder, but also would require a ton of resources on the server and would have the serious problem of LAG.

DELAY or LAG: The second big problem to streamed gaming is lag. If you move the mouse, you can look around very fast in a first person shooter. But sending this command over the internet and receiving the result to show on your screen will necessary take longer than rendering locally. If you have a fast internet connection you can be lucky with a Ping below 20ms, but most connections can be very unstable and the lag can go higher at times. A game which reacts that slowly will play horribly slow and be almost no fun at all. On the contrary many modern games apply a ton of techniques like move prediction, time warp and others so you can lower the perceived lag of other players by making your game compute a lot of local logic and predicting the moves of other players, so the game feels more fluid than it actually is.

Hardware/Out of the box cheating. And there are always a ton of opportunities to cheat which cannot easily be defeated by software. What about doping? (a real thing in esports) Or letting a robot play for you. Or having a webcam over your shoulder, which spots enemies on your screen and tells you where they are? Or even things like DDoS attacks from a botnet on you enemy team to disturb their communications ?

There are some possibilities to make server-supported validations. The server can test the correctness of the game code/anti cheat software like DRM protection (but can of course be spoofed). The server can also check the game logic, measure your movements, collect statistics and data about your behaviour and compare it to other players and certain limits and try to decide if you are playing abnormally or if you are breaking any rules... but nothing of this is perfect.

Falco
  • 1,493
  • 10
  • 14
  • 7
    Side note - stereo sound requires a 3D location of the source. In order to play a footstep sound, your client needs to know exactly where the footstep came from; you could potentially convert that into a wallhack. – Sam Dufel Feb 22 '16 at 16:39
  • good point! modern games just offer too good audio and visuals to make this feasible ;-) – Falco Feb 22 '16 at 16:42
  • 2
    +1 Latency compensation to create a smooth gameplay experience is perhaps the biggest reason for the server to put some trust in the client. That way, in a game like an FPS where you have someone's head in your crosshairs and shoot it, the server accepts that you got a headshot rather than telling the client "sorry, that person's head was there 200ms ago, so you missed". The cost of rendering on the server can be overcome, but latency cannot. – Muhd Feb 23 '16 at 16:46
  • 2
    +1 The only answer which pins down the real problem. I'd like to point out however that it _is_ possible with really good server hardware to check a lot more of the cheating cases in games like CS, but the cost would make running free servers nearly impossible. – Sebb Feb 23 '16 at 21:37
16

If so, then why do these companies not offer server side verification for video games, but rather continue to insist on trusting the client?

They do!

Most online games have some consistency check every now and then.

Player32517 moved 100 units in 3 seconds, is that possible?

However, checking if every single move is valid is an enormous amount of calculations.

Take any shooter for example:

Your average gaming pc starts to struggle if there are too many granades/enemies on your screen. This load is distributed to 20 computers.

Now imagine you would have to calculate all that again on a server and check every move, every mouse swipe, every fire trigger for cheating patterns. In real time.

Because of all this it is much cheaper or even possible at all to check every now and then if you could really have jumped that far, moved that quickly or kept your mouse exactly on the enemies head for 3 seconds before you could even see him behind that wall.

And if all that fails, you still have the community reports with video footage.

Edit:

Thanks Num Lock for pointing that out:

The lag isn't caused by the logic but rather by the rendering. Calculating all the vectors for the light and animations is vastly greater than calculating if something was in range to get hit.

N. Nowak
  • 585
  • 4
  • 13
  • 18
    While I mostly agree, I still think this is half myth and half fact. While you are right that the _average gaming pc_ starts to struggle with a lot of action going on, this is usually not caused by the game logic itself but rather by rendering everything (yay to pretty graphics), which (in most cases) doesn't happen on the server. And there have been large scale games (MMOs to be specific) which handled _everything_ on the server for each player (10k+) with _every_ tick, but your PC would struggle if you just saw 100 of them. (LineageII for example) These weren't as time critical, though. – Num Lock Feb 22 '16 at 07:14
  • The Source engine, Valve's code base for a good number of their own deliveries, has features allowing the developer to compensate for latency, interpolate a prediction and verify every update pushed in from the client against a threshold. This is done by default for every movement and trigger pull and helps gameplay on the client (players don't have to predict nearly as much lag) but also prevents malicious packets. – Gusdor Feb 22 '16 at 11:12
  • 2
    Wow the answers for the question are just terrible. This answer is the closest answer to correct _(servers **do** do server-side verification)_, but the reasoning is completely made up, it has nothing to do with doing "an enormous amount of calculations". If between two packets the user claims to have moved twice as fast as usual, is that because they're speed-hacking, or because the first packet arrived extremely slowly? And how could you detect wall-hacks or aimbots serverside, even with unlimited computing power? – BlueRaja - Danny Pflughoeft Feb 22 '16 at 17:40
5

There's two elements to be addressed here.

Firstly, client-side cheat detection is rarely the sole element in cheat prevention. Given that server software for some games is also distributed, the server-side cheat detection software may be not be fully distributed with it in order to prevent exposing it to reverse-engineering. You can't infer a lack of server-side cheat detection from the server code you may be running vs. the server code they may run internally. Also, companies may be reluctant to discuss their anti-cheat solutions for similar reasons: obscurity isn't a bad thing to have on top of a robust solution.

Yet there's also a necessity to client-side cheat detection due to the fact that games rely on player skill. This means that cheating can happen at many levels: hardware, input, and software. Software is merely the most convenient and precise, there's very little can be done to guard against a proficient robot. In order to guard against software-based cheating, you must have some kind of resident monitor on the client to have a chance of detecting it.

Furthermore, a game simulation is complex. As you rightly stated, there is little preventing someone from building a simulated client that correctly copycats all the protocols that the game uses and can arbitrarily generate inputs at the right time in order to cheat. Just that doing so is a huge undertaking; it's far easier to attempt to break the existing client. The same goes for building a fake anti-cheat client. As such, client-side security is more a case of making things as difficult as possible rather than being 100% foolproof. Valve in particular regularly make updates to VAC to compete in a continuing battle with cheat developers.

Danikov
  • 151
  • 2
1

Most of the other answers focus on the technical aspects of cheat prevention, I'd like to add that VAC prevents cheating by making it economically unviable:

TL;DR: Client-side cheat protection works because the effort and skill required to trick it are high and the punishment for mistakes is severe.

Hacking involves a lot of try-and-error and even if you have full access to the source it requires a significant amount of work to find out how to modify a client whilst having it pretend that it wasn't. And all this work is rendered moot every time the client is updated.

On the other hand, if you make even the slightest mistake you risk being banned forever from all VAC servers.

There is also no point in distributing your hack, as Valve also knows how to google for cheats and once they find your hack they will add some extra detection logic to find everyone who uses it. This again discourages users from using publicly available cheat tools.

Cephalopod
  • 111
  • 2
  • I don't really agree here. Severe punishment is Valve's policy and has nothing to do with the cheats being detected on the client side. However, ruining a cheaters work with every update is really a big point, since having to put a lot of effort into it keeps the "script kiddies" and "I-just-tried"-guys at bay (theoretically). – Sebb Feb 23 '16 at 21:43
0

The challenge with security like this is that you have to do the computation where the information is. You either need to do the anti-cheat computations client side, or move the information server-side so the computations can be done there. For many games, passing all of the information to the server can be exorbitantly expensive. To do so, the client would need to save off all of the user-interactions and what time they occurred. Shipping all that information to the server to do analysis is too much, so instead the computation is sent to the client.

That's not to say that's the end of it. Many games implement both client side and server side tests. Some tests can be made based on information already being sent to the server. It may not be able to catch all speed hacks as someone zigs and zags, but it could catch someone who manages to move from point A to point B far faster than the game rules allow.

There's also an intriguing option: commitments. A client could offer a cryptographic commitment describing all of the user interactions, such as a SHA-1 hash. On a command from the server, they may be obliged to provide the data which generated that hash. This pattern is used in some distributed games which have no server to keep players honest. Clients are obliged to make a commitment to actions they made in the past before other clients will send then the current data. That prevents one client from rewriting its history.

Cort Ammon
  • 9,206
  • 3
  • 25
  • 26
0

Valve does do server side VALIDATION for everything.

All client input is perfectly VALID.

Valve already does checking on valid user data. For example, the client can't say to the server, "I shot Sparkles from the CT spawn, when he was in the T spawn".

It also checks that when you buy something, you aren't trying to buy that gun on credit. If the server didn't do that, then the cheater would be buying AWPs on pistol rounds.

Cheating is VALID

The problem is that cheating (on CSGO for instance) is doing perfectly valid action (the cheats that do invalid actions, like the Spawn Teleport glitch, can be fixed easily). The problem is that cheaters use a variety of methods to enter valid input that is either enhanced or made by a computer.

In effect VAC is trying to apply the Turing Test on a player. Even a server cannot verify the identity of the agent making the decisions.

Aron
  • 763
  • 4
  • 13
0

Server side checks are to make sure the operations requested by the client are legal. Basically so that you don't try to run twice as fast as you're allowed.

Client side checks are to try to verify that the decision to make that change is made by a human, not by the computer - e.g. aimbots who make legal client commands (and therefor not detectable by the server) but are still not allowed.

Also, server-side you can do post-processing of large data sets to try to determine if the player is cheating, but that's something you'd need to look at after the fact and is always an imperfect science.

xaxxon
  • 101
  • 1