Theory - Aimbot Prevention

Resources Community Resources
#1

So, I’ve been doing a bit of brainstorming about possible theory about the prevention of aimbot programs. This is theory that may help developers consider ways to avoid aimbotting on their games.

This thought was sparked personally, by experiencing how widespread such programs are in the Clans Community. And it’s understandable, you want to win, you ensure a way of winning. But it then becomes a battle of aimbots and not a fun or engaging fight, this is arguably one reason war clans have stagnated.

Now, one of my lines of thought was, how do they work? They only seem to apply once a tool or weapon is equipped, as from videos I have seen it use the in-game systems. It can be assumed, therefore, that the aimbot is not an exterior weapons system and thus, with some server side checking of client items, it could be possible to prevent an aimbot.

From what I have seen, the use of aimbot manipulates either the camera, in first person games, or the cursor in 3rd person games. This can be relatively easy to pick up by a check. Does the mouse consistently keep homed in on a players body part while moving? I mean, I’m no pro-aimed shooter, but I’d say keeping a constant aim on a body part while bunnyhopping or moving a bit fishy.

This could be identified by having the origin, the target, and the player that is being shot, be part of the RemoteEvent. This is an example of the logic:

Client: I fired a gun, this is the player part I want to damage and this is my bullet end relative to the player part.
Server: Cool, seems alright to me, your previous shot is not the same part.
Client: I fired a gun again, this is the part I want to damage and this is my bullet end.
Server: Okayyyy, you hit the same part, at the same position, dont do this again.
Client: I fired a gun again, this is the part I want to damage and this is my bullet end.
Server: Hold up! this was the same part, at the same position. You had the warning. Ban it!
Server BanScript: Ended them.

While this, at first, seems like a good system, it relies on 4 things:

  1. It is the same limb.

  2. It is going towards the same position as the last shot.

  3. There is movement by the shooter

  4. The Exploiter is unaware of the system. (Note, this is only if the checks are server side)

If a gun uses a spread mechanic, issues 1 and 2 this could be troublesome. However, a fix to this is to use another ray to pinpoint the point that the cursor is at, as well as the part the cursor is aiming at, and pass this as another element to the RemoteEvent, and use this instead.

3, is the killer issue. If the target is stationary, it makes hitting the same position of the same limb easier, if both parties are stationary, this makes it, nigh on certain, as long as you have a steady hand. Besides, in hopping backwards and forwards, the position and orientation of the limb changes, how, if its based on the user camera, do we extrapolate the “same visual position” of the limb?

4 is a question of server-client relation, from my understanding the consensus is to NEVER trust the client with anything that can effect other players. But some features are not accessible from the server side. Therefore either there needs to be obscure hierarchy of client checks, or some communication from the client that, if tampered, can prompt server side intervention. In this context, storing such monitored systems would be essential to avoid easy identification. But even if it is found, and a workaround created, it could be argued that the aimbot would therefore have to have a specific edit in place for that place.

Another avenue regarding the prevention of aimbots is keeping track of the player mouse, in theory, an organic player has to manually move the mouse, and is likely to trigger many changes in its properties in moving to its destination. Creating a magnitude check system for a mouse could be used to monitor if a player is rapidly switching from player to player, this can also be used in both third and first person games! For third person, its detecting jumps from one point to another on the entire screen, whereas for first person you would only need to calculate shifts from objects shown on the screen to the middle of the screen.

A third possible, and tried method of preventing aimbots, is to write your own camera control script. And to add checks to ensure that organic and legitimate movement is used. After all, having the camera snap to a particular point without it being coded to be able to do that is definitely behaviour that could be indicative of aimbotting.

This is the current composition on the matter, from the replies and my interpretations of scenarios posted, and is by no means conclusive nor is it neccessarily accurate, it would be best to read the replies and interpret them yourselves. If anyone else has other useful logic/code/ideas in regards to this, or even solutions to queries and thoughts in the replies, I am fully open to editing this post for the forseeable future, to help you protect your game.

42 Likes
#2

I feel like this is a pretty good idea, but if a system like this was discovered aimbot could simply avoid the system by forcing switches in bullet locations after each shot (ex: 1 shot head, 1 shot torso, 1 shot right arm, 1 shot right leg, 1 shot head, 1 shot left arm, etc…)

At the same time, they would have to be much more tailor made to each game since each aimbot script would have to be relatively synced to the weapons system of the game it is in (unless it just snaps the camera position multiple times a second as a blunt fix). But then sudden snap camera changes could be logged by client anti-exploit. But then the exploiter could delete this. Hmm…

I’m by no means an FPS scripting expert so I might be wrong. Regardless though, discussion of more theory related to this kind of stuff is awesome to see. I hadn’t considered this way of approaching the issue, and even if it turns out that this isn’t an effective patch, it’s still progress and forces reevaluation of the problem which is always a plus.

