How can cheating be prevented in a FLOSS multiplayer game?

Question

Hacking and cheating in online multiplayer games (that use the typical client-server model) is not uncommon. For example, in some first-person shooters there are "aimbots" that allow the player's character to hit a target every time, "triggerbots" that fire whenever a player's cursor passes over an enemy, and "wallhacks" that allow one to see other players through walls.

And this is all without the source code available! Suppose that someone writes a game that uses on the typical client-server model, and wants to release it as free and open-source software. In a libre game, the players would have the right to modify their client and put all these things and worse into place, and even distribute those modified clients. Any client-side anti-cheating mechanism — for example, Valve Software's Valve Anti-Cheat (VAC), which permanently bans the player's account if it detects software hijacking the client — could be removed from it.

What strategies could the server use to ensure that everyone is playing fairly, and exclude modified clients? Could the game even be considered libre software if the server did not allow modified clients to connect?

Answer 1

I took part in the development of a FOSS online game myself. An MMORPG, to be precise. We didn't even try to prevent modified clients from connecting. Why?

1. It would be against the philosophy of Free Software. Part of the Free Software Philosophy is that users should have the right to modify the software they use.
2. It is a great way to save work. The GPL license meant that we could take the improvements the community came up with and merge them into the mainline. Outlawing client modifications on the official server would have meant to discourage community members from making such modification and even more from admitting that they made them and publishing the sourcecode. In fact at one point we even abandoned the main branch of the client and declared an unofficial community-improved fork the official one.
3. It is a great recruitment tool. The guy who maintained that unofficial client then became one of the most active members of the dev team. And he was not the only one who caught our attention by toying with the client sourcecode and subsequently could be convinced to contribute to the development officially.
4. We can't prevent it anyway. There is no bulletproof anti-cheat technology. There can't be, because whatever runs on the users machine is under their control. So whatever we could have tried, it would have be in vain.

But how do you deal with clients which give the player information they are not supposed to have?

By not sending it to the client in the first place. This is easier in an MMORPG than a first person shooter where part of the player's skill comes from spotting people hiding in concealed places and where visibility calculation is a far harder problem. Yes, that meant we had to make some concession and scrap some features which were simply impossible to implement without the clients cooperation. But there are still a lot of game mechanics which work just fine even when you have to mentally merge player-knowledge and client-knowledge.

And how do you deal with automation?

Ah, the bots. The greatest bane of our game. But not just of ours. Almost every MMO is plagued by them, including proprietary ones. One stop-gap measure is a human one: Write a TOS policy which clearly defines what forms of automation are forbidden, recruit a team of game masters from the community and have them ban all the violators by hand.

But actually, botting is usually a symptom of a far more essential problem of your game: When players feel the need to automatize some aspect of the game, that means it is so boring that they don't feel it's worth their time and so simple to do that they can program a machine to do that. Looking at which parts of your game players automatize gives you a hint to which parts you need to make more interesting and more mentally challenging.

But how about aimbots?

But what about automation which doesn't take away the dull things but assist the player in tests of reaction and dexterity which gives them an unfair advantage? I honestly know no solution to that form of cheating, except a game design solution: Just don't have such elements in your game. Design your game around tactical and strategic decision making instead of tests of dexterity.

Answer 2

Much of this is done at levels below that of the source code. Wall hacks, for instance, often work by manipulating the video card so it displays a wireframe rather than textured surfaces. Having the source code doesn't really affect this kind of cheat.

The ideal solution is to only send the client what the player can see/know. If he can't see an enemy, don't send data about that enemy. If the client doesn't have the data, no cheat can act on it. As for triggerbots and aimbots, behavioral analysis on the server side can spot them. There's an inherent error in aiming manually just because of limited pixel resolution and human reflex-speed variation. If the server spots a player hitting with more accuracy than their hardware should allow, let them shoot but ignore the shots. The same for an excessively high occurrence of firing just as the mouse cursor crosses a target's edge. Or generalize it and look for any behavior that's repetitive within closer tolerances than should be humanly possible. For instance a navigation bot will follow a straighter line and stop more precisely at a defined location than a human would be able to, so when you see a player who always nails a position mark with no error every time you're looking at a bot and not a human player. Ditto for an aimbot that always hits within a tiny tolerance of the same spot on the target's collision box no matter who/what the target is.

