Any comments on my Walkspeed detection? (Exploit Speed Detection)

[rtvr56565]

Oh ok, thank you, before I didn’t know about the

@D0RYU

:GetPropertyChangedSignal

[Vran_n]

That wouldn’t work because the server cannot detect walkspeed changes on the client, which is why I am using distance to calculate how fast the player is moving.

[iGottic]

@Vran_n

Thread.Spawn(function()
		CharacterAdded(character)
	end)

This seems like an unneeded psudothread you’re spawning. The function does not yield, therefore you should not treat it as it is.

---

Now, for the code itself: it’s not great, to be honest.

There are a large number of issues, which I’ll list:

• No edge cases for different frame times – you assume the loop will be exactly 0.1 time, every time.
• A complex solution to a simple problem; use RunService instead of a loop.
• No flexibility for changes. Always make it easy for yourself, both present and future!
• Repeated code where it doesn’t need to be repeated.
• Other issues that break [programming rules](https://clone:SetPrimaryPartCFrame(cframe) clone.Parent = game.Workspace), such as improper variable/function naming, no exception handling, etc.

---

@rtvr56565

local character = -- character
while true do
   wait()
   if character.Humanoid.WalkSpeed > 16 then
      print(character.Humanoid.WalkSpeed)
   end
end

Walkspeed does not replicate across the server-client boundary. Instead, you have to find the delta between the positions to estimate a speed.

[rtvr56565]

But the client (local script) can detect the walkspeed if it’s changed in client

[dukzae]

Exploiters can easily delete the localscript, defeating the whole purpose of an anti-cheat

[minimic2002]

Just calcualte the speed the player moves at, this would anti all kinds if speed glitches and teleports, dont ban players from this though as there are still ways roblox physics can fling a player.

Speed = Distance / Time

You can also add a checker so that you can allow your own scripts to stop it or alter the speed. This means even with games where you give the players speed or teleport them they cant get around your set limits.

This means nothing will need to be on the client so it wont be bypassable either

If you look at one of my recent posts you can find how I have done it.

Anti-Exploitation Script: Need feedback on what to add or change

Anti-Exploit (Server Script)

--- Cardinal - The program that overlooked SAO --- Cardinal Set Up local CardinalSetUp = {} CardinalSetUp[1] = script:WaitForChild("SpeedLimitEnabled") CardinalSetUp[2] = script:WaitForChild("SpeedLimit") --- Create Cardinal Event local CardinalEvent = Instance.new("RemoteEvent") CardinalEvent.Parent = game.ReplicatedStorage CardinalEvent.Name = "CardinalEvent" --- Modules local DSS3Module = require(game.Workspace.Modules.DSS…

[bnxDJ (bnx)]

To add more protection you could have a client script which bans/kick the player since many exploiters are just firing random paste bin scripts and won’t be able to do anything about it. Would help if you put it inside a main client script so they can’t just find a script which is called “no walkspeed” or “anti exploit” and delete it.

[skybird_99 (SkyQuest)]

Do not attempt client always trust the server the client is in hands of the hacker the rule is
my client == my rules

to catch players use velocity checks and sanity checks
and to protect innocent players from getting banned use a code that allows you to bypass

but never try on the client if it works then it gets patched

[anon8077188]

Although your implementation is rather good, it is not foolproof. Never trust humanoid states, they can be spoofed from the client. An exploiter can change their state to Seated, Climbing, Ragdoll or FallingDown and use their advantage of network ownership to fly or use other movement-enhancing exploits.

There are methods to solve this issue, such as implementing sanity checks for each state to ensure that conditions are met and followed for each of the states, such as being able to identify how a player falls. You can also sometimes disregard the negative change in a player character’s Y coordinates as that is a simple solution to prevent falling from being tagged.

As others have stated, never rely on client anticheats. Work on your serversided checks and experiment with different concepts of being able to detect cheats and to justify normal behavior.

[bnxDJ (bnx)]

True but the “hacker” 90% of the time is running a random pastebin script and has no clue on how anti exploits work.

The client side one is only to stop the 90% and the server side is to prevent the other 10% from exploiting.

[FrigidYeti (Yeti)]

@bnxDJ

since many exploiters are just firing random paste bin scripts

This is true, to an extent.
99% of exploiters are script kiddies who don’t know what a variable is.
1% of exploiters are talented programmers who usually distribute specialised exploits for x game.

Your security will always get bypassed if there is enough need.

[RealMarcoos (invis_ck)]

What I do is listen to the humanoid state change on the server and check that humanoid walkSpeed and if any of the stats that I contain in a table are greater then they are supposed to be I ban the player. As this could get mistaken for a player who may of accidentally gotten flunged.

[skybird_99 (SkyQuest)]

Still most dont use random pastebin stuff they use scripts from a popular site known as [DATA EXPUNGED - link has been erased user can’t acess removing traces…]
which has a big community even most videos link it the codes they provide has best anti exploit breaker and help guides to help get rid of anti script if the code can’t do it automatically and you got to do it manually.

still client scripts may work but they are not the best for long term solution and dont put your anti script bulk on it

[anon8077188]

Client anticheats are a complete waste of time, it is factual that they cannot in any meaningful way prevent exploiters. The simple truth is that by developing both a client-sided and server-sided anticheat you waste time on infinite hopeless client sanity-checks which can reduce performance and disregard that about infinite methods there are to achieve advantageous behavior.
Server anticheats function very differently from client-sided ones. With serversided ones you mainly aim for logical checks to ensure that the client complies with laws of movement and Roblox physics, thus making your anticheat reliable and fairly small. The result of a good serversided anticheat is that you are practically able to stop most or all movement exploits and make your entire system unbypassable, meanwhile all client-sided anticheats can be bypassed.
The client has untold power, exploits themselves enhance this power even more. Exploits are able to manipulate property and function indexes, intercept remote events, disable scripts, alter physics and more. It is simply futile to attempt to control an environment which is way more powerful than your scripts.

[bnxDJ (bnx)]

Exactly but most exploiters don’t even know that half of that is possible.
Ofcourse it’s a waste of time making an in depth client sided exploit.
A simple ban/kick on walkspeed change for the percentage of users who can’t (or haven’t yet) bypassed it. It has to be combined with a server side anti exploit.
Just a simple if statement and boom. half of all the exploiters in your game are gone. The other half has to be warded off with server anti cheats.

[anon8077188]

I hope you realize how you’re contradicting yourself. If you have a sufficient serversided anticheat you do not need to provide “special treatment for the 80%”. It is not just a waste of time to develop an “in-depth” client-sided anticheat, it is a waste of time to make one in the first place. There is no logical reason to have one if your serversided variant is effective. The practice you’re suggesting is bloated and bad practice, simple as that.

[bnxDJ (bnx)]

I never meant to say that you should only rely on client side exploits.
There’s always going to be false positives considering lower spec devices and bad internet connections might behave suspiciously for the server side detection. In my opinion something is better than nothing.

[anon8077188]

Your assumption that “lower spec devices” and unreliable internet connections can in some way false-flag anticheats relies on assumption that your anticheat has no method to gracefully handle cases of abnormality. It is only logical that unless a check you’ve produced is extremely accurate, you should not ban or kick the player. Having a client-sided anticheat on top of a server-sided one would also not resolve this issue. Your idea also contradicts, you state that serversided ones can be partly false-flagged by unreliable connections (physics freezes, freezes mid-air), and although that’s true, in no way is having a client-sided anticheat as well going to resolve that. You will still be making the same checks on the server which can still yield the same false-flags.

[bnxDJ (bnx)]

Thanks for explaining.

in no way is having a client-sided anticheat as well going to resolve that

I was thinking more obvious changes like walkspeed being set to 100, jump power to 100 etc.
I understand what you mean but I’ve seen games get ruined by anticheats which detect false positives from normal gameplay (booga booga for example) which makes me want to reduce the possibility of them occurring. But in the process the anti exploit would probably become too forgiving.
Please don’t take this as me trying to convince you that my initial/current idea was correct but me providing my viewpoint.

[outcharm]

I would like to comment on this:

This is a common theme I see on the devforum, that client checks are useless. I know from experience that client-side checks are not totally useless, and for the most part can perform very well alongside server side anticheats. While all client anticheats CAN be bypassed (as mine have been too), most players who come through my games don’t know how to bypass these. This is a huge window of exploiters that CAN be stopped via client sided checks. There is simply some things you just can’t determine from the server. For example, in one of my games, there’s server-side checks for speed, teleporting, flying, the usual stuff you CAN tell on the server, then on the client there is additional measures. In my game, players use classic swords to fight. There is loads upon loads of ways to cheat in sword fighting that you can’t determine on the server – resize other players hitboxes, resize your swords hitbox, teleport other players body parts to the front of your sword, change your swords grip, there is countless ways of doing these things. The only method of partially stopping this on the server is by determining the distance of the two players, and setting a cap to how far the swords can damage. This is simply not enough, and exploiters will still always have the upper hand in these fights using the aforementioned exploits. This is where the client-side comes in. With my client side check, I can use a .Changed event on the sword’s size, the sword’s grip, player hitboxes, and a good bunch more. To date, this has allowed me ban ~4,000 exploiters this year, all while doing nothing. This enables me to have a smaller moderation team, a more enjoyable experience for players, and overall everyone is happy. None of this would be possible without client-side checks, so while they can be bypassed, that doesn’t mean they aren’t worth giving at least a little bit of time into making. To review exploiter reports and ban the 4,000 players it showed me would have taken a good amount of time, far more than the two hours it took to write the client-side anticheat.