Vanquishing Net MP CheatsEdit

  • This topic naturally re-surfaced in discussing HOW to enhance the on-line gaming experience.
  • If you'd like to review that talk... follow the HotLink...

Chojun Distills the ArgumentEdit

  • I agree with Hast's position. I like to think of the following mathematically.
  • THEOREM 1:
  • A client cannot compromise game calculations if all calculations are performed server-side.
  • All client-side calculations can be compromised.
  • Therefore, a client, during net-play, becomes a terminal (such as in *nix systems) where the user simply sends commands to the server, i.e "I would like to do this." Server calculates and returns results to client (updating the game world and giving the client the info it needs). Such a simple model is what *nix is built on, which is what gives *nix its reputation for security. All clients, whether upper or lower-echelon, operate on a "need to know" basis. The server does not send or receive more information than the client "needs to know."
  • The concept is simple, which I could see causing others confusion: "Why don't game companies implement such a server-client model for their games?"
  • Such a model can only be designed on the pre-project level, i.e. the entire project must be integrated and built around the server-client model. The project cannot be built first, then the server-client model implemented. So many, many parts of the project can send packets (or, have data that will need to be sent through packets) that this can be difficult to entirely implement.
  • Also, hardware limitations impair the complete implementation, especially in games where lots of data needs to be sent up and down the network every frame.
  • Following the theorem (and its corollary) above is the only true way of preventing cheating. Data on a client, no matter how vastly encrypted or obfuscated, can still be compromised.

karmazilla Does His DistillingEdit

  • Alright, lets try to think through a modded multiplayer game in a server controlled setup.
  • In order for the server to know all the rules of a mod, the mod must simply be applied to the server instead, or in collaboration with, the clients.
  • This has several advantages:

- players can choose amongst the probably huge library of mods collected on the server, and download any additional files (like graphics) as they are needed.

- the version conflict problem are eliminated for mods when the server dictates which files to use.

- naturally, the mentioned security and cheat prevention.

  • but there's also obvious implications:

- mods are likely to be designed to work with this architecture and this might lower the amount of mods available to online multiplay.

- a large bulk of calculus is put on the servers shoulders and this might lower response times.

- network resources might also be streached, making the game lag prone.

  • a key question must be answered in the consideration of this approach: "Is it a proven method?"
  • Yes. The popular MMORPG genre has proven that servers are able to handle thousands of users with a unit each, so it should make sense to expect that at max 8 players with at max 300 unit each can be handled within reach of todays technology.

Only, even this client-server oriented genre is subject to a growing quantety of cheating, so obviously the current implementations does not exploit a tight anti-cheat method (In Dark Age of Camelot, radars are increasingly the rule than not).

  • My conclusion is that this may very well be a robust and well working method, but as far as I know, we'll probably become pioneers in its implementation.

GER_Killekulla Carves Out His POVEdit

  • There also can be some hybrid solution:

- Make all calculations client-side, so there won't be any lag. No change to core game engine necessary.

- Only send game-relevant information to server (I.e, all interface input, synchronication-events and other important things).

- Client also sends important information of enemy players to server.

- Make some important calculations server-side, also look for discrepancy.

- Server checks game-relevant events and information for plausibility. Server measures the probability, if there could be some cheat in action.

  • (I.e. the server knows, how much power and units each client should have, because it knows number of power stations und oil sinks, it knows build-time and costs fo tanks, research and so on)

- Generate global database with player information.

- Put number of played games into database.

- Also put number of suspicious played games and cheat-probability-information into database.

- Make global database attractive by installing some advanced ranking system, including number of played games, points, wins, ...

- High-Rank players won't try to cheat... the risk to loose fame is very high.

- Slowly add some feature into the client, so that it only can see units of its own team. Only when neccesary, enemy units shall be added on the fly.

--> No fundamental changes to the core game engine necessary.

--> 'Felling' of the game doesn't change.

--> If one cheater tries to fake information sent to the server, the server can detect this, because it also looks at information sent from the cheater to other clients. I.e. if the other clients do see any gauss canon, and the server knows, that the cheater didn't built any or built them to fast or to cheap or to strong, a cheat is detected. Also if the other clients see strange unit/weapon information, the server allways knows if everything is right. And it must not calculate everything of the game

  • And if the cheater also fakes information that is sent to other clients, he can't win... because to win he has to expose his cheats
  • Cheat detection routines allways can be added and refined with this 'full-client' / 'minimal-server' - model.

