High accuracy anti walkspeed (+ noclip)

Resources Community Resources
#24

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.

#25

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.

#26
  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.

#27

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.

#28

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.

#29

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

#30

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
#31

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

#32

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

#33

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

#34

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
#35

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.

#36

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.

#37

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

#39

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

#40

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
#41 
		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.

#42

I have some experience with exploits and I can say this won’t work. InfYeild comes with a remote spy. It can read and modify remotes. For instance it can block remotes with stop remotes from firing. And with some code you can make a speed modifier. It will just block the script and fire every now and then. It is not the easiest but it could work.

#43

This would work, but there is a loophole in which the creator can make. Even if you do manage to do it, running a sanity check on the server could work. Hell, just not even using the remote could work. You could then kill two birds with one stone.

#44

The remote exist so that ping doesn’t matter. Normally developers do checks purely on the server side which is affected by ping so the allowed distance is usually very high. While with this method, the allowed distance is very low as ping doesn’t matter, it limits more cheats than a normal check on the server would do.
i.e, autofarming. Exploiters usually use tween (with like 2x the normal speed) to somewhat bypass the check on the server as the allowed distance is very high. With this, they can only use tween with the base speed (or slightly higher) to do so.

Stopping the remote from firing and then fire with their own settings once in a while is indeed very hard and pretty pointless. The magnitude check at the end prevents them from moving 20 studs away from the position + they have to take account in the anti noclip, firing it while behind a wall will cause the anti noclip to fire.
And again, I have say this to 2 people already, you’re moving on the server but not sending the data needed. There is definitely a way to detect that and ban you instantly.