Obfuscation or hiding of server to client state updates

Question

I'm not actually writing this software myself, but it occurred to me that I have no idea how to solve the problem. As the best way to explain the problem, I'll describe a specific scenario from a hypothetical multi-player first-person shooter game...

• Player A is hiding in some bushes facing west
• Player B is sneaking up on player A from the east, or sneaking up behind player A

A popular "hack" written for this game would be for player A to have a radar showing him the location of player B, even though he can't see player B on his screen, and the game does not support a radar. This hack is possible because the server is sending info to player A's client on all players within a certain range (perhaps within player A's clipping plane). It would not be realistic (as far as I know), for the server to attempt to only send info to player A's client on players within player A's view frame. Because the server must send info on all nearby players to player A's client, player A could write a hack that overlays a radar on his screen, which is populated by watching for data sent to the client and pulling out enemy player state updates. I think these are commonly known as "radar" or "wall" hacks.

Is there any way to obfuscate or hide state updates of enemy players in the information sent to the client? From what I understand, encryption wouldn't be viable for real time solutions? Even if the server was able to only send state updates on players within player A's view frame, this would still allow player A's hack to show players hiding behind camouflage or cover objects (which were presumably transparent in a minor way).

The only thing I could really think of would be to implement some type of "punkbuster" solution. That is, have player A's client regularly scan for illegal processes. The idea being that any popular hacks would be monitored. Unpopular hacks would affect a small enough player base that they're too small to go after.

Answer 1

That's the only way. In addition to punkbuster, you should do some research on Warden (beyond wikipedia, there lots of interesting stuff that I won't link here). It's a very interesting battle given the laws of online world design ...

The client is in the hands of the enemy.

Another element to it is that people will replace their video drivers with modded drivers that give them advantages (things are opaque or highlighted, players can't be "blinded", etc). I'm not sure if any games check for modded drivers or not.

Answer 2

There was a program called "eqmon" that did something like this for the game Everquest. At first, the game packets were completely unencrypted and contained all characters (both PC and NPC) for the entire level. Eventually, they ended up using encryption to make it harder to snoop the packets, but eqmon got around that by brute forcing the encryption key (a new key was created by the server every time you entered a level, so it sometimes took a few minutes to decrypt the key). They then changed it so that your client only received updates for PCs or NPCs within a certain range of your location. This made eqmon less helpful for camping and monitoring "rare spawns" far away in the same level.

Answer 3

Simple encryption might be viable for real-time with today's hardware, but the problem is that in order for the client to access the encrypted data it must have the key. If the client has the key it will probably not be all too difficult for a cheater program to find and retrieve it. The best way is for the server only to send B's position to A if it's at all possible to see B. It will still be possible to cheat but to a somewhat lesser extent.

A possible solution for the cases when B is hiding but a small part may be visible is for the server to simply say that there's something at B's position. It may be a rock or whatnot. The problem is that in order for the client to be able to render the something, the server has to give a fairly accurate description. Given that today's multiplayer games fake low latency by simulating what the server does, this is most likely not feasible until we have ultra-low latency networks.