Around four years ago in a large Skype group chat, I stumbled upon an administrator of a reasonably popular Minecraft server network. This encounter happened before Minecraft server networks became trendy, so this one stood out from the rest. They approached me due to my previous work on Minecraft anti-cheat and wanted to run something by me.
The Goal
The network in question was about to launch a new rank-based PvP server, and they were concerned about the possibility of cheaters ruining the experience. At the time NoCheat was the most popular anti-cheat system available, with most larger servers using it. However, NoCheat didn't have in-depth detection of aimbot cheats. They were looking to hire someone to write an anti-cheat plugin that mainly focused on detecting aimbots.
The requirements were relatively simple. Don't revert or prevent the actions done by cheaters; log them. They had diligent staff that responded nearly instantly to reports but needed a plugin that could find and report the harder to detect aimbots.
The Problem
In the community, hack clients became more popular, and private groups formed with exclusive clients that they only gave to those they trusted. This landscape differs from today where money is the only entry point to accessing the clients. These clients used much more advanced forms of aimbots compared to the others at the time and bypassed NoCheat entirely. The aimbots were still very basic compared to today's standards, however.
Getting the Clients
The first step to creating this aimbot detection system was to access what I was trying to prevent. To do this, I worked to gain the trust of the 'elitist' members by posting questions and tutorials on the forums that they frequented. I posted some tutorials on making some very basic non-harmful cheats, such as a 'Full Bright', a cheat that allows the player to see in dark caves.
I was eventually added on Skype by developers of a few of the more prominent cheat clients. After chatting, I was able to get a good selection of private cheat clients.
Decompiling the Clients
Now that I had the clients, I was able to determine how they bypassed most aimbot detections. As they were coded in Java, mostly using MCP (Mod Coders Pack), it was trivial to access the source code.
With the code, I discovered that most of these clients just used a gradual movement that tapered towards the end, rather than immediately snapping to face the opponent.
My solution to patch these aimbots was relatively simple. It calculated the movement's trajectory, checked if it was the same throughout five network ticks, and then checked for an intersection between the snapping point of any potential targets and the trajectory line. This technique is what I presume most current anti-cheat solutions for the game do.
Playing a game of 'Cat and Mouse'… With myself
It was here that I decided to write an aimbot for the game. Not to use, but to try and bypass my anti-aimbot solution. The first change that I made was to include jitter on the movement of the camera. The jitter bypassed my solution, as it no longer had a constant trajectory.
Patching my jitter bypass
Here I rethought my original solution. Instead of generating the trajectory for the first five network ticks, I tracked general movements and determined the positions that were probably the beginning and end of each camera movement. I estimated these positions based on a mixture of movement speed, and sharpness of angle change. I determined if it was an aimbot or not by smoothing the line and detected if it directly targeted a player. This solution still only worked in a motion that went straight to the target but caught small jitter quantities.
Bypassing the motion smoothing
To bypass my new protections, I made a simple modification; replacing the jitter with a reasonably flat sine curve. I came up with this solution after mapping my mouse movements when moving to targets that I had set up to appear in-game randomly. This test gave me insight into what a legitimate mouse movement looked like. When smoothed, most of my mouse movements were very flat sine curves. It was also frequent to see small amounts of overshooting when pointing at the target.
I modified my aimbot to use a general sine wave shape and slightly overshoot the target before bouncing back to the final position. This change successfully bypassed my earlier detection.
Patching the sine curve bypass
At this point, I was starting to notice a performance impact on the server. I knew I couldn't make the detection much more complicated in this regard. I made it check the smoothness of any line, basically triggering if the angles were changing predictably. I then optimized all I had done as much as possible and then went to add another type of detection.
My new detection occurred as soon as the movement started. It checked for player movement and logged the exact tick that a player became able to attack another player. It then crosschecked this with the start of movements, and if they correlated, logged it. Using this information, it tightened the other detection system's checks when it correlated with the new detection. The higher the stored violations, the stricter it was. This system did end up with false positives; however, a legitimate player should never have reached that violation level.
These changes solved both the overshooting issue and the sine wave bypass, without causing too many false positives. As moderators were manually verifying all reports, the number of false positives was deemed acceptable. I talk more about sufficient punishment thresholds in another article where I analyze forms of anti-cheat.
The Takeaway
This experience taught me to understand what I now believe to be a core tenet of security.
"It's not about making it impossible, it's about making it so hard they won't bother."
It's not possible to completely block aimbotters without punishing legitimate players severely. In my testing, this didn't pick up legitimate players enough to impact them, and it did pick up every aimbot I could find. In my mind, this was a successful project. If the system were automatic instead of requiring moderator action, I would likely have worked harder to prevent false positives. Given the requirements of the project, this system was what they wanted.
Before writing this post, I attempted to find the network that I made this for, to see if they were still using it. However, it appears the network has sadly shut down sometime since then. Due to that, I strongly doubt this aimbot detection software is in use today, making it safe to talk about publicly.
About the Author
Hi, I'm Maddy Miller, a Senior Software Engineer at Clipchamp at Microsoft. In my spare time I love writing articles, and I also develop the Minecraft mods WorldEdit, WorldGuard, and CraftBook. My opinions are my own and do not represent those of my employer in any capacity.