Most large multiplayer games sooner or later face the fact that not all users play fair. In our Warface shooter, at some point it began to be felt especially strongly. To combat cheaters, we use a whole range of solutions. One of the components of this complex is our internal development called MRAC (Mail.Ru AntiCheat). After its implementation, we achieved good results: the average number of daily cheat accounts leaving the bank fell from 17,000 at the beginning of the year to 1,500 now, despite the fact that the number of complaints from users to cheaters has decreased significantly. It now takes about 5 minutes to detect suspicious activity and blocking an account, instead of the previous 20. Now the system recognizes and responds to more than 200 signatures of cheat software and is constantly being improved.

Each game has its own specifics, and to effectively deal with cheaters, it is necessary to understand the internal features of a particular game and the tricks used in cheats. We could tell in detail about all the solutions that we use in Warface, however, having given such information to free access, we would invite malware authors to take action. While the specifics remain a secret cheaters more difficult to hide from the system. Nevertheless, the topic itself is very interesting, so I want to reveal it in more detail.

Brief background

I think many people know what IDDQD is. Throughout the history of computer games, developers have built in their offspring such codes, called cheats. Cheats allow you to become immortal, get endless ammo, resources, and more. The primary purpose of such codes is game testing. In addition to the cheats built into the game, there have always been lovers on their own to correct something in the game for the same purpose - to become "immortal." All this is good in single-player games, when a person plays with his computer and does not bother anyone. In multiplayer online games, cheating is already a problem that can ruin the whole game. If one does not play by the rules, then his rivals play is simply not interesting. Moreover, if in a shooter it is just a spoiled match, then in RPG a violation of game mechanics or bot-breeding can skew the entire in-game economy.
')
Of course, there are no embedded cheats in online games. But for almost any online game there are cheats in the form of separate applications. As a rule, cheats at launch make changes to the running game client. Sometimes changes are made directly to the client files on disk.

One of the types of cheats are bots that control the character themselves, automating routine actions. It would seem that in such bots there is nothing terrible. But actually there is. If a person sleeps, and his character kills sheep on the field automatically, gaining a gaming experience for this, then other players will be upset by this state of affairs. Some of these bots allow you to write entire scripts to control the character. Here the possibilities are limited only by the imagination of the bower driver.

Motives cheaters / botovodov:

1. "Kick ass all" for self-affirmation. Let it be dishonest.
2. Earn money. For this you need to quickly pump, collect resources, clothes, etc., then to sell it for real money.

The main motive of the authors of cheats / bots is to earn money. The best quality cheats / bots are sold by subscription for real money. There are free cheats, but they are usually filled with adware and all sorts of semi-viruses, which, again, is designed to bring money.

Let's take a closer look at how and how the cheats are done using the example of the multiplayer online shooter Warface.

Types of cheats

Any cheat somehow interacts with the game's client. To do this, the author of the cheat needs to have an idea about the internal structure of the client. The most professional chitodels get such an idea, including by reverse engineering - they find the necessary variables and restore the class interfaces. Then the class methods can be called in their own interests. The internal structure of classes in the client changes extremely slowly throughout the life of the game. After some time, this information falls into a much larger circle of less qualified chitodel and then the variety of cheats of identical functionality increases by an order of magnitude.

ESP (Extrasensory perception) - a type of cheats that can show additional information about opponents in the game. Unfortunately, the game client knows about the location of all opponents within a certain radius from you, even if they are behind the wall and cannot be seen. In a shooter, actions develop fairly quickly and if the client only receives information about the enemy from the server when he is in sight, this will certainly lead to lags due to network delays. A cheat receives information about opponents through the internal interfaces of the client's classes and displays it directly on top of the game image. This, at least, is the location of the enemy in space and the distance to it. To draw on top of the game image, a cheat intercepts one of the Direct3D methods that are invoked every frame. For example, EndScene. All this implies that the cheat code necessary for rendering was embedded in the client's memory.

Aimbot is a type of cheats for automatic aiming. You just have to run and pull the trigger, and the sight itself falls on the nearest enemy. You can even choose the part of the body you want to aim at. The location of the enemy in the space cheat also receives through the internal classes of the client. Further options are possible for automatic pickup. Or cheat directly calls the right methods in the client to rotate your character (the sight is always in the center of your gaze). Or sends a message to the client on behalf of the mouse for the same purpose.

Autoshot - automatic shot at the moment when the enemy is in sight. Such a cheat works in the same way as aimbot - it receives information about the location of the enemy through the internal classes of the client and sends a message from the mouse for a shot. Often, autoshot and aimbot are combined together. Then you just have to run, and aiming and shooting are performed by cheat automatically.

Recoil - disables recoil when fired. Such cheats, as a rule, simply patch the client's code of the game in memory, which is responsible for the return. As a result, shooting becomes much easier. In addition to disabling recoil, there is also a mass of cheats that disable various elements and simplify the game. For example, disabling scatter when firing or disabling the effect of the work of a noise-noise grenade. Some of these cheats do not modify the code, but variables in the client’s memory to achieve their goal.

Of course, this is not a complete list of existing cheats, but you can already make a list of the mechanisms of their work:

