Best way to detect this speedhack script?

The following script (CFrame speedhack) is used to bypass the old anti-cheats that detect WalkSpeed changes by constantly changing the HumanoidRootPart’s CFrame instead:

character.HumanoidRootPart.CFrame = character.HumanoidRootPart.CFrame + character.Humanoid.MoveDirection * Multiplier 
-- The higher the Multiplier, the higher the speed.

What is the most effective and optimized method for detecting this exploit while minimizing the risk of false positives, if possible? I had previously attempted a fix on my side, but it significantly increased the client’s FPS lag.

Do it on the server. Use speed-distance-time calculations to effectively calculate roughly how fast the player is moving.

local lastTick = tick()
local lastPos = HumanoidRootPart.CFrame.Position

while true do
    task.wait(1)
    local newTick = tick()
    local newPos = HumanoidRootPart.CFrame.Position
    
    local travelled = (lastPos - newPos).Magnitude
    local timePassed = lastTick - newTick

    local roughSpeed = travelled / timePassed
    print(roughSpeed) --should output a rough WalkSpeed, give or take ~15-20
end

The simplest way I can see to solve this issue is by placing a speed calculation in a local script for each client. You could run it on the server with a table checking each players’ data but it would lead to server lag (not sure how much though).

You could do this by checking to see if the player’s magnitude is above the maximum possible speed squared in the game (Not sure what the game you’ve made is)

could be something like this:

local Players = game:GetService("Players")
local RunService = game:GetService("RunService")

local player = Players.LocalPlayer
local character = player.Character or player.CharacterAdded:Wait()
local hrp = character.HumanoidRootPart

local CHARACTER_SPEED = 16
local MAX = CHARACTER_SPEED * 1.5 -- Assuming default walkspeed

local function CalculatePlanarSpeed(deltaTime)
	if MAX < Vector3.new(hrp.AssemblyLinearVelocity.X,0,hrp.AssemblyLinearVelocity.Z).Magnitude then
		player:Kick("Speedhacks")
	end
end

RunService.RenderStepped:Connect(CalculatePlanarSpeed)

The only issue with doing it on the client is exploiters could just get rid of the script. Embed it within another script and they can delete that code, no matter what they can get rid of it. You could make it harder by parenting it to nil and removing the environment reference for the script, but ultimately they can get rid of it.

It shouldn’t cause too much server lag if you do it correctly, you could always run this larger task in parallel to reduce strain on the main thread.

Thank you for your response.

In the context of Realistic Street Soccer, I might run into some false positives with this script.

  1. When there’s a kickoff, all players are teleported (client-sided teleportation) to their positions on the field. If I were to implement this script, it would detect a high roughSpeed on all players and overturn the teleportation (if we tp them back to the lastPos).

  2. If the player has a ping spike, it will detect a high roughSpeed.

Making it client-sided seems to be the best way to avoid false positives, despite being less secure.

The speedhack script does not increase the HumanoidRootPart’s AssemblyLinearVelocity. Therefore, the condition in your script will never be met.

  1. You can authorise a teleport on server.

  2. You can account for ping.

1 Like

The base script I provided was just a framework. You could use attributes or a similar method to control how it behaves in specific circumstances such as teleporting. False positives would exist on either side of the client-server boundary; the only upside to doing it on the client is you can detect when a player changes their WalkSpeed and JumpHeight. I’d recommend having a hidden, obfuscated script for this purpose of the speed hacks only.

If the player moves suddenly with their ping, it doesn’t really matter because of how the detection works, it will only take into account the total movement. It’s impossible to make the perfect anticheat, I’d also recommend a strike system and if the player gains a certain amount of strikes they get punished.

I hope this helps.

1 Like

Strike system was exactly what I was working on right now as I read your post. :raised_hands:

I opted for a client-sided version of the script you provided and it seems to work very well.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.