Designing a successful Anti-Cheat system
Since the dawn of time there have been games, there have been winners and losers and there have been cheaters. Cheating, winning by deception; whatever you want to call it. It has been prevalent since humanity first poked it’s head out of a cave. If there are rules there will be people who follow them and people who bend or break them. Why? Who knows? Is the desire to win so strong that it impairs moral judgement? Or is limiting your potential by following arbitrary rules the problem? I have no idea. What I do know is how to break games.
Breaking games is easy, fun and intellectually stimulating. Would I use these skills to cheat? No. Would I purposefully break a game and screw around? Absolutely.
I had an Indie Developer friend approach me recently and ask me how he should protect his game from cheaters and the cheating of his game. I asked him why he thought he needed to do that: he responded by saying he wanted people to play the game as he intended. I countered by saying cheats have been in games since they first came out, in fact I seemed to recall he and I playing GTA Vice City with the All Weapons cheat and seeing how long we could hold out against waves of police.
Sometimes cheating can allow you to create your own metagames on top of an existing game. Sure there’s a suggested way to play but why can’t I play it how it I want? Which brings me to very first question you should ask yourself:
Does your game actually need an Anti-Cheat system?
Well does it? If its a single player experience who cares if a few rove mavericks break it open and mess with it? I say let them mess with it, who knows maybe they’re busy and they just want to cheat past a particularly hard boss, or skip some boring side mission. They bought the game let them mess with it.
Using cheats as a reward
One of my favourite design choices in any game was in Goldeneye 64. The game on it’s own was solid, the multiplayer was fun and frantic and there wasn’t anything else available like it on consoles at the time. Doom was of course available on PC but Goldeneye had something that Doom lacked: Unlockable Cheats.
Those unlockable cheats were the most memorable part of the game. Seeing what pure insanity could be created in 4v4 multiplayer was great fun and it didn’t require a gameshark or any mucking about. The cheats also allowed (like I said before) the creation of new metagames on top the existing one. They also had a secondary effect: you had to be good at the game to unlock them. This ensured that players played the game properly first and then mucked about with cheating later.
Doom of course had the famous IDKFA and IDDQD codes but there were always there in the background like crutch. They weren’t earned and you always knew you could pull them out if things got a bit hairy during the game. It kind of broke the immersion for me once I learned they existed. This is where Goldeneye outshone Doom in my opinion.
Not only did Goldeneye have the standard weapons, ammo and god mode cheats it had other entertaining cheats like DK Mode, paintball mode and my personal favourite multiplayer match-up “slappers only + turbo mode” essentially turning a frantic FPS into a game of TAG.
Sometimes people want to cheat, sometimes it’s fun to cheat. If don’t want people to break your game and want them to play it “properly” try offering cheats as a reward. It’s a lot simpler then doing what I’m about to talk about.
Baked in Security
Unfortunately for a lot of software security is an afterthought. It cannot be prioritised at the bottom of the pile if you want to design a strong and thorough system for repelling cheaters. Most times it seems like games get “burned” by cheaters online and as a knee jerk reaction implement some half thought out Anti-Cheat system; or worse use a particularly hostile system which punishes honest players.
If your game is MMORPG or has some type Online play then you will certainly need to consider this in the design phase. Before you even open a compiler you need to create a system that is secure-by-design. As long as the design is solid you can always patch bugs and exploits as they arise. However if the system itself is inherently flawed-by-design no amount of patching will save it. This reactive form of development often leads to more bugs and more flaws over time not less (in my opinion).
I’ll use Fallout 76 and Bethesda as an example. It recently came to light during one of the more recent BETAs that Fallout had some serious issues. These weren’t bugs or glitches or implementation issues. They were complete design flaws.
Here’s a list of some of the things Fallout was doing:
- Important checks were happening on the client side.
- The server was explicitly trusting clients.
- Game files were not checked for integrity prior to joining an online game.
- The network protocol was unencrypted.
- The network protocol was in a human-readable format.
NB – At the time of writing this information was from an unverified source on reddit. Bethesda has since denied that this information was correct: however they’ve gone on record saying they were looking into some issues effecting multiplayer. So you be the judge on whether or not it’s true.
Which brings me to my first point:
Never…EVER trust the client
There is only one person who is trust worthy: the server. Short of successful hack on the server and code being modified you can be 100% sure the server is truthful. However you can not trust anything that is sent to you by the clients. Under no circumstances should you ever trust anything client tells you. As the server you need to fact check EVERYTHING.
The more things the server checks the more secure your game will be. However the more things your server is doing per client, per second the slower things will be. This is where the problem lies: how much stuff do you check server-side? There’s no correct answer to this question, ideally you check every single thing however this is not always possible.
The key is balance. At the very least you need to check things like player health, speed, location and ammo on the server. Your game also needs to be designed from the ground up so that the server tells the client, not the client tells the server. Understandably we aren’t all Blizzard with the resources of a small island nation so this is going to be at the developer’s discretion. Certain things may need to be offloaded to clients to reduce server load and costs, however don’t get complacent make sure anything you offload is verified on completion.
I don’t know how Bethesda screwed up the file integrity one. Pretty standard make sure your files are unmodified or match the expected files of the server. Don’t let players play with modified files ever. Single player mods are different but for online play everyone needs to have the same files. I’ve played older games which would boot you from the lobby if your files were different from the host/server.
Garbage in – Garbage out
It’s 2018 and things are still being sent over the wire in plain-text. Never send anything over the wire in plain-text ever! Before I can hear you saying “but performance” BitTorrent has been using encryption in forever and it hasn’t affected it in the slightest. There’s no excuse not to have encryption in place on a network protocol today in 2018. If encryption is affecting the performance of your game optimise your frigging code.
Then you top it all off by having an easily understood protocol that is human readable? Eugh. Security through obscurity is typically considered bad in most cases. However when designing an Anti-Cheat system denying your adversary as much information is extremely important.
The basic idea is layers. Encryption, integrity checks, obscurity. A layered defence strategy is always the best approach. Your entire defence should not rely on a single protection mechanism. Protecting your network layer is arguably more important than protection anywhere else. Once that data is pushed out the Wifi port or LAN cable it’s gone and you no longer have control over it. You can have the best Anti-Cheat system in the world but if you don’t protect your flank you’ll get a knife in your back.
Don’t be a dick
Another thing that gets overlooked with Anti-Cheat systems is how invasive they can be to your player base. Remember a PC is used for things besides playing your game, 90% of the time they aren’t playing your game. So don’t do anything that might affect the stability of their system or unnecessarily invade their privacy remember: they are your customers.
As a rule Anti-Cheat should only be active if:
- The game is open
- The game is running in a mode that requires Anti-Cheat
At all other times it should be disabled. There’s no excuses for this devs, if your Anti-Cheat driver affects the stability of my PC there’s going to be hell to pay. Or if your driver leads to some type of 0day that results in my system getting owned I’m going to be extra mad.
Always online: Just, just don’t do this. This is the worst idea that people have come up with. This may come as a shock to bigger companies like EA but some people play single player games and don’t have an always on internet connection. I’m playing single player why do I need internet? My Nintendo Gamebox doesn’t need to connect to the internet when I play games, why the hell do you need to?
Just don’t be a dick about it. Make your Anti-Cheat system fair and don’t punish people for having different lifestyles. I spent a lot time on the road last year and I pretty much only had an Internet connection for 2 hours a day. So do you know what games I played? Everything made prior to 2006.
Never trust the client, always encrypt your data, perform validation and integrity checks, do important stuff server side. Design your Anti-Cheat system from the ground up to be secure-by-design, or avoid using one altogether if you don’t really need it.
If you must use an Anti-Cheat try to weigh up the pros and cons of having one. These systems aren’t set and forget they’re constantly evolving like Anti-Virus software. If you have limited development resources you’re probably underestimating your adversaries, every time they they find an exploit in your system you’ll need to patch it. This can be on going for the entire life of your product. How much time are you willing to invest to continually update the system you have in place?
That being said over the next few weeks I’ll be looking at some simple tips and tricks you can use for your Indie project. There is no 100% effective method for stopping cheaters but there’s a few basic things you can do to make it annoying enough that they might give up and move on to something easier.
If you’re interested in reading that series make sure you head over to Patreon.com/timb3r and flick me a buck. It’s the support of the Patreons that lets me keep writing these articles for you guys. There’s lots more articles available on the site just for the Patreons too!
Special thanks to my $5 tier supporters: Alecn, Endless90 and Sik. Also a very special thanks to Icey for being an absolute madlad.