Kevin's Re-conceptualizationEdit

  • i've been thinking about this for a bit, and have a silly idea.
  • you know how unix systems, though open source, can be very well secured through the use of 'terminals' which relay data to the user, but don't run anything (except a terminal emulator - important) on their machine.
  • A basic text terminal can be used confortably from a slow dialup connection. I can even use a graphical terminal fairly comfortably from dialup, provided the underlying system does not send many pictures.
  • How much bandwidth would be needed to take the high level information from a graphics system (draw this here, whatever), with the textures not transmitted, and send those commands to a client designed to render the information using d3d or sdl or w/e? it sounds farfetched, but is it? how hard would it actually be to accomplish this 'split' in the graphics code?
  • right now you could probably play the game using a vnc or x terminal, but it wouldn't be very fast (it would be fast enough over a lan) because those protocols rely on sending pictures, or wouldn't work at all in the case of hardware rendering (black frame most likely).
  • oh, and sound data (play this sound at this 3d location, nothing special or hard here, a few bytes per sound).

"SecurePlay" Put It TogetherEdit

  • Kevin..... Cowboy ......look at what I just came across...
  • Check this out:
  • Sony Corp has bought into it in a big way...
  • A strikeing combo of concepts related to your seperate ideas guys... all brought together (even the POVs I mentioned.)
  • You can request more info on CD & so on....
  • Also of interest:
  • I believe this to be a viable working solution.
  • Secure Play has been on the market for several months.
  • Over 200 Developers are on-board.
  • Sony Corp (Multi-Billion Co.) has evaluated & bought-in for their Multi-Million $ Playstation business.
  • Developer Forum: HERE
  • Got questions- ask there or thru support.
  • "Secure Play" is For-Profit venture with Millions at stake.
  • They ain't just giving their chit away...... Patented Intellectual Property & some International Patents are still pending. Their pricing - sweet.
  • The company's 20 year biz history is verifiably impeccable. Thier client list no-less than impressive.
  • There is much marketing but I also found lot 'o meaty info.
  • Just a few examples:
  • I find myself feeling that this topic has reached a watershed with the existence of Secure Play's Anti-Cheat Net MP Tech, its Modus Operandi & it's roll-out.

Pursueing "SecurePlay" TechEdit

  • Protect the games integrity by protecting the protocols, not the software &
  • Provide a non-deniable evidence log.
  • That's a summary after studying several hundred pages of documentation....... & .....
  • The C++ Source of "SecurePlay" is available for Non-Profit Developers. (Java & Linux versions too, I think.... I'm bleary-eyed at the moment & brain a bit mushy.)
  • Just contact their "Support" division.
  • Those with a genuine interest / passion for this topic..... I would highly recommend you delve into & pursue what is being offered....
  • That could possibly also include a no-cost relationship with the Co. towards applying this tech to the WZ Re-Dev. effort.

GER_Killekulla Puts It All TogetherEdit

  • Quotes copied from the SecurePlay forum:

  • QUOTE: "There are four core protocols that are part of SecurePlay now. These protocols sit at the "bottom" of the game. They are much like the table, cards, and dice that we use for face-to-face games, but are built to work securely in a network environment:"
  • QUOTE: "1. Multi-step Protocol - This is a generic multistep transaction that provides encryption, digitial signatures, and a privacy mode (where an alternate message is sent to the game participants that are not part of the transaction - think of a card deal: I get a card that I can read, you see that I get a card, but you cannot see it."
  • Sounds like encryption of network communication. Warzone uses encryption with a _known_ key. Implementnig encryption with different unknown keys for each encryption channel will not be very difficult, also without using SecoutPlay platform.

  • AFAIK Warzone doesn't imlpement that, and it won't be very difficult to implement this framework without using SecuryPlay. This feature is usefull to avoid lag by sending lots of 'secrets' to a client, and to reveal important information just in time when needed.
  • QUOTE: "3. Simultaneous Protocol - This is for creating logically simultaneous events over a network. The simplest example is "Rock-Paper-Scissors" where things must occur simultaneously to work."
  • I don't know if the Warzone engine supports time-tagged events. But if something secure is needed,

it will be not very difficult to use serverside (encrypted?) timestamps.

  • QUOTE: "4. Shoe Protocol - This is a means to produce one or more random events. It essentially replaces the randomizer and other related code to build fair random events over a network (dice, cards, laser blasts, whatever)."
  • With server support this won't be very difficult to implement, if needed. With statistics, effects of random events can be checked for plausibility.

Next AnalysisEdit