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.
In the context of Realistic Street Soccer, I might run into some false positives with this script.
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).
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 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.
