Punkbuster exists just to prevent cheating, and yet cheating is common in punkbuster enabled games. Modern Warefare 2 is seriously locked down from the end user running their own server or making any mods, and cheating happens constantly.

For a multiplayer game where each client is running on a PC, what can be done to reduce or eliminate cheating?

  • \$\begingroup\$ strlen.com/trusted-communities \$\endgroup\$ Commented May 18, 2013 at 21:52
  • 1
    \$\begingroup\$ This isn't a complete answer in itself so I won't list it as one, but if you add a certain amount of value to the players account in addition to traditional anti cheat methods I believe that can help. For example if the new players are relegated to the "noob" servers until they gain enough experience to access the rest of the game it makes it a massive pain for hackers to re-level their account after being banned every time. There are probably still some hackers that can get past that, but securing your account/matchmaking servers is much easier than securing clients. \$\endgroup\$ Commented May 18, 2013 at 23:42

6 Answers 6


It depends how they're cheating, focusing on one of the primary ways of creating cheats, other processes latching into your application and modifying it - you can enumerate through all other processes, and hook their memory manipulation methods, and their keyboard/mouse emulation methods.

Wallhacks are typically written by injecting code between your process and the DirectX/GL libraries to set the transparency on materials so they can be seen through. You can add some code to your scenegraph/culling system to specifically not draw other players/useful entities if they're behind walls (to prevent cheating that way).

If you're going multiplayer and want to prevent packets being modified between client/server, then creating a checksum of the data you're sending via some algorithm of your own and checking this as it comes through on the other side can be effective. (You will probably end up doing this anyway for various QA purposes).

The same goes for most of your in-memory resources, creating a checksum at the beginning of a frame, and verifying it at various stages can yield in some pretty handy memory manipulation detection.

This is quite an involved topic, but hopefully this sets you in a vaguely acceptable direction.

  • \$\begingroup\$ Or even better than hiding objects behind walls (which can still be hacked), not giving the client information about that player's location at all (or only that which is needed for e.g. a good sounding 3d sound effect) \$\endgroup\$ Commented Sep 3, 2010 at 0:36

At the most extreme solution, you basically never trust the client. For games like MMOs, users don't run their servers, and any gameplay logic is handled server side. Never give the client the authority to say "I have X health" or "I have X ammo", etc.

  • 4
    \$\begingroup\$ That's great if you actually have the resources to run a dedicated server, but it's quite simplistic way of looking at it. Most likely you'd still do a lot of the logic on the clients and a minimal subset of the logic on the server, with occasional syncronisation to enforce basic rules. It also doesn't necessarily prevent against all the client-side cheats like wallhacks/memory manipulation to fool the client into revealing useful information/etc \$\endgroup\$
    – metdos
    Commented Jul 15, 2010 at 15:06

If you've got a system where the logic is expensive and must be done mostly on the client to save server cycles, you can implement a probabilistic cheat detection system. Every few minutes it chooses a different few players to inspect closely and consistency-check on the server. Since cheaters rarely limit their cheating to short and rare periods of time, they will be caught eventually.

Another benefit to this is that they won't have a rapid turnaround cycle for development - if it takes 10 hours of gameplay on average for the server to pay attention to you, then that's a 10-hour turnaround cycle every time you want to see if something worked. And if it did work, it's even longer because they won't know if the server has given them a thumbs-up or just hasn't gotten around to them.

  • \$\begingroup\$ +1 In terms of performance, stochastic approaches like these are the only realistic answer to the broader issues, IMO. Aside from OnLive, that is, if you're targetting the US only. \$\endgroup\$
    – Engineer
    Commented Dec 11, 2011 at 12:57

There are also many types of aim-assist hacks for first person shooters that also work by hooking into graphics library calls. OGC Hook for Counter-Strike / HL1 had a multitude of options beyond making walls transparent.

If the location info for enemies is at some point passed to a lower level library which has widely available code, those calls can be hooked into and the location, scale, rotation, etc. data can be used to precisely calculate the best vector for firing upon that enemy. Anti-cheat systems like PunkBuster often include heuristic-type detection (how often does this player get a perfect shot, how often do they spin around 180 degress to land a one-shot kill, etc.) in addition to memory and process monitoring.

Ultimately the task of preventing cheating in multiplayer games is a game of cat and mouse. As new cheats are developed, new anti-cheat methods are created, and then new cheats are built to avoid the new anti-cheat technologies.

As Tetrad said in his response, the only hard and fast rules for "game security" are to provide the client as little information as possible, and to trust the client as little as possible. Different types of games will have different requirements that can impact how well you can adhere to these rules, though.

In an FPS game, because the speed of gameplay is so fast, it is often not possible to only provide the client with data it should know about this exact instant. If you don't tell the client there is an enemy around the corner and the player does go around that corner you suddenly have to send them that information in a matter of milliseconds or risk having the player be killed by an enemy they didn't ever see.

The only "fix" for these issues that is currently available would probably be OnLive. Because that service only delivers audio and video content from a client running safely in the datacenter the only means for cheating would be to essentially create a human AI that could analyse the incoming video stream and take action based upon that -- a task that few, if any, cheaters are up to.


All the answers above are great, but I'll add another piece:

Some games have a very solid replay feature, which allows to save every game's replay after the game's end in a compact format, and watch it in various ways - different player perspectives, real-time statistics UI and so on.

Example that I'm very familiar with: Starcraft 2. One of the ways that Blizzard blocks hackers is by receiving cheating evidence as game replays.

An example for usage in an FPS would be: if you played a game and you suspect that the other person cheated with a wall-hack, you watch the replay, and then see that in his normal replay vision, he couldn't have possibly seen you and throw a grenade over the corner, or whatever.

You then report him with the replay, and if the evidence against him is good enough, he's banned. As far as I know, companies who do this things only take serious evidence, or multiple sources of evidence of the same behavior before banning.

So this is not an anti-debugging technique, it's a user report system that allows convenient human-assisted proof of cheating.


This may not be a full answer, but I have some input here. One of the best ways to prevent cheating is obfuscation or using C/C++. This prevents people from modifying the client code.

  • \$\begingroup\$ It's worth mentioning that there are many deobfuscators out there. Also .Net (C#, XNA) games can be modified using a Reflection. From what I know, I guess C/C++ really is one way to make it hard to tamper with the code. \$\endgroup\$ Commented May 12, 2013 at 8:21
  • \$\begingroup\$ Yeah. My point is just that obfuscation prevents easily decompiled code to be unreadable and C/C++ aren't easy to compile, they're both good options. \$\endgroup\$ Commented May 12, 2013 at 8:22
  • \$\begingroup\$ Also, if you patch your game frequently and change binary offsets in the executable or insert random NOPs, no hack will survive long enough... \$\endgroup\$
    – SirKnigget
    Commented May 19, 2013 at 0:14
  • \$\begingroup\$ @CPP_Person: Actually C is quite famous for being very easy to compile. It's a totally different matter for C++, which is indeed quite a complex language from compilers perspective. However I don't get, why it should matter, how easy it is to compile a certain programming language - you want to prevent people from writing cheat tools, not from writing a good compiler - they would use an existing C++ compiler anyway - making decompilation hard seems a lot more interesting to me than making compilation hard. \$\endgroup\$
    – Kaiserludi
    Commented Mar 13, 2015 at 14:07

Not the answer you're looking for? Browse other questions tagged .