Preventing Anti-Exploit False Positives

Help and Feedback Scripting Support
#1

I am having some trouble trying to figure out the best method to detect speed exploiters. It seems like it fires a lot of false positives due to lag and such. Since they can disable local scripts, I have to use server side scripts to detect them.

-- Local Vars

local maxspeed = 22 
local checktime = 1 

local root = script.Parent:WaitForChild("HumanoidRootPart") 
local lastcf = root.CFrame

local LastTim = os.time()



--Main logic:

while wait(checktime) do
    
    local currentSpeed = math.floor((Vector3.new(lastcf.p.X, 0, lastcf.p.Z) - Vector3.new(root.Position.X, 0, root.Position.Z)).magnitude)
    local currentTim = math.ceil(os.time() - LastTim)
    
    
    if currentSpeed > (maxspeed * currentTim) then
        print("Exploit Detected: "..currentSpeed) 
        root.Parent:SetPrimaryPartCFrame(lastcf)
    end
    lastcf = root.CFrame 
    LastTim = os.time()
end

Does anyone have a better method to detect speed exploiters server side without triggering many false positives? Thanks for any suggestions :smiley:

3 Likes
#2

This is a perfect example of a machine learning problem. I considered gathering a data set for people to train on but decided to pursue other things. Here is the post if you are interested in reading:
https://devforum.roblox.com/t/features-for-detecting-exploiters-using-machine-learning/243021

Basically, each player and network may have different patterns. More than that, some latency issues may look exactly like an exploiter and an exploiter may look exactly like a laggy player. However, machine learning can still learn some valuable information and depending on the method report how sure it is that a player is exploiting. How do you design and implement these algorithms? Well, that’s the fun part I’ll leave to you.

However, there is a better way! Prevention rather than intervention. Whitelist over blacklist (don’t get me started on modern anti-virus software, I don’t use any. I recommend VoodooShield to family / friends). Maintenance vs repair. There isn’t a problem if you define appropriate ways for the client to interact with game servers. This includes their character. I’m not aware of a good server-side character implementation, but if you’d like to put forth the effort to pioneer it, many, many developers would benefit and most probably worship you.

4 Likes
#3

You’ll always get some false positives. If they lag, fall, glitch or anything similar. Unless you actually have a problem with speed exploiting and it destroys your game I would say don’t add such system.

1 Like
#4

I really love your machine learning suggestion. Definitely will take that into consideration.I think that would help reduce the amount of false positives but won’t really eliminate it. Thanks so much for your article as well on this. Very neat stuff man!

#5

Haha yeah, speed exploit is kind of a huge issue. I was just wondering if there is better methods to this whole thing to prevent it.

#6

@IdiomicLanguage’s suggestion is probably the best way to go here. However, there is another method that I remember should work. Basically, when a player sets their WalkSpeed from the client, they are labeled as running on the humanoid from the server, but when you set the WalkSpeed from the server, it isn’t labelled as running.

Not 100% sure if that works but I remember reading it somewhere.

1 Like
#7

Players can change their humanoid state and trick the server. They do not have to set their walk speed to speed hack.

1 Like
#8

That’s because a client has network ownership over their character. WalkSpeed doesn’t replicate but their position changes do.

1 Like
#9

Do not kick the player right away

The thing was speed and teleport hack detection is too not kick the player right away. Players can get flung, lag can increase the amount they move, players with a bad connection may move in jolts.

The best way to prevent speed and teleport hacks

Just teleport them back to their previous position if a exploit is detected. Players that get flung will just be teleported back. Players that are laggy may rubber band a bit, but that sacrafice is for the greater good. Normal players will experience almost nothing, and exploiters will not be able to teleport or speed hack.

You do it pretty well with this line:

root.Parent:SetPrimaryPartCFrame(lastcf)

You could kick them after a certain amount of attempts, but make it high and make sure legitimate players do not get kicked.

If you have any more questions about this, feel free to ask.

This reply was composed on a mobile device. Please ignore all typos.

1 Like
#10

Or (even faster by a few miliseconds) do
root.CFrame = lastcf

Also the reason as to why you get false postivies for walkspeed is due to ping but adding a remote function for ping can defeat the whole purpose of it I recommend you add one or two extra studs to prevent teleporting back.

#11

That is why I said pretty well. With all the constraints, moving the PrimaryPart of the character is SLIGHTLY faster.

It is not that significant of a difference, as there will be delay in server to client replication anyways.

#12

The speed difference is negligible.

Relying on WalkSpeed to detect speed hacking is pretty pointless. You should only be concerned about the displacement of the character over a span of time.

#13

I’ve seen many people use teleportation but on a laggy game with a lot of players, they would keep getting teleported back which might annoy some players.I could probably set it where it just detects a set amount of time and kill them.

Thanks for your feedback on this man :smiley:

#14

Yeah, I am trying to use velocity to calculate the actual distance globally.

#15

Since parts are network owned by the client, they could modify their velocity. Be careful, .magnitude from the previous position is better.

1 Like
#16

Thanks! You are totally right, I should definitely use position rather than magnitude.

#17

.magnitude IS based off the position. .magnitude is the unit number of studs from one position to another. What I said it your should not rely on the velocity.