The fight against cheaters in online games: 22 "must" and "impossible"

It is almost impossible to find a successful online multiplayer game (except for those that are just friends of the developer) in which no cheaters. In other words, if your public game, no cheaters, she or isn't popular enough, or the detection of cheaters does not work well. In all other cases you will have to deal with cheaters. Examine the list of steps that SHOULD NOT make (for a detailed discussion of the topic of cheating is given in my three-volume book, see note at end of article) when dealing with cheating in games.

the

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

You should not just add that right, but to state that such decisions are "at own discretion". However, it can be difficult:

the

note: I am not a lawyer and this article should not be considered legal advice. Better consult your lawyer.

the

Is a complex legal problem, whose solution depends on the country or territory of stay. Don'T make the decisions on this issue alone, ask the lawyer (it is better that he was from your country), will your terms of use be considered a valid agreement in court. At GDC 2016 I spoke to someone from a large company. The biggest difficulty for them was a legal problem with a ban detected cheaters.

the point here is simple — to be able to ban players if they cheat. However, you need to formulate the terms of use so that it's clear that you don't need to prove fraud in court, otherwise the prosecution of cheaters becomes too expensive idea. The most important legal question here is "burden of proof" — do you have to prove that the cheaters are cheating, or accused cheaters have to prove his innocence. As you know, the latter is much more profitable for you and worse for cheaters. I mentioned above that one of the possible ways of solving this problem — insert the clause "such decisions are made at our own discretion". However, it is necessary to check the validity of such clauses in the relevant jurisdiction.

the

If possible, it is best to have the ability to lock players without a refund to cheat was unprofitable. But if this is not possible, then the lock money back MUCH better than not being able to block cheaters at all.
don'T worry too much about complaints of players such language in the terms of use. Most players still do not read the terms and conditions of different games they are still indistinguishable from each other for the General public. However, do NOT attempt to abuse this wording, otherwise you very quickly have a problem.

the

2. If you use engine protection party, you NEED to add on top of it as much as possible of his defense (or, even better, to combine third-party and their protection)

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

the

3. You NEED to deal with cheaters from the beginning

As soon as the community of cheaters, making money selling cheats to your game, any action on your part will cause MUCH more resistance. In other words, do NOT feed cheaters.

the

4. You NEED to use the authoritative server

This is really important. Moreover, you NEED to move all the logic to the server. In an ideal situation the client should not be making. Since this is not always possible to 100% (mostly because the games have a very high rate) you NEED to fight against every decision taken in the client. The more calculations are performed in the client, the more opportunities to the attacker. If you're not aggressively migrate all server-side, it will gradually become a Very Big Problem (I had this problem, and this topic was one report on the GDC 2016).
It is IMPOSSIBLE to adhere to the deterministic-lockstep architectures (in which synchronization occurs only sending input data). Although games with deterministic-lockstep architecture suffer less from solutions that run on the client side, they are quite vulnerable to attacks of information leakage (such as Wallhack and Maphack. Cm. article about how to restrict a client only necessary information).

the

5. NEED to encrypt traffic

Traffic encryption allows you to protect against several types of attacks, including on the basis of proxies (which is otherwise almost impossible to handle) and some bots.

Comments in this regard:

the

No, the use of UDP is not an excuse for the lack of traffic encryption. Here comes DTLS and some other protocols. the