I would allow modified software, but make the server so that all players had to accept the same set of allowable modifications or they wouldn't be allowed to join the game. Then it's up to the players to decide what's allowable, not the game author, yet players can still exclude cheats by saying they won't accept any modifications to the client. I wouldn't do it on a specific-modification basis, more along the lines of "the players on this server will only accept clients with a minimum aiming error tolerance identical to that of the standard client" vs. "minimum aiming error of no less than X" vs. "allows 0 aiming error". Then use that for your checks: if the players agree to a minimum aiming error of X, any player exhibiting consistent aiming error of less than X is breaking the agreement and can be kicked. You don't even have to bring cheating into it, it works just as well for players saying "We have a certain skill level and we don't want to be steamrolled by players who're so good they can wipe the map with us without breaking a sweat.".

Answer 3

I am a PS3 modder and work in low level involving these mods. Here is how I would go about protecting a game from my methods.

1. You cannot prevent everything

   Any data that the client has, they can manipulate. This involves angles, player coordinates, etc. It is virtually impossible to prevent everything, but you can make it hard to do certain things with a few tricks.

2. Tricks I learned while modding GTA V

   GTA V does not give you a lot of client information. By that I mean stuff like buttons being pressed, rendering on their screen, etc. The downside of GTA is that all data is managed through one host, so you can do a bunch of other things very easily. My point is, I cannot easily control other players' coordinates or render stuff on their screen. Their client is virtually untouchable in many ways because of the lack of data about clients I receive. If you simply don't tell me things, I cannot do it. In GTA, the further you go away, the less data your game sends to me.

3. Tricks I learned while modding Call of Duty

   Almost every aspect of call of duty can be controlled if you are the host. I can render text on peoples' screens and teleport them and everything. The way you should prevent this from happening is by making the host on the Call of Duty servers rather than using a player as the host. If the code is held on the server you can filter packets being sent and make sure players don't magically change coordinates too far and stuff like that. Also, stuff like aimbot only takes a few simple things. 1. Find your players' rotation and coordinates (which can generally be found easily) 2. Find other players' coordinates. If the server does not check changing rotation then you can easily do some math to calculate the rotations to look to. To block this I would check to make sure the player isn't turning too fast on the server side and kick them if they did.

4. Tricks I learned while modding Minecraft

   Minecraft is one of the best games when it comes to modding protection. When on a server, all data is basically checked on the server side. You cannot modify your health or coordinates because it is all checked through server side. That is the ideal goal for a game.

5. Other notes

   Make it confusing. Reverse engineers like to use already built-in functions to do stuff like check if a player is visible. If you manage to make that function hard to call or don't have a function for it at all, it may take ages for the best modders to fully reverse it and get it working. At least it will give you a safe game launch. Also as a general sum up, the best thing you could possibly do is make frequent checks on the server side to make sure they are not changing values too often or other miscellaneous things. Also, learn how to, and try modding your own game. If it is easy for you to figure out it is probably easy for other people to figure out.

Answer 4

What strategies could the server use to ensure that everyone is playing fairly, and exclude modified clients? Could the game even be considered libre software if the server did not allow modified clients to connect?

I would consider two different aspects: the server software proper AND the service that I offer to the community and runs this server software.

1. the server software can use or be free or open source software and make this available in source form alright.

2. the service I offer to the players community can be subject to terms of service (TOS), such as prohibiting accessing the service with modified software that would give the players unfair advantage and would be considered cheating. That service could enforce this eventually using any mean I like including crypto for instance to ensure that modified clients are banned from accessing my service, but that would likely be hard or impossible: hence, I would likely eschew this complexity and stay with the TOS. The TOS could be a good enough way to offer a fair gaming experience and healthy community environment.

(NB: the same could apply to the client code if any) These two are not conflicting:

• someone could take my server code and start a new service and remove the anti-cheat provisions alright if they like. Or if there is no anti-cheat provisions, the service they would provide is not subject to my TOS anyway.

• someone could modify the client, but if they try to access my service, then even though the modification is allowed by the open source license attached to the code , their usage of this modified code with my service would be a violation of my TOS.

To recap:

I can have both software under a FOSS license AND restrictive TOS for the service. These are not conflicting. I could enforce in code that only authorized clients can interact with my service, though this is likely very complicated or borderline impossible and the TOS is likely enough.

