High accuracy anti walkspeed (+ noclip)

This looks great! Could you maybe put this into a model? Also where exactly do these scripts go?

You’re also using deprecated methods, like spawn() and wait(), which is not good practice if you want to post some useful resources on the devforum. You are also using _G, which is extremely terrible as a practice, since they can overlap with other modules by other creators and it all creates a huge untrackable bug mess.

Overall i’d say “almost perfect” is far from what this is, however it’s still okay if you’re just starting out.

It should be obvious, the first one will go into a Script and the second one will go into a LocalScript

Script runs on the server so that’s why they are called Server Script

LocalScript is self explanatory

1 Like

I can see that this could easily be bypassed by any exploiter who knows how to manipulate remoteevents, as you can manipulate the LocalScript loop to send false coordinates.

I’ll update it to use coroutine later but what’s wrong with wait()?
_G can overlap, I know but how else would I let every other script to get that information?

Please tell me how to improve it.

  1. You can use task.spawn and task.wait, as they now replace the old deprecated functions. Make sure you don’t use wait() and spawn() in your new scripts.
  2. Use modules.

However, the code being exploitable is still an issue and this code doesn’t work against competent cheaters.

I’m pretty confident about it being unbypassable despite it being a remote event.
If you could, make changes to the local script in a way that will bypass it.

The issue is, you seem to not understand how much power exploiters actually have and i made a thread about it some time ago, ill link it for you if you wish to read about it.

Here’s a simple breakdown of how exploiters spoof namecalls, this should make it easier to understand why your code is ineffective against them:

I know how they work, I know what they can do. This one though uses data from the client but it can’t be modified unless the client wants to be unable to play.

I think it’s not bypassable by itself.
It will only have some small bypasses (i.e slightly increased speed) when it’s made into a game.

1 Like

If i were to manipulate the localscript to send the spawnposition only, then toggle some speed exploits, would it detect me?

There is a normal magnitude check at the end of the server script, you wouldn’t be able to move 20 studs away from the saved location.

I also told in the post that they should use the _G.Location to get players location and do things with that instead of the normal .Character.HumanoidRootPart.Position things

Essentially, you can’t play the game.

Not to mention you’re moving but not sending to the servers the needed data, the anti cheat could ban you instead of tping you back

Many exploiters use delete tool and F3X, so add a whitelist script that bans everyone who isn’t white listed with f3x

this is very simple to bypass, you disable the local script and then just fire the remote yourself with spoofed details that pass the servers criteria. you could also just hook onto the localscript right before it fires and spoof the player location, many ways to bypass the localscript check atleast.

1 Like

This is a VERY bad way to make an anti-cheat. I made one a while ago that is very basic and may not be the most consistent, but does the job since you would get kicked for the time without the server receiving anything if you were laggy enough to trigger a false positive. If I were an exploiter I could literally just make a script that deleted your client side portion and replace it with a script that just pings with the position that the character was in when my script first started.

What? To detect an exploit like giving yourself tools requires a client side script that can be bypassed by using DEX (which protects itself from detection) to delete the script.

what if I want to increase the character’s speed by a power up? then?

This wouldn’t work, there’s a part of the server script that checks your character’s actual position.

Guys, it’s simple, if you’re using remote events anywhere in your anti cheat, it’s bypassable. Remote events, can be intercepted, manipulated, changed, stopped entirely, etc. Yeah this would kick them if they outright stopped it, but an exploiter can literally just fake the positional data of their character that’s being sent over the remote event. In fact all they’d have to do is change this line from this

updatecharacter:FireServer(deltatime, Player.Character.PrimaryPart.Position)

to this

updatecharacter:FireServer(deltatime, Vector3.new(0, 0, 0)) 

Now let’s look at the logic in check:
pos = (0, 0, 0)
local old = _G.Locations[p.Name] = (0, 0, 0)
((old-pos)*Vector3.new(1,0,1)).Magnitude = 0
distance > dt*p.Character.Humanoid.WalkSpeed*1.25 = false, distance is 0, the remote says they didn’t move at all
local a = pos - old = (0, 0, 0)
local direction = a.Unit*a.Magnitude = (0, 0, 0)
local raycastResult = workspace:Raycast(old, direction, raycastParams) = nil because the length of the ray is 0. Therefore the noclip check passes as well because a ray of length 0 doesn’t actually exist and will always return nil.
With both checks passing, _G.Locations[p.Name] is set to (0, 0, 0) and the process repeats

There’s no way to do these types of things in a non-bypassable way utilizing remote events.

1 Like
		for i,v in pairs(_G.Locations) do
			if (player[i].Character.PrimaryPart.Position - v).Magnitude > 20 then -- Change 20 to your allowed distance
				player[i].Character.PrimaryPart.Position = v --go ban them instead?
			end
		end

At the end of the server script, there is this, it blocks the player from moving away from saved location. There is definitely a way to just instant ban you as you’re replicating your movement on the server but not firing the remote.
Furthermore, in the post, I told people to use _G.Locations to get character position instead of doing .Character.PrimaryPart.Position to do stuff. If developers do this, it is pointless for the exploiters to do that.