I NEED to link the OpenSSL library statically. OpenSSL.DLL (or any other implementation of encryption via DLL) provides the attacker a guaranteed way to bypass encryption.
you CANNOT use anonymous Diffie-Hellman (Anonymous Diffie-Hellman ADH). Yes, it is written in every book, but still there are games in which developers use it (at least one game even mentioned ADH in About dialog!).
you NEED to check the saved root certificate on the client side (Yes, some developers still don't).
you CANNOT use a certificate with a machine user. Instead, create your certification authority and integrate the root certificate in the client (otherwise, increases the likelihood of MITM attacks).
Obfusticate root certificate in executable files of the client, otherwise will be subjected to another type of MITM attacks.

the

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

Find them, analyze and release fixes as soon as possible. If the game is successful enough, is to allocate a separate team.

Don't forget when analyzing cheats the following principles:

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

the

even more obviously, you CANNOT run cheats within their own network (otherwise fulfilled the dream of many cheaters). Instead, create a securely fenced firewall "sandbox" (ideally in a separate location that doesn't have a VPN between your internal network and "sandbox").

the

7. It is IMPOSSIBLE to employ known cheaters

In fact, this rule has exceptions. First, it does not concern white-hat hackers. Second, it MAY be acceptable to employ known cheaters, in compliance with ALL of the following conditions:

the

they will NOT Have special access to the "innards" of the program (especially the source code)
They must ONLY deal with "black-box hacking" (which they would do). The only difference is that they will announce the results of hacking, not to use it.
of All communication with hired cheaters NEED to maintain a separate account e-mail (completely isolated from the rest of the system).
Access to all the information of this separate account SHOULD be only in the "sandbox" configured to analyze cheat programs

the

8. You NEED to think about the politics of locks

Will you ban cheaters forever, or only for a few days? What about recidivists (at GDC 2016 said that 72% of cheaters are trying to cheat again)? What you have protection from cheaters, opening a new account (hint: F2P games on PC, such protection is almost non-existent)?

the

9. The rule of thumb is you can'T rely on players complaints on cheating

Moreover, it is to encourage players to complain about cheaters. In any case they will complain that we would be considered cheating, but a boost to complaints can easily turn a large enough number of players in paranoid. Although in some cases locking a vote MAY be required, allowing the players to throw opponents is rarely a good idea.
On the other hand, the NEED to take complaints of cheating seriously and manually reviewed information within the reports. This requires a separate team, if the game is successful. And you NEED to collect sufficient information (statistical and other) to perform such an analysis. You NEED to store such information in the database and add the query reports the anti-cheat team.

the

10. You NEED to pass to the client only the necessary information

In other words, implement a so-called system of "management interest". Any data in the client can be hacked, so the transmission of sensitive information that should not be public is a Very Bad Idea. If you do not implement the management of interests, you are almost guaranteed to put the game cheats to make transparent walls (Wallhacks) and removes the fog of war (Maphacks) and ESP-cheats (to see the health and other characteristics of the enemy).

the

11. You NEED to use a C++ client

C++ can be hacked, but I usually share the "cracking" and "full-scale reverse engineering". In my experience, although a program in C++ can be "busted" (i.e., you can find and disable a limited set of checks, and find and change a limited number of memory locations), the full reverse engineering for C++ is much more complex than C#/Java (I'm not even talking about JavaScript, without compiling Emscripten).

If we mention it, it should be noted that for this purpose Emscripten almost as good as C++. Now I cannot nothing to confirm his words, but judging from what I know it looks that way.

the

12. IN ANY CASE do not let the game with debug information inside

Do I need to explain this?

the

13. NEED to run code to filter all error messages

That is, you need to get rid of all messages that are not important to anyone except you (if you want to keep it, you can always replace their respective hashes).

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

the

14. The NEED to protect the source code of your life

If the sources leak to hackers, 99% of the obfuscation does not make sense.

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

the

15. You NEED to check the integrity of the client (including the resource and/or configuration)

This should be done at least when starting the client (ideally in the process of his work, but that's another story).

Also provide reports to be sent to the server in case of compromise of the client — if this is not a cheat, it is definitely an alarming signal.

the

16. You NEED to install the client "traps" for cheaters

Here are some typical examples of traps:

the

same value is stored twice in the memory of the client and from time to time checked for equality. For the effectiveness of such traps need to obfuscate the memory of the at least one storage location (for example, XOR with some constant, although you can implement this MUCH more difficult). If the values are not the same, then this is Very Alarming, although I am opposed to only one such mismatch was considered conclusive evidence. When the game has a million players, with some of them sometimes happen Very Strange Things.
Verify the integrity of critical parts of the code of the client and check for suspicious DLL introduced.
Measurement of code execution time to search for unusually long delays, pointing to the debug client. In this case, an interesting option is the RDTSC instruction of the x86/x64, because it often allows you to measure time even in the presence of the kernel debugger.

the

17. You CANNOT report cheaters right away that you caught him

Instead of immediately block the cheater, usually always better to postpone the ban. Personally I'm not a big fan of the "wave lock" and choose a random delay for each player, but even the waves of locks MUCH better than instant bans.

the

18. Don't forget that almost any compensation lag opens up the possibility for cheating, based on time

It is almost impossible to distinguish valid delay from made a hacked client (artificial lag). On the other hand, if you are reasonably careful, you can limit the impact of such cheating on the gameplay.

the

19. You CANNOT rely on any ways of identifying the computer

You CAN implement them, but do not forget that the identification of the computer costs are trivial (and ensure that the departments of marketing/monetization/business intelligence also knew about this, otherwise they will be relying on identification to prevent abuse of the is).

the

20. You NEED to collect statistics, which may be associated with a cheating

For example, if a player gets to occupy 5 percent of the body center of gravity of the enemy 95% of the time, you get suspicious.

Iron rule: statistics SHOULD NOT be used as direct evidence, it is only alarming. How to figure out what to do with this signal.

Last but not least, you CANNOT rely on statistics collected by the client. In other words, collect as much statistics on the server side.

the

21. You NEED to think about CAPTCHA for recognition grandama bots

One of the types of protection, good enough working against unwanted bots (usually occupied by pilot whales) is a CAPTCHA. I must admit that it's pretty annoying, but I've seen examples of how the developer explained the need for the CAPTCHA community of players, and they recognize it as "a necessary evil", it checks if the users only occasionally.

Keep in mind to make it work, it SHOULD NOT be a CAPTCHA for all, it SHOULD only be activated when you trigger one of the alarm signals.

the

22. You NEED to be ready to scan the player's computer for known cheats and

This is a rather controversial question, but rather it is necessary to implement this feature than not. For most of the game scanning the player's computer is a MUCH lesser evil than the unfettered cheating (it destroys for the players an interesting process, and therefore, kills your game).

Overall, the implementation of such scanning is very complicated (it is quite similar to writing your own antivirus), so I'll give here some tips:

the

to add to the terms of use section on the right to the scan.
it is IMPOSSIBLE to obtain any other information other than that needed to detect cheating.
If you lose to cheaters in this battle, you NEED to consider the options based on device drivers (hint: there are commercial products)
When using the scan NEED to recognize run in a virtual machine (VM often used to hide the software and there are likely to be considered disturbing)
NEED to consider TWO levels of recognition. The first level may be a simple recognition of the most obvious and popular of cheats, and should lead to a friendly message: "You're using something against the rules. No need to do this, or that...". The other level is full recognition, leading to the ban. The idea here is to stop a potential cheater before it's too late, not losing a player. I've seen examples of what this approach worked well in a fairly large multiplayer game (but then, as they say, there are no guarantees)

Conclusion

"in Order to escape the bear, you don't need to run faster than him. Enough to run faster than the person next to you."
Jim butcher

"do Not have to defend themselves against cheating 100% to save the game from cheaters. Enough to be better than their competitors".
"No Bugs" Hare

"Development and Deployment of Multiplayer Online Games"

Article based on information from habrahabr.ru

Поиск по этому блогу

computer express