Fighting cheaters in online games: 22 “must” and “cannot”

It is almost impossible to find a successful multiplayer online game (except those played by only friends of the developer), in which there are no cheaters. In other words, if there are no cheaters in your public game, it is either not popular enough, or fraud detection does not work too well. In all other cases, you will have to deal with cheating. Examine the list of steps that should and should NOT be done (a detailed discussion of the topic of cheating is given in my three-volume book, see the note at the end of the article) in the fight against game fraud.

1. Add your right to block cheaters to the terms of use.

It is necessary not only to add this right, but also to indicate that such decisions are made “at its own discretion”. However, there may be difficulties:

• Note: I am not a lawyer, and this article should not be considered legal advice. It is better to consult your lawyer.
  ')
  
• This is a complex legal problem, the solution of which depends on the host country or territory. DO NOT make decisions on this matter yourself, ask a lawyer (it is better that he is from your country) whether your terms of use will be considered a valid contract in court. At GDC 2016, I talked to a person from one large company. The biggest difficulty for them was the legal problems with the ban of cheaters discovered.
  
  
• The point here is simple - to be able to ban players if they cheat. However, it is necessary to formulate the terms of use in such a way that it is clear that you do not need to prove the fact of fraud in court, otherwise the pursuit of cheaters becomes too expensive. The most important legal issue here is the “burden of proof” - should you prove that cheaters are cheating or accused cheaters have to prove their innocence. As you understand, the latter is much more profitable for you and worse for cheaters. I have already mentioned above that one of the possible ways to solve this problem is to insert a reservation “such decisions are made at our own discretion”. However, it is imperative to check the validity of such a clause in the relevant jurisdiction.
  
  
• If possible, it is best to have the ability to block players without a refund, in order to cheat was unprofitable. But if this is not possible, then blocking with a refund is MUCH better than not being able to block cheaters at all.
  
  
• DON'T worry too much about player complaints about such language in terms of use. Most players still do not read the conditions, and when comparing the conditions of different games, they are still little distinguishable from each other for the general public. However, do NOT try to abuse this wording, otherwise you will have problems very quickly.

2. If you are using a third-party protection engine, you MUST add as much of your protection as possible (or, even better, combine third-party protection with your own)

Of course, third-party security engine developers often know what they are doing, but in the context of hacking systems with the security-by-obscurity principle, such engines become a target for the entire hacker community. Therefore, adding protection from above greatly improves your position.

3. MUST Fight Cheaters from the Start

As soon as a community of cheaters appears, making money selling cheats to your game, any action on your part will cause MUCH more resistance. In other words, it is impossible to feed cheaters.

4. NEED to use the proxy server

This is really very important. Moreover, you MUST move all the logic to the server. In an ideal situation in the client no decisions should be made at all. Since this is not always 100% possible (mainly because the games have a very high pace), it is necessary to fight against every decision made in the client. The more calculations are performed in the client, the more opportunities the attacker has. If you do not aggressively transfer everything to the server side, it will gradually become a Very Big Problem (I came across this, and there was one report on this topic at GDC 2016).

DO NOT adhere to deterministic-lockstep architectures (in which synchronization occurs only by sending input data). Although games with a deterministic-lockstep architecture are less affected by client-side solutions, they are quite vulnerable to information leakage attacks (such as Wallhack and Maphack. See below for information on how to limit the client to only the information necessary for it).

5. NEED to encrypt traffic

Encrypting traffic allows you to protect against several types of attacks, including proxy-based (with which it is almost impossible to cope otherwise) and some types of bots.

Remarks in this regard:

• No, using UDP is no excuse for not encrypting traffic. This is where DTLS and some other protocols come to the rescue.
• You need to bind the OpenSSL library statically. OpenSSL.DLL (or any other implementation of encryption through a DLL) provides an attacker with a guaranteed way to bypass encryption.
• DO NOT use the Diffie-Hellman anonymous protocol (Anonymous Diffie-Hellman, ADH). Yes, this is written in every book, but there are still games in which developers use it (at least one game even mentioned ADH in the About window!).
• You need to check the stored root certificate on the client side (yes, some developers still do not do this).
• DO NOT use the certificate from the user's machine. Instead, create your own certificate authority and embed the root certificate in the client (otherwise the probability of MITM attacks increases).
• Obfustsiruyte root certificate in client executable files, otherwise you will undergo another type of MITM attacks.