7 Likes
#3

Even if we were to go with your theory on aimbot prevention, what’s to stop HBEers (Hitbox Expanders) and RCMers? RCM can be toggled on/off and is easily concealed. Although this may not be pertinent, users will migrate from one method to the other.

3 Likes
#4

That is a good question, HBE’s would require sanity checking of the bounds of a player model, I believe. Though I hadn’t much considered either HBEs or RCM however, so I’d have to do some more digging on how they operate to give decent answers to that…

2 Likes
#5

I appreciate that you’ve taken on this topic. I’ll follow to stay updated, that is if you plan on similar releases. :slightly_smiling_face:

3 Likes
#6

From a quick Youtube of RCM, it looks like it focuses in on certain body parts, and thus would possibly trip the sanity checks that I put in my original post if it were to fire. I don’t have an in-depth understanding of how it works to really facilitate an answer there.

As to concealment and toggling, this would require knowledge of how the server checks things. If the checks are placed in an area that the client cannot easily access, such as ServerScriptService, it might be hard to evade this type of check. Plus, even if you force them to toggle, they will be forced to use actual skill and combat for a duration. While this does make it more annoying to check, it gives legitimate players a chance at least.

I do plan on incorporating more into this topic, as my understanding of client-server relationships, and understanding of how particular aimbots function increases. Hell, might even include some code if I can make heads and tails of it. :slight_smile:

Edit: Reread your comment, and provided additional response.

2 Likes
#7

Perhaps we can apply https_KingPie’s scenario here. The same may go for RCM. What could be put into place to prevent this. :thinking:

I apologize if this seems like an inquisition, I’m just curious.

#8

Just saw this! Sorry, still getting used to being able to message :laughing:

It is indeed an interesting consideration. Perhaps monitoring if the cursor snaps to particular areas of the screen for 3rd person aimbots? A mouse has to be moved organically, creating many minor position changes, so snapping from say, the top left segment to the bottom right in less than a nanosecond is VERY fishy.

Edit: Even better, if a cursor snaps to the position of a player in frame from a specified distance away, wonder if you can create a magnitude check for the cursor and screen… :thinking:

Edit Edit: Maybe this could help for first person games too! Magnitude check the elements on a screen, if it snaps to it, there’s clearly fishiness afoot!!!

I think a snag with this would be data, and a possible fringe case being somebody tabbing out and then tabbing in with a different mouse position. Still, decisions decisions :thinking:

1 Like
#9

Unfortunately if the client has the ability to execute an aimbot, they would also have the ability to cease any client-side checks. Now, even if the exploiter allowed your client script to run, an advanced aimbot would have a mode to “humanize” its movement. This would make the movement non-linear, and even overshoot its target sometimes. Which would make your checks for linearity moot. Large companies have tried tackling this problem with advanced statistical models on the server such as Fairfight, or VACnet. Even with the millions of dollars pumped into them, they’re still not nearly as effective as a human moderator.

6 Likes
#10

Wouldn’t this become a little too obvious tough? Even if you were to randomize what limb was to get hit, someone would have to get skeptical and say “now wait a minute, that shooting pattern is way too consistent.”

As for the solution presented in the original post, and correct me if I’m wrong, but your system could possibly be triggered by a false positive if a player happens to hit the same shot within the same frame (which is possible, especially for faster paced games.)

The best thing you can do is introduce variables that modify the mechanics of the weapon such as recoil, spray patterns, etc. Another solution that I have heard of but have not yet experimented with is clone the limb that is being hit multiple times, make it fully transparent, and change the position of it 20+ studs in any direction. In theory some aimbot exploits would lock on to this part and still hit it while is invisible if there is no invisibility check.

2 Likes
#11

Indeed, hmmmm. It is a tricky issue to contend with. I suppose the idea of this is, however, to remove some aimbots viability. Checks aren’t going to harm player unless it’s too unforgiving as a check.

Though it got me thinking, “human moderator”, why not make every player a moderator? Creating a server side votekick system may help deter exploiters in general, and if they get through the aimbot hurdle and the players see it is too obvious, you can use that votekick to restore your balanced playing system. In a group scenario however, it could be very difficult. Especially if there is no cooldown, multiple exploiters, and cognitive dissonance because “exploiter make me win, we keep!”

#12

That invisible cloning solution, could be quite interesting.

Maybe you need no cloned item and just hide a part somewhere under the player, and if it’s locked in on, it automatically bans the player because hitting such a part, or even aiming directly at it, would be impossible for any human without cheats or knowledge of that part to accomplish? This is good especially if they then utilise the alternating characteristic.

R15 could perhaps have given us an answer to making sure the bot is baited, why not, say, have an R6 avatar with a single R15 named part, and if the aimbot cycles through without checking it’d hit the R15 part as it is a bodypart name, and if it does check if its R6 or R15 it will notice the R15 part and set the setting to R15 shooting anyway, so it aims at it and the head…?

