Questions about "Secure by design" server communication

[alvrrr]

Hi, I'm new here, and I have some questions about how to make a secure server communication in a free software project.

First of all, in multiplayer games, how do you prevent cheating?
For example, let's say someone gets the source, alter the speed of the character to 2x the original one and recompile it.
What are the available tools/ways to prevent that? Is there a way to make your game secure by design against this type of stuff?
What if both the game and the server are free and you have access to the source?

I suppose the server could check the position and infer if someone is cheating based on that, but I'm talking about a more general way to prevent the user to modify his client for doing what he wants. Is there a way?

Second, kinda the same type of question. But let's suppose you have a server that tracks scores and achievements (the source may be open as well).
How do you make that type of communication secure? For example, there's an achievement for killing 10 bad guys.
How do you keep the player from modifying the source to send that message to the server (that he already killed the 10 bad guys) when he wants, or to set the counter to 9 when a stage starts so the next bad guy he kills gets the achievement.

Is there a way to do it as well?
The best thing I could think of for the second case would be if the game was compiled with a certain "secret", it would hash the info in a way the server expects (let's say, with a salt stored in a db, so the user can't know even though the server's source is free).
But it comes with the drawback that the player needs a compiled version provided by the server owner, otherwise he would not be able to get the achievements, etc.

Basically I want to prevent cheat and have an achievement server, keeping everything free software and allowing the user to compile it himself if he wants. Is it doable?

Any ideas (or sketches of ideas) or reading recommendations (papers/books/etc) on this are very welcome

[Julius]

Games with a server/client architecture avoid all these issues by running a complete game on the server and (simplified speaking) taking only sanity checked movement commands from the client.
Just have a look at (and preferably use) one of the many open-source engines that have a build in multiplayer component. This is rather common stuff.

[Vandar]

Julis idea is the right one - keep all game state on server and use the client only as input/output module (aka thin client). Players can only recompile the client, and if all logic and data are on server side, it's significantly harder to cheat. They'll have to look for loopholes in the server logic, use those to corrupt the game data in their favor.

Eventually it will be a compromise between security and performance. If each and every user interaction is handeled as distributed transaction there is no way to cheat, but it is not performant enough for e.g. a realtime FPS.

[andrewj]

Some open source engines (like Cube, possibly Sauerbraten too) do not use a true client/server model, and have had problems with people cheating by modifying their client source.

Even true client/server model (as used in Quake 1/2/3 engines) cannot prevent certain kinds of cheating, like aimbots and wallhacks (showing players through the walls when you would normally not be able to see them).

[xahodo]

Keeping a complete game state on both client and server doesn't harm, but if only changes are sent over the network (and those are consistency checked by the server) you can prevent a lot of cheating, especially when you check the state of the game once in a while (say every 5 seconds) with the clients.

If one is not consistent with the server, he is either cheating or triggering a bug. At that point the connection could be terminated.

[Vandar]

If you make the client a pure input/output device and keep all data and logic on the server, it is very difficult to cheat by hacking the client or the communication layer. Keep that "public" server API as narrow as possible, and never send data to the client from which they can extrapolate guesses on other data on the server. The less information the server gives the client the harder a hackers life will be.

But eventually a hacker will always find ways to exploit the communication channel, regardless how narrow it is. You can make a hackers life harder by having semi-random sequence numbers for the messages, i.e. the sequence of a RNG algorithm which the client and server know, but which the hacker must learn to predict, to spoof messages. Message encryption with dynamically changing keys, also checksums with dynamically changing algorithms will make the hackers swear and wish the designer of the protocol to go to hell.

But nothing is safe, all those measures can be countered, particularly if the client is open source or the code was disassembled. But for many, particularly free games it will be good enough, because there is no money to make by botting and selling items or characters as it happened in older RPG MMOs. Just make breaking it harder than the expected reward for the hacker and you'll be safe from 99% of all hackers.

[xahodo]

It all boils down to the balance between amount of effort for the cheater/hacker and the worth to hack your game.

If there's money (microtransactions or winning through forms of gambling (tournaments, for example)) involved, you might as well assume your game is a target for hackers as there's always money to be made and as such you should write your game to be paranoid with clients and thus the server should assume it's always right on top of a coupling with an email adress or (idealy) a bank or paypal account.

However, if there is little to be gained by hacking your game, you could simply opt for a salted client/server model where the server always assumes it's right. That should thwart most cheaters.

If there are accounts involved, those accounts should be checked and double checked for things like multiple loggins and tampering with the records. If you have rewards or a ladder in the master server, you could attach a server to a player account (for accountability reasons). If a server is found cheating, the player (and thus the server) could be blacklisted (i.e. kicked from the ladder and reward system).

Now on to how to check for cheating servers

A server should report each event required for a reward to the masterserver. The report should then contain:
- Server ID giving the information
- Client ID to which the event applies
- Game tick the event was generated
- Basic event information
- Other client ID involved (if so, this player should also have an event).

The master server then checks this for sanity and for cheating. If something isn't right, the server is disconnected and all scores don't go to the ladder or reward system. The server and it's clients are than informed of that.

This is the most failsafe system I could dream up. This system also generates the most developer work (as the master server needs to be kept up to date) and network traffic. Memory consumption of the master server might also skyrocket (depending on your game). However, in this case the client code, server code and master server code can all be open source while still making cheating very hard.

[Nikita_Sadkov]

First of all, in multiplayer games, how do you prevent cheating?
For example, let's say someone gets the source, alter the speed of the character to 2x the original one and recompile it.

In multiplayer games we have a concept of parallel universes running in sync (clients share state edits with each other). Typically each client computes a hash of it's state, which then compared by server, running its own copy of universe. If some client supplies wrong hash or bad edits, it gets kicked and it's player loses the game.

So it is basically up to the server or some P2P network to decide who is right and who makes moves against the rules of the game.

In games using random number, pseudo-random number generator should be handed to the 3rd party, so no single agent can predict the state. Some developers have decided to make their games completely deterministic, so the random number problem gets solved by absence of random numbers. For example, Blizzard removed random damage output from Starcraft and Warcraft 3, while earlier Warcraft 2 had it and the corresponding problems.

It gets much harder with fog of war, where the only way to prevent hacked client seeing unexplored terrain (maphacking) is by keeping state secret - completely on server side or inside of some encrypted P2P network, where no single agent knows entire state.