6. You need to keep track of publicly available and paid cheats

Find them, analyze and release corrections as soon as possible. If the game is successful enough, it is necessary to allocate for this a separate team.

Do not forget the following principles when analyzing cheats:

Obviously, the more popular a cheat, the higher it should be in the list of fixes.

• What is even more obvious, you can NOT run cheats inside your own network (otherwise the dream of so many cheaters will come true). Instead, create a sandbox that is securely fenced in with a firewall (ideally in a separate place that does not have a VPN between the internal network and the sandbox).

7. DO NOT hire famous cheaters.

In fact, this rule has exceptions. Firstly, it does not apply to white-hat-hackers. Secondly, it MAY be acceptable to hire renowned cheaters, subject to ALL the following conditions:

• They will NOT have special access to the “internals” of the program (especially the source code)
• They should be engaged ONLY "black-box-burglary" (which they would have already been doing). The only difference is that they will report the results of hacking, and not use it.
• All communication with hired cheaters MUST be kept from a separate email account (completely isolated from the rest of the system).
• Access to all information from this separate account MUST be only inside the sandbox, configured to analyze cheat programs

8. NEED to think about lock policy

Will you ban cheaters forever, or just for a few days? What about repeat offenders (at GDC 2016 they said that 72% of cheaters are trying to cheat again)? What kind of protection do you have against cheaters opening a new account (hint: in F2P games on a PC, this protection is almost absent)?

9. Proven rule: DO NOT rely on players in cheating complaints.

In addition, it is NOT possible to encourage players to complain about cheaters. In any case, they will complain about what they consider to be cheating, but pushing for complaints can easily turn quite a large number of players into paranoids. Although in some cases blocking by vote CAN be necessary, allowing players to throw out opponents is rarely a good idea.

On the other hand, it is necessary to take complaints about cheating seriously and manually view the information in such reports. For this we need a separate team, if the game is successful. And you NEED to collect enough information (statistical and any other) to perform such an analysis. It is necessary to store such information in the database and add reports on the requests of the anti-cheat team.

10. It is necessary to transfer to the client only the necessary information.

In other words, implement a so-called “interest management” system. Any data in the client can be hacked, so the transfer of sensitive information that should not be public is a Very Bad Idea. If you do not implement interest management, then you are almost guaranteed to expose the game to cheats that make the walls transparent (Wallhacks) and remove the fog of war (Maphacks), as well as ESP cheats (allowing you to see the health and other parameters of the enemy).

11. Must use C ++ in client

C ++ can be cracked, but I usually separate the "cracking" and the "full-scale reverse engineering". In my experience, although a C ++ program can be “grunt” (i.e., you can find and disable a limited set of checks, and find and change a limited amount of memory), full-scale reverse engineering for C ++ is much more complicated than for C # / Java (I'm not even talking about javascript without compiling emscripten).

If we have already mentioned this, then it should be noted that for this purpose Emscripten is almost as good as C ++. Now I cannot confirm my words with anything, but judging by what I know, everything looks exactly like this.

12. NEVER release a game with debug information inside.

Does it need to be explained?

13. You MUST go through the code and filter all error messages.

That is, you need to get rid of all the messages that are not important for anyone except you (if you want to save them, you can always replace them with the corresponding hashes).