1. Modification of the game client code in memory.
2. Modification of game client variables in memory.
3. Calling methods of client internal classes directly.
4. Send messages on behalf of the mouse.

Methods of struggle

How to deal with this? Of course, the presence of a competent client-server architecture for the game is very important. But, unfortunately, this does not solve all problems. Some gameplay elements are executed only on the client side, and the server cannot detect the fact of their disconnection. And to inform the client about all opponents in a certain radius from you, the server is forced for acceptable game performance.

The first most effective way is validation on the server of player actions. For example, if a player somehow moved farther out in space than the game mechanic allows, then surely this is a cheat (speedhack), and he should be kicked immediately. Such a validation of player movements is possible, since ultimately the server controls the location of players on the map.

The second method is a statistical analysis on the server. For example, if all the player’s bullets constantly hit the enemies head, then this is very suspicious. Or not in the head, but simply without a miss. Or, say, the player’s results for the match are very much out of the average. Of course, all this is not a reason to block the account of this player. Maybe he really is very cool. However, this can be used as a trigger to closely check the player’s actions by the game’s technical support team. It should be understood that the smart cheater, most likely, will not “burn” and will not fall under the check.

Another way to fight is the built-in ability to complain about the cheater. Of course, the complaints must first be checked and then decide whether to block the account or not. But as practice shows, this method has a rather limited application. A complaint about cheating immediately becomes an element of manipulation in the game - people complain about everyone who plays better than them. The result is a huge flow of complaints, especially for experienced players.

At this, "beautiful" ways to protect against cheats end, but the problem is not completely solved. We have to contact the hanging protection of the game client.

Hinged protection

It is very painful for the game to modify the client code. For example, to disable some gameplay elements that are played only on the client side. This can be dealt with by periodically counting and checking the checksum of all of its code in memory. But this check will be turned off exactly the same way: by changing the code responsible for it. Here we need to protect the code from analysis (obfuscation) and debugging. Independent development of more or less strong code protection is a separate challenge, but there are ready-made solutions on the market.

There is no way to protect the entire code. Obfuscated code runs much slower as it gets many times larger. Only small areas of code that are not critical to performance can be protected. For example, you can just protect the checksum verification of the entire code. Of course, no code protection is a panacea. It can only complicate the task for the attacker. The goal in this case is to make the cost of hacking higher than the expected benefit.

If a code can calculate its checksum, then with variables it is already more difficult. It is necessary to invent ways to store variables that are important from this point of view in an encrypted or redundant form. And so that it does not affect performance. Again, this does not solve the problem, but only complicates the task for the attacker.

For example, at the very least, we somehow protected ourselves from modifying the client’s code and important variables. But there are cheats that do not need to modify the code or variables to work. For example, ESP. In fact, the cheat takes information from the client’s memory and displays it. But for such functionality, the cheat code must be present in the client’s memory. For this you can already catch on and go in the following ways:

1. Do not let the cheat get into the memory of the client.
2. Try to find a cheat in the client's memory.

The first path implies a ban on writing to the process memory (WriteProcessMemory) and a ban on creating remote threads (CreateRemoteThread). The usual way to inject your module into a process requires you to write it into memory and create your own thread in the process. Given that the cheat has the ability to work with administrator privileges (the cheater will always give them), then in no way should Windows be allowed to write to memory and create threads in other people's processes. You might think in the direction of creating your own driver, which will block access to the game client process. But in the Windows kernel, there are no documented ways to filter writing to other people's processes (NtWriteVirtualMemory), and the use of undocumented methods is greatly complicated by the presence of Kernel Patch Protection . Even if it is possible to block the recording in your memory, there will always be other holes: you can embed your code in the system libraries on the disk.

It is assumed that the game modules are protected and packed with code protection, and changing them on the disk is quite problematic.

The second way implies something similar to the antivirus: look for previously known fragments of cheats in the client’s memory. There are no technical obstacles here. However, it is necessary to solve the problem of promptly updating the cheat database You can go further and look for fragments of cheats not only in the client’s memory, but in the entire system. This is in case of such cheats that work in their own process, and the client is patched with code and variables or sends messages from the mouse.

There is a third way: try to find traces of interception by the Direct3D functions cheat and consider it a threat. The cheat intercepts the D3D functions to get control and render the necessary information every frame. But this option has significant problems. There is a lot of "good" software that does the same thing: it hooks the same D3D functions to draw its information over the game image. For example, RaidCall . And the task “to distinguish good software from bad” is generally unsolvable.

Of course, all this search for cheats and blocking their implementation can be turned off by modifying the code that is responsible for this. Here the only way out is to use code protection. But no matter how you protect the code, sooner or later it will break anyway. It is clear that while the application is running on the user's computer, nothing can prevent the user from changing this application. It is only a matter of time and cost justification.

Conclusion

The problem of cheating in online games cannot be solved only by improving the client-server interaction. It is complex, and it is also necessary to deal with it with complex measures. As a result, most games have additional specialized software to protect against cheats (anti-cheats), and there is a tangible sense from them. Thanks to such systems, cheaters spoil the gaming experience of other players on a much smaller scale than they could.