“Cheaters are ruining my game experience”
A sentence many have heard before. According to the Irdeto global gaming survey 60% of online players feel that cheating had a negative impact on their gaming experience [1]. Cheating can then lead to a decline in the playerbase if not dealt with accordingly.
Well then how do I deal with cheaters in my game as a developer? Pretty straightforward question with a very much not straightforward answer.
research conducted by Samuli Lehtonen [2] offers a great breakdown of different cheating methods and ways to deal with them. I am going to attempt to summarize the paper to answer that question and hopefully bring value to your game development journey.
Samuli splits the cheats into two main categories, soft cheats and hard cheats.
“Soft cheats are cheating methods that utilize game mechanics in order to gain an unfair advantage over other players.”
Why unfair if they’re part of the game? Well simply because they are not intended by the game developers. The most direct way to deal with them as a developer is to thoroughly test the game before release and patching those exploits as soon as they are pointed out by the players.
Other soft cheats such as the exchange of real money for in-game goods can be dealt with by setting up bots tracking the logs for suspicious events and possible geographic restrictions.
As this post aims to focus on hard cheats I will not expand more on the soft ones.
Hard cheats
Regarding hard cheats, here are a few examples taken from Samuli’s article : “hard cheats could be programs that edit the game client or modify the packets that the game client sends out. External cheat programs could also inject themselves into the game’s memory space and create new functionality by calling the functions of the game.”
This is usually what people think of when they hear about cheating: gaining an unfair advantage by tempering with the game system.
We can split the anti-cheat methods for game developers in two categories: server-side and client-side methods.
The first checks on the incoming packets and ensures that the data and game state are correctly handled on the server. Client-side methods on the other hand are things such as anti-cheat programs that operate on the client machine and send data back to the server.
In this post I am going to focus on the server-side methods as they are generally more resistant to tampering.
Let’s now look at four different ones to prevent cheating on the server side.
Do not trust the client
This one might seem obvious. “Of course, I am not going to trust the information sent out from the client, it could have been tampered with!” Indeed. But this one is often overlooked and presents a vulnerability if the received data is not properly verified.
Samuli warns us: “If the network traffic is not obfuscated, this type of attack can be executed just by intercepting the packets and modifying the packet data on the fly without even touching the game client itself.”
Lehtonen’s research demonstrates two protocol cases. A vulnerable one and one that is not.
In the vulnerable protocole the cheater can modify the packet on the fly. For example by grabbing the packet, modifying a didWin:false into a didWin:true and sending it to the server the player can modify the result of a battle. In the non vulnerable protocol, the game server does not trust the client except its input actions and simulates the battle on the server. One downside to this is that if the server is to run all the battle simulations, the network traffic would increase and the server would need a lot of resources to conduct all of them.
However, Lehtonen mentions that utilizing cloud computing has greatly reduced costs and made it possible to quickly deploy additional resources should they be needed. Thus there are fewer and fewer reasons to build solutions that trust the client without verification.
All in all, this is a good solution although it can greatly increase the processing power of the server. Additionally, the amount of work required to apply this to an already existing game would be rather significant. This method is best suited for more slow-pace games as they do not need to send large amounts of data continuously.
Designing a tampering resistant application protocol
Transport protocols such as UDP and TCP encompass the packet structure; what kind of data is sent in different types of situations and how the data is handled on both the client and the server.
Be aware that the cheating could happen (in theory) on any layer of the protocol stack. Here, we are focusing on the application protocol that you can affect.
TCP’s way of functioning has both disadvantages and advantages.
Due to TCP utilizing sequence numbers, if a packet is delivered unsuccessfully the next ones will get blocked. This is good because if the cheater attempts to send a replay attack by resending the packet, it won’t work. For the reason that TCP will notice that it already received a packet with the same sequence number.
Most games, however, tend to use UDP protocol in a transport layer and implement some of the TCP functionality in their own application protocols. This is commonly known as TCP over UDP.
Here is how Samuli presents it in this figure:
1) TCP-related data contains information that TCP packets normally contain such as sequence numbers.
2) Lag compensation data contains time-related information such as the time when the packet was sent by the server. This data can be utilized to make calculations about the game latency. It can also be taken into account when evaluating things such as character movement.
3) The protocol data can contain miscellaneous data that the developers have chosen to use for the protocol. For example, this can be things like data reliability hashes.
4) Game data is actual data of the packet. This can be anything related to the game such as character movement data, enemy health data or account information.
Other researchers such as Auriemma and Ferrante highlight that when searching for game vulnerabilities, the packets are
often a good place to look at [3]. For example, cheaters could edit the data in the (4) game data portion of the packet and fool the server into thinking that the player has more money. The only way to prevent tampering of the data inside the packet is to encrypt the packet.
For fast paced games these protocols even if well constructed would not be the best solution to go for and other anti-cheat methods would suit that type of games better. It can cause unnecessary delays since it continuously sends data that did not exist before thus causing latency between players. For other types of games however they would be very well suited as they are very resistant to tampering when well implemented.
TCP offers a lot of features out-of-the-box, so it can be a good choice for teams that do not have a lot of experience implementing networking solutions.
Obfuscating the network traffic
When data travels over the network, by default it is not encrypted; this means that anyone can get the data by using third party tools and understand what is transmitted over the network. This is called a packet sniffer tool and can be used in tandem with a cheating program like a “maphack” that shows the players’ positions on the map. Obviously, this can be detrimental in a first person shooter game for example.
By encrypting the data, you can block inexperienced cheaters that do not have the knowledge to decrypt the data. For those who do, one solution would be to change the encryption method every time the game receives an update, making the cheaters have to start from scratch again.
A good solution is to use well-tested encryption libraries such as RakNet [4].. It is suitable for any type of games and doesn’t suffer from other kinds of limitations such as strain on the server.
It is worth mentioning having a server authoritative approach that validates the data on the server would fix the pitfalls of encryption.
Utilizing statistical methods to discover cheaters
By collecting various types of data on the player such as number of wins, kills, deaths etc, it is possible to set up a system that could flag the player if their activity seems suspicious.
If for example the player’s kill count diverged enough from the global average of the player’s own past record. The flagged person could then be investigated by a person because statistical data alone is generally not enough to make a direct judgment.
The downside of this is that it takes a significant number of resources from the studio developing the game to set up such a system. Additionally, this method requires a huge amount of data to be effective. It is not recommended for games with a smaller playerbase.
Lehtonen says: “Overall, statistical anti-cheat methods are among the best tools to fight cheating, especially considering their high tampering resistance, low overhead, and non-invasiveness. All these are reasons why commercial data-based anti-cheat systems like FairFight and Easy Anti-Cheat are increasingly popular and preferred over the old systems that mostly rely on client-side techniques.”
Conclusion
One thing is certain anti-cheating methods keep evolving over the years as much as cheating techniques. if you are interested in seeing a benchmark of these methods, have a look at Lehtonen’s comparison:
All the credits of this post go to Samuli Lehtonen and his comparative study of anti-cheat methods. Multiplayer development is already hard enough without even considering security. So f you didn’t have much experience with anti-cheat methods, I hope this post was useful to you. If you want to learn more about anti-cheating methods for game developers, I recommend to check the full text of the thesis which is available among this post’s references. You can also get in touch with Unordinal with you need help with your security we’re always happy to help!
[1] https://resources.irdeto.com/irdeto-global-gaming-survey/irdeto-global-gaming-survey-report-2
0 