I remember the case when the algorithm used was restored by an innocent message from a third-party library, and this, in turn, simplified the creation of almost a hack. Again, in the client you need to obfuscate everything, because any information issued can be used against you (yes, this is very similar to Miranda's rule ).

14. It is necessary to keep the source code as your life

If the source is leaked to hackers, then 99% obfuscation will not make sense.

In particular, if you are a big company, then divide the source code into parts so that each part is available only to the corresponding team. Among other things, it will help reduce damage from targeted phishing attacks on your team, from which it is almost impossible to defend.

15. It is necessary to check the integrity of the client (including resources and / or configuration)

This should be done at least when the client starts (ideally - and in the process of its work, but this is another story).

Also ensure that reports are sent to the server in the event of a client being compromised - if this is not a cheat, then an alarm signal is definitely given.

16. It is necessary to install in the client "traps" for cheaters

Here are typical examples of traps:

• The same value is stored twice in the client’s memory and is checked for equality from time to time. For the effectiveness of such a trap, you need to obfuscate the memory in at least one storage location (for example, XOR by some constant, although it can be implemented MUCH more difficult). If the values ​​are not the same, then this is a very alarming signal, although I am opposed to one case of such a discrepancy being considered conclusive evidence. When a game has a million players, Very Strange Things sometimes happen to some of them.
• Checking the integrity of critical parts of client code and checking for suspicious embedded DLLs.
• Measurement of the execution time of the code to search for unusually long delays indicating debugging of the client. In this case, an interesting option is the x86 / x64 RDTSC instruction, because it often allows you to measure time even with a kernel debugger.
• Another special type of trap is the honey pot. Technically, the “honey pot” differs from the usual trap in that an artificial target is created for the cheater.

17. DO NOT immediately tell Cheater that you caught him

Instead of immediately blocking the cheater, it is usually always better to put the ban off. I personally am not a big fan of “blocking waves” and prefer random delays for each player, but even blocking waves are MUCH better than immediate bans.

18. Do not forget that almost any lag compensation opens up the possibility for cheats based on time.

It is almost impossible to distinguish the actual delay from the one introduced by the hacked client (artificial lag). On the other hand, if you are careful enough, you can limit the impact of such cheats on the gameplay.

19. DO NOT rely on any means of identifying a computer

You CAN implement them, but do not forget that computer identification is trivial (and ensure that marketing / monetization / business intelligence departments are aware of this, otherwise they will rely on identification to prevent advertising abuse).

20. It is necessary to collect statistics that may be associated with cheating

For example, if a player enters an enemy’s center of gravity that occupies 5% of the body 95% of the time, then something might be suspected.

The iron rule: statistics should NOT be used as direct evidence, it is only an alarm signal. How to figure out what to do with this signal is a separate story.

Last but not least: DO NOT rely only on statistics collected by the client. In other words, collect as many statistics on the server side as possible.

21. MUST CAPTCHA THINK FOR GRINDING BOTS RECOGNITION

One type of protection that works fairly well against unwanted bots (usually occupied by a grind) is CAPTCHA. Admittedly, it is rather annoying, but I saw examples of how the developer explained the need for CAPTCHA to the community of players, and they recognized it as a “necessary evil” if she only checks users occasionally.

Consider that it works, it MUST NOT be a CAPTCHA for everyone, it MUST be activated only when one of the alarms is triggered.

22. It is necessary to be ready to scan players' computers for known cheat software.

This is a rather controversial question, but we need to implement this function rather than not. For most games, scanning the players' computers is MUCH less evil than unhindered cheating (it destroys the interestingness of the process for the players, which means it kills your game).

In general, the implementation of such a scan is very difficult (it is quite similar to writing your own antivirus), so I will give here some tips:

• You MUST add to the terms of use section on the right to such a scan.
• It is IMPOSSIBLE to receive any other information, except necessary for recognition of cheats.
• If you are losing to cheaters in this battle, you MUST consider solutions based on device drivers (hint: there are such commercial products)
• When using scan, you MUST recognize the launch in a virtual machine (VMs are often used to hide software, and they usually MUST be considered an alarm)
• NEED to consider the need for TWO levels of recognition. The first level can be a simple recognition of the most obvious and popular cheats, and should lead to a friendly message: “You use something that is prohibited by the rules. You do not need to do this, NOT THAT ... ". At the second level, full-scale recognition is performed, resulting in a ban. The idea here is to stop a potential cheater, until it is too late, if possible without losing the player. I have seen examples of the fact that this approach worked well in a fairly large multiplayer game (but here, as they say, there are no guarantees)

Conclusion

Of course, the above list is incomplete. If your game is successful, you will have to find out something new on this path yourself (sometimes it is very hard). However, here is the most important principle that has STRONGLY helped us in this regard:

“To escape from the bear, you do not need to run faster than him. It’s enough to run faster than the person next to you. ”
Jim Butcher

In our case, this can be rephrased as:

“It is not necessary to defend yourself from cheating by 100% in order to save the game from cheaters. It is enough to be better than their competitors. ”
"No Bugs" Hare

The economy of cheats (especially those sold for money) tells us that if there are two goals, one of which is very attractive, but well protected, and the other is moderately attractive, but poorly protected, commercial cheaters will definitely choose the latter. In the end, it's just a business, nothing personal.


This article briefly reviewed the subject of cheating on the basis of materials from the book Development and Deployment of Multiplayer Online Games (development and release of multiplayer online games).