Answer 5

What strategies could the server use to ensure that everyone is playing fairly,

Define unfair play: What would you consider unfair play of the following examples?

Your player is using some tool/modification to...

• help him aim and shoot at things (aim bot in a FPS)
• help with your characters skill rotation (in a RPG)
• predict/guess your opponents cards based on which cards he played (in a TCG)
• show you your opponents cooldowns and available attack moves (no genre in particular)
• give you access to normally unavailable functionality (e.g. flying or creative mode in Minecraft)

Some of these are blatantly unfair, but some (like the rotation helper) are really subtle. For example, a rotation helper might even improve the gaming experience for people with some impairment, but with some form of automated decision making it could make some boss fights trivial or allow "superhuman" reflexes in a PvP setting. Okay, rotation helpers are disallowed because of their abuse potential. Now, what about healer interfaces?

You could spend days discussing all the nuances of game altering modifications/tools and their in-game balance effects. But, there is a simple rule that is fair for everybody: Disallow any modification!

... and exclude modified clients?

This is the hard part, and so far, I know of no one who could reinforce this under all conditions. It is just too hard. (Basically, your server tries to be an interrogator in a turing test.)

The best approaches in your case (no client side anti-cheat program) are (in order of difficulty):

• verify that every client packet sent to the server contains valid values
• limiting what information is available to a client (e.g. positions of players that cannot currently be seen)
• try to detect patterns in a clients behavior

Yes, the first point should be obvious. But I think it warrants extra mention here, because it frequently gets skipped, either because of performance considerations, or because of some sort of blind trust into the client software ("Why yes, we are the only ones capable of communicating with our server." - No, you are not, especially not once someone reverse-engineered your network protocol).

The second one is also rather obvious, but can be tricky to get right in a latency tolerant fashion. Most game servers already use this in some way to save on bandwidth - but it can double as a way to make cheating more difficult.

That brings us to the last point: pattern recognition. While it is rather easy and feasible to do some easy detections this way ("that player wanted to go to those exact coordinates on X different occasions"), it can get quite hard and time consuming if the bot writers get smart about how their bots operate. To continue on the "exact coordinates" example: what prevents the bot writer to pick a coordinate in a specified area around that exact coordinate? Set a radius, add a call to rand, sin and cos and suddenly you have a circle of points instead of a single coordinate. Now add varying radii on different coordinates (depending on terrain etc), and suddenly it gets a lot harder to match that pattern. (Yes, in this case it's still possible to detect that pattern - but if you additionally vary the paths a bit, you come very close to matching human behavior).

But for all this, please keep in mind that you are trying to run a game server - you have limited CPU time and memory, and, depending on your game, you normally have tight constraints regarding latency (and maybe bandwidth). Just because some operations are possible, it doesn't have to mean they are possible while running an efficient server under those constraints.

Of course, employing GMs to monitor players and identify bots will also help, but they (as humans) have limited uptime - and who monitors the monitors?

Also, you could design your game in a way that prohibits modifications from having any real influence, e.g. think about a game like go: All information is readily available to all players, and fast reflexes don't give you any advantage, so this basically makes the major cheats unavailable. On the other hand, since go is "that simple" (not really, but still), moves can be precomputed to some level which might swing the odds in someones favor.

Could the game even be considered libre software if the server did not allow modified clients to connect?

As said earlier, with enough sophistication, it gets nearly impossible to even detect a modified client. So how would you enforce this?

Some of the anti-cheat software is basically a rootkit (or something close to that): It tries to take the control over the client's computer. While this approach might prevent simple tinkering (e.g. by comparing checksums), it still has to communicate those results to some server. And if someone is able to hijack that communication, you're back to zero.

Note that all of this is oblivious on the fact that, in your case, the source code is freely available (it just sets the hurdle higher for closed source games). Also, as mentioned in the answer of @Todd Knarr, for some kinds of exploits, you don't even need to modify the executable itself - some configuration for the graphics card or a manipulated asset can be enough to allow for some simple cheating.

TL;DR: With enough sophistication, you cannot rely on any information sent by the client, and trying to match patterns will a) cost good amounts of server CPU time and b) increase in difficulty once the bot writers learn the limits of that pattern matching algorithm.

Answer 6

The only way you can reliably prevent cheating in your scenario is keep as much information and processing as possible on the server.

