41

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?

  • 3
    Readers might also be interested in Game Development. – unor Sep 12 '16 at 13:33
  • 1
    If you go full open-source (not just client-side source code), you could just have "official" servers work with unmodified clients and allow user-run servers for modified clients. – David Starkey Sep 12 '16 at 13:39
  • Anti-cheating techniques don't have to rely on closed source, otherwise how would open-source cryptographic tools exist? – Dmitry Grigoryev Sep 12 '16 at 15:26
  • 1
    Cheaters will modify the code, extract everything from data you send them and craft data to send you in any way they please, no matter, open-source client or not. – Daerdemandt Sep 12 '16 at 16:04
  • 1
    @DmitryGrigoryev - Alice and Bob can prevent Eve from listening to their communications with open cryptographic protocols. In this case Alice is talking directly to Eve, and hoping she won't look at part of the message. Cryptography can't fix that. – patstew Sep 12 '16 at 22:14
50

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.

  • 10
    I disagree that "It would be against the philosophy of Free Software". The player has the right to modify the client; it's just that it will make a program on another computer incompatible. "The freedom to run the program as you wish means that you are not forbidden or stopped from doing so. It has nothing to do with what functionality the program has, or whether it is useful for what you want to do." If the server source code is available, he/she could modify it and start another server that accepts modifications. – EMBLEM Sep 10 '16 at 15:19
  • 2
    @EMBLEM The existence of the Affero GPL and anti-Tivo clauses, both of which give end users rights over software running on computers they don't own, suggests that there are some people whose "philosophy of Free Software" is more thorough than your own concept of the idea. – Random832 Sep 10 '16 at 16:40
  • 12
    Great comment about bots' being a symptom, at least to some extent. – chrylis -on strike- Sep 10 '16 at 22:23
  • 4
    "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" -- strictly speaking, it just means that they feel losing by playing fair is more boring (less enjoyable) than winning by cheating. Depending how much they enjoy winning, that might not be very boring, it's just up against a tough opponent. And even if the game doesn't explicitly define "winning", players invent for themselves what it means to be doing well in a MMORPG. – Steve Jessop Sep 10 '16 at 23:27
  • 2
    It's in the spirit of open source that anyone can modify the client. It is not in the spirit of a multi-player game to let cheaters take part. Of course you could have one server where "cheating" is not just allowed but an expected part of the game: Which programmer can create the best "cheating" client and beat everyone else. – gnasher729 Sep 14 '16 at 8:32
45

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.".

  • 25
    Wouldn't the response to that to create bots that incorporate a fixed amount of error in their targeting? It's an endless circle, for each constraint you set, the other side will just adapt to the constraint. – ralfoide Sep 11 '16 at 0:30
  • 2
    One thing I do like in your argument as in the one from @Phillip below is the philosophy of sending the client only the info it should "see" (or have). Anything else that is sent down to the client is fair game. – ralfoide Sep 11 '16 at 0:33
  • 7
    @ralfoide For any given check, they can do that. The idea is to have many overlapping checks so that avoiding all of them either degrades the bot's performance to no better than what a player could do anyway or makes it so hard to write the bot that they go elsewhere. For instance an aimbot that has to vary exactly when it detects an enemy appearing, move the cursor and swing the view with enough randomness not to appear mechanical, vary where it aims and how much jitter it includes, is a lot more work to write. Then you have things like false targets... – Todd Knarr Sep 11 '16 at 0:46
  • 3
    @ToddKnarr I fully agree that the more constraints you add, the more difficult it becomes to write the bot. But then some folks will see this as an even more worthy challenge. For others, the motivation will largely depend on the reward. I tend to look at issues in eSports as not very different from the issues seen in real sports and Olympics. – ralfoide Sep 11 '16 at 0:57
  • 2
    The big problem with measuring stuff like "mouse cursor crossing a targets edge": it would either require the server to render parts the scene with the exact same settings as the client (which gets really slow really fast), or it will have to trust the data sent by the client (which is generally a bad idea, especially when your client can be easily modified). Trying to get someone that always tries to hit the center of the head (in a FPS) might be slightly more feasible, but then the botters will just randomize their targeting algorithm a bit. – hoffmale Sep 11 '16 at 1:23
9

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.

  • I also want to mention that some games only allow clients with the same code/scripts to connect to eachother. This is good in some cases, but won't block all types of mods and is, in my opinion, a waste of time. – gopro_2027 Sep 11 '16 at 6:15
8

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.

4

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.

  • 1
    Delving deeper into the topic of what's a cheat: there are graphics drivers that interface 3D glasses. Does that provide unfair advantage to some gamers? It helped tree dwellers distinguish between nearby vertical branches and tree trunks a bit further away, it sure does help judge the corners in a racing game even today. While VR support isn't cheap, it's at least a part of the game software. This thing could be used with anything that was rendered on the GPU (and fared rather well). – John Dvorak Sep 11 '16 at 11:10
3

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.

  • 1
    "used by a cheater for naughty purposes". Another (very reductive) way to look at it is that the game is to design a client. OK, most players are going to use the stock client with themselves as a mechanical Turk to add intelligence, meaning the only differences between their clients are the operators. That's just an implementation detail on their side. The difficult part is to design a game where you think players won't do any better than that. Then it's not that players are naughty when they automate, it's that you want to design away from that being a useful strategy. – Steve Jessop Sep 10 '16 at 23:33
2

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.

  • 4
    "the server will only accept control using a shared lib with a known signature" How would you stop a 'hacked' lib from giving the signature of the official lib? – curiousdannii Sep 11 '16 at 2:23
  • @curiousdannii He probably means a cryptographic signature, which offers integrity, authentication and non-repudiation. – 0xFF Sep 12 '16 at 14:03
  • 2
    @fhlamarche I know what a cryptographic signature is, but how does it help in this circumstance? How does the server know that what is being run is what was signed? – curiousdannii Sep 12 '16 at 14:06
  • 2
    @curiousdannii Ah, good point. I guess nothing can really stop the client from using the real lib to answer security challenges then call the hacked one for actual use. – 0xFF Sep 12 '16 at 14:09
1

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).

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.