Anti Cheat Solutions Over The Years
In recent months I have been absolutely fascinated by anti-cheats, especially for the game Minecraft. Players can join a server where they can interact with both the world and each other. Sadly, this opens up the ability of players to use cheats and exploits to gain unfair advantages compared to their opponents, cause harm to the game world or even the physical server and more. Since the start of server (and 3-party plugin development), software engineers have been trying their best to mitigate these issues, often with poor or mixed results.
Taking a look at various anti cheat or exploit plugins, it is clear that users (often server administrator or moderators) are not satisfied with the current state-of-the-art performance of most. Some plugins such as Grim or Spartan (both of which have been open sourced) allow for an easy drop-in anti cheat solution (from now on abbreviated as ACS). The compromise here is that such drop-in plugins most of the time lack knowledge about how to write efficient and accurate checks, albeit for movement, combat or any other type of exploit. They often fail in being optimized for performance or lack certain features that are required of an ACS.
Machine Learning Techniques
Besides this critical point of failure, most developers try to implement new and exciting ways to detect these exploits. Many developers will implement some machine-learning (ML) algorithm (due to the fact that artificial intelligence and ML are buzz words in the 21 century), but do not take into account which algorithm might perform best. For example, some ACS try and use neural networks to try and predict whether or not a player is cheating, but this bears no use since the features that can be obtained within Minecraft do not properly translate to this particular ML architecture.
This tutorial is a prime example of how not to code for a Kill-Aura check. The tutorial uses a convolutional neural network (CNN) on images that capture the movement of the mouse cursor. Based on these images one can train a network to check if the player is using a Kill-Aura exploit. While this can be effective, it is redundant. Instead of relying on a resource-hungry convolutional neural network, one can easily get away with comparing the delta movement of the mouse cursor position over time and draw conclusions from there. This mitigates the necessity of obtaining collecting sample data, training the network and than deploying it in practice.
However, it is important to realize that not every ML approach is bad! My personal point I want to make is that often the wrong techniques are being used. I often see developers use ML algorithms which are freely available in software packages such as DeepLearning4J, but they do not expand the capabilities of these libraries or take into account the available data. For example, promising techniques such as one-class SVMs, liquid neural networks, dynamic time warping, hidden Markov models (HMM) or clustering techniques are rarely used. They do however offer the greatest potential in my opinion. It is much more efficient to train a classifier which can be used to detect outliers (e.g. in movement speed, clicks per second, etc) than it is to train a neural network to predict a binary outcome. The neural network in these cases does not offer any value except compressing the data it is being fed into a latent representation on which it tries to make a prediction.
Predictive ACSs
Recently, other ACSs such as Intave or Polar have been using simulation tools to predict the movement of players. This is a relatively new approach that offers a unique view on a variety of movement exploits. For example, predicting the movement of a player can be very insightful, especially when natural movement does not correspond with observed behavior of a player, which might be indicative of cheating.
While this can provide a new way of looking at exploit detection, it is sadly not enough. Prediction of movement or other player actions can be very restrictive if done incorrectly. Since the source code of most prediction-based ACSs is not publicly available, it is difficult to determine the actual accuracy of their methods and if they actually use these predictions in a way that is supportive rather than restrictive.
Cost of ACSs
Specialized ACSs which rely on exciting new features such as ML or prediction are sadly often quite expensive. The reason for this is not because they contain a heap-load of unavailable technology but because they offer other new features such as SaaS (Software as a Service) which require monthly expenses from the developers to keep the product running.
ODIN - Next Generation ACS
It is clear that there is a need for an ACS that tries to combine all desired properties into one. In general, there are a few qualities a good ACS should in my opinion definitely have; accuracy and performance. On the one hand, if an ACS is not accurate (albeit by having a high rate of false positives or false negatives) the user is not going to be satisfied with the result. An ACS should therefor try to optimize its checks such that its accuracy is high enough. Users that do not use any exploits should not be bothered by being kicked or banned falsely. Users that do use exploits should be punished, preferably as fast as possible. On the other hand, an ACS should be a performance-oriented software package. This is especially the case on servers with a high amount of players, where each player’s data needs to be stored, checked and a decision must be made. Often this is a bottleneck many ACS currently appear to be suffering from.
This is where ODIN will come into play. The plan for ODIN is for it to be an ACS that focuses on accurate, high-performance exploit detection. As mentioned before, current ACSs suffer from a variety of issues such as accuracy, performance, cost, etc. ODIN will try to mitigate all of these. By understanding both the game mechanics and laying out a proper software foundation, ODIN will offer accurate, high-performance exploit detection. Furthermore, due to the software foundation being modular, it is easy to expand ODIN to become a cross-platform ACS.
Since ODIN is a passion project of mine, not only will it try to implement a variety of new and exciting exploit checks, it will also implement new features that are unseen on other ACSs. Currently, the plan is to allow for the following features:
- Efficient baseline checks will be a threshold before performing a more complex data analysis. This allows ODIN to focus server resources on those players that are the most likely to use exploits. A Probability-based voting system will be used to see which players will be eligible for complex analysis.
- Async checks will allow for multithreaded data analysis. This is reliefs the main thread of the server such that it can continue to handle events and keep up server TPS.
- A combination of statistics, time series analysis, machine learning will be used to optimize checks for each type of exploit. Leveraging proven existing techniques also allows to further aggregate the probability of exploits being used, rather than to give a binary answer. Profiling of players can be achieved by looking at the probabilities of using a certain exploit over time.
- Communicating data to server administrators is important. By allowing server administrators to assemble a per-player report on the various exploit probability profiles allows them to make a decision about whether a player is using exploits or not. Furthermore, ODIN will leverage knowledge gained by other ACSs in the past to provide flexible and easily manageable automatic punishment behavior.
- In some cases, data aggregation will be used to store player data. This allows for longer periods of time to be stored per player and allows for faster inference on certain metrics (e.g. instead of computing the velocity of a player for each movement update and aggregating during the check, looking directly at the average speed of a player over time is a better indicator for using a Speed exploit). Furthermore, in some cases data can be compressed to allow for even more flexibility.
- While in some cases, having too many parameters is a nightmare for server administrators (an infamous example is NoCheatPlus), ODIN will allow to tweak every single parameter. The goal is of course to remain flexible, thus separation of certain parameters will be taken care of. This allows important parameters to be easily changed, while still allowing the ability to change other parameters if necessary.
- Each parameter will be stored in a single file (which can be tweaked manually). This allows for the automatic redistribution of updated parameters, removing the need of updating the plugin each time a false positive or false negative is fixed by changing parameter values. Decoupling the software-state and parameters-state of the plugin saves time for both the developer and for server administrators.
- Encryption offers a wide variety of unseen features. For example, it is completely possible to anonymize player data and store their exploit probability profiles offline in a communal database. This would allow to notify server administrators when a player joins who was previously detected to have a high likelihood of using exploits.
How will this be achieved?
As you might have noticed, this is the first blog post about ODIN. Future blog posts about ODIN itself, as well as tactics that will be used within ODIN will be discussed and presented. Here is the roadmap for ODIN, as well as potential blog post topics:
- Create an alpha-version of ODIN which has the following basic features
- Automatically updated parameters
- Full logging, which will be useful especially during the alpha
- Asynchronous and parallel processing of events
- Efficient short-term data storage
- Event capturing/streaming
- Basic commands to allow for basic user interaction
- Beta phase where several actions are on the to-do list:
- Allow server administrators to experience ODIN to see which features they’d like to see improved, added or removed
- Allow players to test ODIN using hacked clients, which allows for optimization, removal of primary false positives and false negatives, as well as optimize parameters such as exploit threshold, probabilities, etc
- Collect and re-train necessary algorithms
- Study comparing ODIN against the most popular ACSs such as Spartan, Grim, Polar, Intake, etc.
- Release of ODIN to the public. Currently there is planned support for
- Paper
- Spigot
- Sponge
- Purpur
- Craftbukkit
Thank you for reading through this first blog post. If anything is unclear, please feel free to reach out (
Contact)!