#13

Not necessarily.

Take Phantom Forces for example. This is ironically a bad example because Phantom Forces sort of gives the killed player insight into the camera of the player who killed them, so if they killed someone shortly after you you’d see it spaz a bit. But imagine it didn’t. A consistent shooting pattern would be hardly perceptible if the server doesn’t give you a lot of insight into the what the player’s camera is looking at. Furthermore, if the player is using a gun with a lot of recoil (AK47 or M60 for my PF homebodies) any aimbot built on randomizing body part locations is further hidden because the excuse “it’s the recoil throwing my shots over the body” becomes increasingly valid.

Moreover, (and riding with the Phantom Forces example a little further) consistency as a detection method works well in games where recoil is noticeably difficult to control (CS:GO) and/or a very new FPS game that does not have people well versed in controlling the guns. Phantom Forces has a competitive scene with teams that practice, queue up community matchmaking servers, and have an extremely in-depth knowledge of the games inner mechanics for players who have never seen the source code (simply because of play time). As a result, with more experienced players in servers coupled with a game that has manageable recoil on their weapons, consistency can be hard to use as metric for detecting or generating suspicion of aimbot.

To reply to a point @Tyanarus just made, human moderators have their limitations too. Continuing to roll with Phantom Forces (if anyone can’t tell I’m a big fan of that game) players in the competitive scene of that game (or just very highly skilled players in general) are known for very frequently getting kicked from games (because they do things that look like exploiting i.e. shooting through walls, headshot consistency, high kill games (166 kills in just this round - https://www.youtube.com/watch?v=aTcws5dGJH4), etc. That’s not to say it’s entirely ineffective, but there are many false positives that come with a system like this.

1 Like
#14

As soon as a player kills someone, position an invisible, fake character behind the player’s camera / character instantly and if they turn around and shoot the invisible, fake character within 0.1 seconds, kick them with a “You have lost connection” message. They will either fall for the same trap again or think that the aimbot is broken and complain to the person who made it.

5 Likes
#15

Hey you shouldn’t do checks like these. If player constantly moves around, the shot sometimes hit the same part but different position. I experienced this issue while playing Knife Ability Test (KAT). In my scenario, most of the aimbot’s work like locking camera in FPS. When player moves fast (like : jump or boost) they cursor of exploiter follows it but it doesn’t accurately synced with body position. But a fact is the exploiter’s cursor moves the same way as the players targeted body parts move. Now it’s a issue how to merge cursor position(Udim2) and bodyposition(CFrame). If you somehow get the Udim2 value of player’s body position and keep checking if cursor is moving exactly the same way with body parts position, then it can be prevented I guess. I think roblox should do something like this. So FPS games won’t be suffering from aimbot issues! Hope this helped. Thanks!

4 Likes
#16

Just to point out that aimbot scripts these days have improved a ton and it doesn’t just hit at the same part on the same position. I’ve scripted one personally (for private reasons and uses.)

Issue 1 and 2 would never work; no matter if it has a spread mechanic or not. The way I script it (and the other “updated, better” aimbot programs) is that it moves your mouse with a certain sensitivity. So unless that the exploiter’s going really blatant by making the sensitivity 0 (which people never do because it also might break your mouse), you can never detect Issue 1 and 2.


Look closely; it’s not a very obvious aimbot but it is infact an aimbot.
note: this script can work in both 3rd person and first person shooters.

note2: Not every aimbot is scripted my way, I’m just saying that your theories might work on the low-tier badly scripted aimbots but yes; the aimbot scripts is growing.

1 Like
#17

Transparency check is very easy to make, this would only work for very badly scripted aimbots.

1 Like
#18

I feel like this is a great idea and people could use this to prevent most aimbot and aimlocks. But the thing is most paid developers that provide premium scripts could easily find a workaround over this.

In my theory we could make it check if it was the same player and see if they hit directly onto the position of the part as there is a slim chance a real player would be able to hit directly onto the position of a part.

This is a very smart idea tho. Good job.

#19

If the solution were this easy you wouldn’t see that many cheats available and working in basically every tripple A online shooter title. There is a huge multi-million dollar industry behind detecting cheats and they are all fighting the same issue.

Be aware you are engaging in a cat and mouse game. You find a method and it will only take some amount of time before someone bypasses it again. There is no ultimate solution.

I wish ROBLOX would take a harder stance on these paid for (as in someone is making money off of them) exploits/cheats as that would certainly be a better approach than all the affected developers having to come up with hacky solutions to this problem from within an engine that severely hampers them in that regard.
ROBLOX is now big enough of a corporation to scare them off with a legal letter.

3 Likes
#20

This could lead to false detections as well as false bans, but it is still worth a try to improve it.