Any anti cheat solution implemented on your game's client can be defeated by the client without your knowledge. For example, a system that tries to verify that a client hasn't been modified relies on the client sending a truthful response, which can't be guaranteed. That's not to say such systems are useless; a well implemented anticheat, keeping the client closed, obfuscation, etc can dramatically slow down and prevent cheating attempts. It's important to recognize, however, that these ultimately will be defeated if your game gets popular or if the wrong person or group gets interested in your game and decides develop cheats for it.

A common security paradigm is that you should never trust the client. In your context, envision a connected client as a black box you don't can't look into or control. Assume every piece of information you send is being used by a cheater for naughty purposes, and that every byte you receive from the client has been modified somehow by it. This mindset should help you identify where your design will be problematic for cheating.

Answer 7

Here's another approach: split the client in 2 parts, one that controls the core gameplay and the other one that is literally chrome around it. Distribute the first one using a typical distro mechanism in the form of signed shared libs -- the code is open and but the server will only accept control using a shared lib with a known signature. The other part of the app is chrome (settings, macros, toolbars, menus, icons, whatever) and leave this open so that the community can improve on this.

Combine this with another approach at the philosophy level: let the game have 2 modes, one competitive mode that is locked down and one open mode which is free to tinker. StarCraft II for example is a good model with a public repository of mods in multiplayer mode; in solo campaign I can play in god mode for extra ludicrous fun but that disables the achievement system (fair enough). Let the community come up with alternative gameplays and if one stand out incorporate it in the official next release.

Answer 8

If you want to do the traditional model where you distribute a binary and avoid people hacking it, you can do that easily in a FLOSS setting.

FLOSS means that you give out the sourcecode together with your binary. Nobody keeps you from compiling it, distributing the binary (together with the sourcecode) and then trying to make sure that only this binary can connect to your server. FLOSS does not require you to open up the API to just everybody.

The highlighted part in the previous paragraph is no different for FLOSS than non-FLOSS. You work with whatever mechanism you can think of - certificates etc.; it gets slightly harder because attackers have your source code, but not having the source code has never kept any attacker away.

You can use any of the existing protection schemes with your FLOSS binary. Say, you distribute your binary via Steam - the fact that it is open source does not change anything about whatever binary protection Steam has. An attacker modifying and recompiling your source is no different at all than an attacker disassembling your binary and modifying it with a low level editor (ignoring effort).

To take it further, FLOSS does not even keep you from taking money for offering the game servers. It does not keep you from having your game assets (graphics, map design, music, sounds, stories, quests - whatever) under a more restrictive or even closed license. This means you can easily make a great FLOSS source base for client/server MMOs or whatever, and still give everyone the opportunity to a) recuperate the cost of running the servers etc. and b) make it possible for games to charge money in general (for example, to pay a staff to create content).

Answer 9

It's almost impossible to verify that the client is not lying to you. Existing client-side cheat-detection systems have a limited lifetime against determined hackers. (It's like an arms race.) The only way I think it might be possible would be to use DRM to execute secret code on the client (and pass secret hashes) that cannot be emulated (faked) by a cheater.

Assuming you aren't going to take that route, there are still some things you can do:

1. Track unique players and demand investment

Require an initial investment from the player, such as a unique Facebook or Google account, or captcha and email address. Require them to always use that account to play.

If you later find them to be cheating, you can ban that account, and they will lose any items, experience, stats and reputation associated with it. They would then have to start from scratch with a new initial investment.

Furthermore, all brand new (0-day) players can be considered low-trust until they have invested some time/effort in playing. Low-trust players could have certain limitations (e.g. reduce spammers by limiting messages per second). StackOverflow uses a similar mechanism: privileges increase as reputation/experience builds.

This won't stop all cheaters immediately in their tracks, but it will increase the costs/risks associated with cheating.

2. Segment players according to their ranking

Track players to establish their skill level, and have them play in arenas with players of a similar ranking.

As a result, the bots with unrealistically high performance will simply end up playing each other.

This won't prevent the cheaters from using your server, but it will keep them away from the regular players. (Or at least indistinguishable from regular players.)

One side-advantage of this is that new players will not have to face up against strong players until they have learned the game and their skill level has improved.

But it's a disadvantage if you want strong and weak players to play side-by-side or against each other.