Protection against cheating in online games
This is an article about how we made the HTML5 browser protection system for games against hacking and falsifying results, what difficulties we encountered while doing this, how we solved them and what we got in the end. The main and all familiar problem of such games is the possibility of writing a bot that this game will automatically pass. The development of such a bot is facilitated by the fact that the game code is in the public domain. The situation was complicated by the fact that real prizes were announced, including the iPad, concert tickets, USB flash drives, etc.
The article will be useful mainly to those who make HTML5 / Flash games and care about their safety; those who pay to develop these games; and some to those who are called upon to fight bots. And, of course, those who wrote this article. Because we hope that it will be the beginning of a productive discussion about how browser game developers can resist cyber-fraudsters.
A little about the game itself.
Unfortunately, the game itself, we can not show at the request of the customer. Despite all the techniques described below, unfortunately, “ignorance” is a key element of protection. That is, the disclosure of methods in relation to a particular game will significantly reduce their effectiveness.
We are web developers, but we haven't been involved in game development before. At the very beginning we gave birth to many funny solutions. For example, we made an important architectural error - we decided to generate a level on the client in the browser; and as a defense relied on obfuscation of JS code. True, comrades from neighboring departments said that for quality protection they would have to “play” the game on the server and compare it with the client. But we laughed then, that this is very difficult.
')
I repeat that the main requirement was to provide anti-cheat protection. But our team decided to first make the game work in principle. And the development of protection was postponed later. It seemed logical: first we do something, and only then we defend this “something”.
As soon as we started to engage in protection, we immediately faced the basic problem of all browser games arising from the client-server architecture. Namely: the player sees the entire client code of the game and cannot blindly trust the data that came to the server. If we are able to manage the second part of the problem, then the possibility of analyzing and changing the source code by any user really puzzled us.
We started with a simple solution - obfuscation of JS code and data encryption sent by the client to the server. But the customer had a killer security team, which in 15 minutes was able to record an unreal game score, having a fully obfuscated code. Encrypting data during transmission is also not an option - the keys lie with the client, and you can easily substitute them in the right place. So, in fact, both of these decisions proved effective only for very lazy hackers.
Moreover, Flash games are also subject to such reverse engineering, and those developers are also looking for a protection solution.
The situation was complicated by the fact that our game has real prizes. In this case, its hacking has passed from the category “hack for fun” to the category “hack for money”. This game is more than attractive to specialists of a higher class than the “novice hacker”.
Despite the fact that a lot of online games have already been developed, very little information has been found on how to deal with their hacking. Here are some recommendations we have learned from the Internet:
We brainstormed and also developed a lot of ideas. Were successful, and were not very. For example, the output of CAPTCHA “before”, “during” and “after” the game can be classified as not the most successful. Or, say, receiving screenshots during the game and sending them to the server for verification. The following describes the most interesting of the implemented methods.
After much deliberation and resistance to a complex decision, we came to the conclusion that playing (emulating) the games on the server is clearly a necessary thing. If not to say - inevitable.
To do this, we began to generate a game (the location of bonuses and obstacles) on the server and
send to the server not the final result of the game, but only the events that occurred in it: collisions with obstacles, bonuses and keystrokes. For each event, we knew the time, coordinates, keystrokes or bonuses / obstacles that the player encountered.
There was an option to send only keystrokes, and on the server to calculate the result at the end of the game. But we are faced with the problem of different game speeds on different devices and in different browsers. The probability of a strong discrepancy in the game process on the client and on the server is high, since this method is very sensitive to inconsistencies. For example, if suddenly the client does not send just one collision with an obstacle, then the emulated game will go completely differently from now on. Indeed, in collisions, energy and speed are lost.
Another option: handle events on the server and immediately send the results of the event to the client. But at the same time there is a very large traffic between the server and the client, the response time of the game increases and the server load dramatically increases. This is how MMO games work, for example. But for a small Collect & Run game, we considered this impractical.
I would particularly like to note the fact that the devices on which the game was launched had different performance. On fast devices, the game went smoothly, on slow ones - in spurts. Because of this difference, we had to abandon the time reference during emulation. Instead, we viewed the events of the game as something that happens in some coordinates. For example, at first we considered the jump for the bonus as “pushing the button up at the 10th second, clashing with the bonus at the 12th second”. But we are more approached by the following: “pressing the button upwards with the X-coordinate of the player equal to 1000, collision with the bonus with the X-coordinate of the player equal to 1100 and the Y-coordinate of the player equal to 300”. In this case, both the fast and the slow devices were emulated more or less equally.
As a result, after the game we decided to emulate on the server each event sent by the client, and additionally calculate the probability of its occurrence. One of the tasks that we solved was the creation of identical collision calculation algorithms on the server and on the client. It was necessary to achieve the same accuracy, including rounding.
As a result of the work of the emulator, we receive on the server a sequence of game events in the same form as in the actual game. After emulating the events, we turn to an analysis of what we did.
This is the most interesting block. Here are collected the most successful methods of detecting cheaters. All of them are different, run in sequence, you can add more if necessary.
Each method has its own weight in the calculation, the value of which is adjusted. By the way, it makes sense to put into the settings the maximum possible number of parameters. For it is not clear in advance how sensitive or rough this or that algorithm will turn out in reality.
During operation, the analyzer sets each method with values ​​from 0 to 1 (0 - the game is beyond suspicion, 1 - the test is completely failed) and at the end it calculates the “Suspiciousness Index of the game” (also from 0 to 1).
This index is used to automatically tag the game. If it is greater than the threshold, then the game is considered hacked. The specific threshold value is selected empirically, we got it 0.4.
But that is not all. We must do something with all these calculations. It is one thing to program the algorithms described above, and another to submit the results of the work to the game administrators in a readable form. Blocked for hacking a player can apply for support with complaints, and they must have proof of the decision. Therefore, it is recommended that administrators be given the maximum amount of information so that they understand and justify why a particular game was identified as hacked.
To do this, we made 4 pages in the admin panel.
By the time the game was launched, we did not have time to automatically block suspicious users. This would greatly simplify the work of the game administrators, since the person is not able to view thousands of suspicious games in a day.
Analyzing the top players a few days after the launch of the game was very entertaining. One hacker followed a simple path and collected all the elements, but he never jumped. He also collected all the “false” elements. Another “champion” has evolved consistently. At first he had about ten fair games, then - a lot of “empty” ones. And in the most recent games, the suspicion index was overwhelming. Some “winners” went through the game in less than 10 seconds. Some people played the game only once and immediately hit the top. This, by the way, can be used as an analyzer method - very few people are able to make the maximum from the first time. There were “champions” in one second, gaining an unrealistic number of points. And so on. All of them were blocked and were not allowed to real prizes. No complaints from them.
After reviewing dozens of real games, we updated some of the threshold parameters upwards. For example, the maximum index value of a game’s suspicion, when a game is considered hacked, can be increased. In other words, the initial settings were very suspicious.
In reality, we received a positive result of this system. Strongly helped to understand the display of results in the admin panel. In general, it can be said that the system proved to be quite viable, the customer was satisfied.
When defending against the account we used the data of only one game and tried to catch it on internal discrepancies. We proceeded from the fact that the game is completely vulnerable: all source codes are available to the player, and the incoming data is unreliable. But the game has a part that is inaccessible to hackers - this is the data of all games. There is an assumption that correctly using a database played by thousands of players, you can improve the accuracy of determining hacking. Now we believe that the database of game results is the main advantage of developers over hackers.
What do you think, habrovchane? Share your thoughts and approaches to the protection of online games.
The article will be useful mainly to those who make HTML5 / Flash games and care about their safety; those who pay to develop these games; and some to those who are called upon to fight bots. And, of course, those who wrote this article. Because we hope that it will be the beginning of a productive discussion about how browser game developers can resist cyber-fraudsters.
What game is this?
A little about the game itself.
Unfortunately, the game itself, we can not show at the request of the customer. Despite all the techniques described below, unfortunately, “ignorance” is a key element of protection. That is, the disclosure of methods in relation to a particular game will significantly reduce their effectiveness.
- Game type: Collect & Run.
- Examples: a familiar Mario Bros. and his clones
- Duration of the game: about 1-2 minutes.
- Purpose of the game: to score the most points.
- The main elements of the game:
- Character.
The main character is always moving. Can bounce and duck to collect bonuses and avoid obstacles. - Bonuses
Can increase points or speed of movement of the character. In order to collect them, the character must jump. - Obstacles.
Barriers or moving towards the character objects. In order to avoid them, the character must duck or jump. When confronted with an obstacle, the character loses speed.
- Character.
- Characteristics of the game used in calculating the result of the game:
- Points scored. Increase when collecting bonuses.
- Character speed Decreases with time. Decreases when confronted with an obstacle. Increases when collecting bonuses.
- Time spent on the game.
- Used technologies:
- Client: HTML5. Reason: the game was required to run on all devices. JS-framework: Pixi.js ( http://www.pixijs.com )
- Server: PHP, Framework: Zend
- The goal of the customer: advertising your brand through the game. Gameplay was associated with the company's services; logos, brand colors and all that stuff in stock.
- The game was launched for a certain period, after which the players with the best results were awarded valuable prizes.
- Based on the above, the customer immediately emphasized that the game should be protected from falsifying results. The customer values ​​the reputation. He didn’t want the news to appear in the media that their branded game had been hacked.
What kind of team?
We are web developers, but we haven't been involved in game development before. At the very beginning we gave birth to many funny solutions. For example, we made an important architectural error - we decided to generate a level on the client in the browser; and as a defense relied on obfuscation of JS code. True, comrades from neighboring departments said that for quality protection they would have to “play” the game on the server and compare it with the client. But we laughed then, that this is very difficult.
')
I repeat that the main requirement was to provide anti-cheat protection. But our team decided to first make the game work in principle. And the development of protection was postponed later. It seemed logical: first we do something, and only then we defend this “something”.
The problem
As soon as we started to engage in protection, we immediately faced the basic problem of all browser games arising from the client-server architecture. Namely: the player sees the entire client code of the game and cannot blindly trust the data that came to the server. If we are able to manage the second part of the problem, then the possibility of analyzing and changing the source code by any user really puzzled us.
We started with a simple solution - obfuscation of JS code and data encryption sent by the client to the server. But the customer had a killer security team, which in 15 minutes was able to record an unreal game score, having a fully obfuscated code. Encrypting data during transmission is also not an option - the keys lie with the client, and you can easily substitute them in the right place. So, in fact, both of these decisions proved effective only for very lazy hackers.
Moreover, Flash games are also subject to such reverse engineering, and those developers are also looking for a protection solution.
The situation was complicated by the fact that our game has real prizes. In this case, its hacking has passed from the category “hack for fun” to the category “hack for money”. This game is more than attractive to specialists of a higher class than the “novice hacker”.
Tips from the Internet
Despite the fact that a lot of online games have already been developed, very little information has been found on how to deal with their hacking. Here are some recommendations we have learned from the Internet:
- Hide, protect and encrypt game data:
- The variables responsible for the game account should not be made in the global scope. They are recommended to declare private and put in closures (closure).
- Do not send invoice values ​​in clear text, but be sure to encrypt.
- Encrypt addresses (uri) to which the account is transmitted.
- Obfucirovat part of the code that is responsible for calculating and sending invoices.
- Send license keys along with the game results and check them on the server.
- Pros: relative ease of implementation
- Cons: as it was written above - hacked in 15 minutes
- Fool hackers:
- When a cheat account is detected, the result is still shown to the hacker in the list of records. Let him think that the deed is done. But other users should not see this.
- When a game is defined as hacked, then postpone the punishment for a random period (for example, from 1 to 3 days). The hacker will use several methods and periodically he will see what he does. But what exactly turns out to understand him will be difficult, and what exactly he was caught in the end - too.
- Check the realism of game data:
- Check on the server the theoretical possibility of sending values. For example, the energy can not be negative, the score can not decrease, the position of the player always increases, etc.
- Send game data to the server and compare data with the same data from other users. For example, if a player made 200 shots and reached a score of 200,000, while the remaining players, after making 200 shots, reach a score of 5000, this is a reason to doubt the integrity of the game.
- Delete games that lasted less (more) than a certain time.
- Pros: relative ease of implementation
- Cons: does not give full protection, adds an extra 5-10 minutes to organize hacking
- Organizational impact on accounts:
- Add importance account, so it was a pity to lose it. For example, to play this game with real prizes, you must first achieve something in other games without prizes.
- Make account registration paid.
- Ban on IP hackers at the very first attempt of hacking. Do not give them the opportunity to understand.
- Emulate the game on the server:
- Make 'instant replay' on the server. After passing the level to send data, which are restored events in the game and re-calculates its result. Then this is all compared with what the player sent, and if the difference is big, then this is a hack.
- Pros: gives a greater degree of protection
- Cons: Events sent at the end of the game can also be tampered with.
We brainstormed and also developed a lot of ideas. Were successful, and were not very. For example, the output of CAPTCHA “before”, “during” and “after” the game can be classified as not the most successful. Or, say, receiving screenshots during the game and sending them to the server for verification. The following describes the most interesting of the implemented methods.
Emulator games
After much deliberation and resistance to a complex decision, we came to the conclusion that playing (emulating) the games on the server is clearly a necessary thing. If not to say - inevitable.
To do this, we began to generate a game (the location of bonuses and obstacles) on the server and
send to the server not the final result of the game, but only the events that occurred in it: collisions with obstacles, bonuses and keystrokes. For each event, we knew the time, coordinates, keystrokes or bonuses / obstacles that the player encountered.
There was an option to send only keystrokes, and on the server to calculate the result at the end of the game. But we are faced with the problem of different game speeds on different devices and in different browsers. The probability of a strong discrepancy in the game process on the client and on the server is high, since this method is very sensitive to inconsistencies. For example, if suddenly the client does not send just one collision with an obstacle, then the emulated game will go completely differently from now on. Indeed, in collisions, energy and speed are lost.
Another option: handle events on the server and immediately send the results of the event to the client. But at the same time there is a very large traffic between the server and the client, the response time of the game increases and the server load dramatically increases. This is how MMO games work, for example. But for a small Collect & Run game, we considered this impractical.
I would particularly like to note the fact that the devices on which the game was launched had different performance. On fast devices, the game went smoothly, on slow ones - in spurts. Because of this difference, we had to abandon the time reference during emulation. Instead, we viewed the events of the game as something that happens in some coordinates. For example, at first we considered the jump for the bonus as “pushing the button up at the 10th second, clashing with the bonus at the 12th second”. But we are more approached by the following: “pressing the button upwards with the X-coordinate of the player equal to 1000, collision with the bonus with the X-coordinate of the player equal to 1100 and the Y-coordinate of the player equal to 300”. In this case, both the fast and the slow devices were emulated more or less equally.
As a result, after the game we decided to emulate on the server each event sent by the client, and additionally calculate the probability of its occurrence. One of the tasks that we solved was the creation of identical collision calculation algorithms on the server and on the client. It was necessary to achieve the same accuracy, including rounding.
As a result of the work of the emulator, we receive on the server a sequence of game events in the same form as in the actual game. After emulating the events, we turn to an analysis of what we did.
Game analyzer
This is the most interesting block. Here are collected the most successful methods of detecting cheaters. All of them are different, run in sequence, you can add more if necessary.
- Collision coordinates.
A collision with an obstacle or a bonus occurred in the browser on the client at the point where this item was generated on the server. - Increase character position.
The position of the character in the game should increase with time. It cannot decrease or remain the same. - The character has reached the end of the level.
The maximum character position does not exceed the length of the level generated on the server. - Duration of the game.
The level is physically impossible to pass in less than one minute. Therefore, games that have passed in 30 seconds or 2 minutes are considered hacked. - Control of speed and energy indicators.
The values ​​of the indicators in the browser on the client should be related to game events (collection of bonuses, collisions with obstacles). When taking some bonuses, the character's speed increases, when confronted with obstacles, it decreases. Also, the collection of some bonuses increases the number of points gained by the player. Knowing what items a player has collected, you can calculate on the server what values ​​he should have: speeds and total points. - Jump before taking the bonus.
Bonuses hang high to make them a character must jump. Here it is checked whether there was a jump before taking. - Jump before the obstacle.
In order to avoid a collision with an obstacle lying on the ground, the character must jump. For each obstacle, we check whether the player jumped up to the obstacle (pressing the jump button) and blocked his jump trajectory. - The correct keys.
Check the pressing of certain keys: “up” and “down”. If something else was pressed, it is suspicious. - Bonuses and obstacles are collected once.
The user can collect one bonus (or obstacle) no more than once. - Clashes on the client.
Comparison of collisions that occurred in the browser on the client and received on the emulator. - Clashes on the emulator.
Comparison of collisions that occurred on the emulator, but did not occur in the game. This method is introduced in order to have different weights of this and previous methods. We thought that if there is a collision on the emulator, but not in a real game, then it is less suspicious than when there is a collision in a real game, but not on the emulator. - Taking false items.
When generating the game, we added a few bonuses, which are impossible to take in the game. For example, they are slightly higher than the character can jump; or there are two bonuses that are nearby, but physically you can only collect one of them. And we check if the hacker got hooked and took these bonuses. - Fingerprint analysis.
Before the start of the game during registration and player login, we collect information about the client (browser plugins, http headers, ip, installed fonts, screen size and color). This does not help us to understand whether the game was hacked. But in the case when administrators mark a player as a hacker, the analyzer scans all players in the system and finds similar “fingerprints”. Thus, it is possible with a certain probability to detect hackers who try to break the game under one account, and play “purely” under another.
Each method has its own weight in the calculation, the value of which is adjusted. By the way, it makes sense to put into the settings the maximum possible number of parameters. For it is not clear in advance how sensitive or rough this or that algorithm will turn out in reality.
During operation, the analyzer sets each method with values ​​from 0 to 1 (0 - the game is beyond suspicion, 1 - the test is completely failed) and at the end it calculates the “Suspiciousness Index of the game” (also from 0 to 1).
This index is used to automatically tag the game. If it is greater than the threshold, then the game is considered hacked. The specific threshold value is selected empirically, we got it 0.4.
Administration of evidence
But that is not all. We must do something with all these calculations. It is one thing to program the algorithms described above, and another to submit the results of the work to the game administrators in a readable form. Blocked for hacking a player can apply for support with complaints, and they must have proof of the decision. Therefore, it is recommended that administrators be given the maximum amount of information so that they understand and justify why a particular game was identified as hacked.
To do this, we made 4 pages in the admin panel.
- Game Information - Emulator
Table with real and emulated events of the selected game. The columns are as follows:- element type (bonus, barrier)
- Element X and Y Coordinates
- client time
- X- and Y- coordinates of the character (on the client)
- fact of collision of character and element (yes, no)
- X- and Y-coordinates of the character (emulated)
- probability of collision at a specified time on the client
- Game Information - Analyzer
The overall index of suspicion of the game and the table with the results of the analyzer for each method. - Analyzer
Shows a table of all suspicious games in general, based on the threshold of suspicion (0 - no suspicions, 1 - just hacked). By experience, we have a value of 0.4. - Player Page
They added a player suspicion index to the player profile. It is calculated on the basis of the suspicious indices of all his games.
By the time the game was launched, we did not have time to automatically block suspicious users. This would greatly simplify the work of the game administrators, since the person is not able to view thousands of suspicious games in a day.
How did everything go
Analyzing the top players a few days after the launch of the game was very entertaining. One hacker followed a simple path and collected all the elements, but he never jumped. He also collected all the “false” elements. Another “champion” has evolved consistently. At first he had about ten fair games, then - a lot of “empty” ones. And in the most recent games, the suspicion index was overwhelming. Some “winners” went through the game in less than 10 seconds. Some people played the game only once and immediately hit the top. This, by the way, can be used as an analyzer method - very few people are able to make the maximum from the first time. There were “champions” in one second, gaining an unrealistic number of points. And so on. All of them were blocked and were not allowed to real prizes. No complaints from them.
After reviewing dozens of real games, we updated some of the threshold parameters upwards. For example, the maximum index value of a game’s suspicion, when a game is considered hacked, can be increased. In other words, the initial settings were very suspicious.
In reality, we received a positive result of this system. Strongly helped to understand the display of results in the admin panel. In general, it can be said that the system proved to be quite viable, the customer was satisfied.
Conclusion
When defending against the account we used the data of only one game and tried to catch it on internal discrepancies. We proceeded from the fact that the game is completely vulnerable: all source codes are available to the player, and the incoming data is unreliable. But the game has a part that is inaccessible to hackers - this is the data of all games. There is an assumption that correctly using a database played by thousands of players, you can improve the accuracy of determining hacking. Now we believe that the database of game results is the main advantage of developers over hackers.
What do you think, habrovchane? Share your thoughts and approaches to the protection of online games.
Source: https://habr.com/ru/post/252699/
All Articles