Would this be practical/reliable for anti exploit (local script)

Help and Feedback Scripting Support
#1

I don’t have many knowledge of hackers/exploiters
But from what i know they can hold script before execution and edit/disable it,

So what i tested is i added a simple if player walk speed is greater than 16 make there humanoid 0
In a local script, and added a clone of this simple anti exploit script in server storage,
Then i added a server script and basically with the server script i delete the anti exploit script and replace it with a new one(cloned one form server storage) and this happens every 0.07 seconds.

So even if they try to edit the anti exploit script it will be a deleted one there editing and there will already be a new one same goes for disabling it,

Is there something else i didn’t know and they can still bypass this to walk faster?

3 Likes
#2

That won’t work because the client can’t see serverstorage and therefore cannot create clones in it. Just keep track of each player’s speeds from the server

4 Likes
#3

It would would work. The server script is cloning it not the local script.

1 Like
#4

You could do this without a local script. WalkSpeed is replicated to the server. So you can check if it changes on the server.

#5

Yeah ik its just a example i use

1 Like
#6

No it wouldn’t. The server can’t see playerscripts so it can’t insert localscripts there.

#7

You can put it inside of the player’s character. Or playergui.

#8

You can also put it in the playergui

2 Likes
#9

Local scripts can always be bypassed, I’m pretty sure this could be bypassed by using metatables, and setting walkspeed always to below 16, meanwhile the character runs way faster.

4 Likes
#10

Not necessarily. An exploiter could change their walkspeed and use metatables to return walkspeed value of 16, and the server would still read the property as 16, but because the client owns physics ownership of their character, they would still be speedy. This is why anti exploits use magnitude checks.
Also, I don’t think it’s a good idea to rely on an exploiter not being able to delete local scripts fast enough because they can do anything with their client. “My machine, my rules.”

5 Likes
#11

Ow i didn’t knew about this but make lost of sense hmmm

#12

Golden rule: Don’t trust the client ever.

2 Likes
#13

Agreed, exploiters tend to bypass client kick systems easily. You’re better off using a server-sided kick script.

#14

But by doing this can i prevent them from rewriting the code in the local script or thay can bypass that also?

#16

I’m not entirely sure what you mean by rewriting the code, but assume an exploiter can just use Synapse to execute anything a localscript can plus more.

If you really want to know how an exploiter can make their walkspeed look like it’s 16 without being detected, check out this tutorial post on metatables. I believe it explains how exploiters can use debug.getmetatable().

1 Like
#17

Sorry i don’t really know i tought here you could ask for help and get feedback

#18

This should be fine in development discussion because we’re talking about if this system would be reliable or not, and if it’s effective or not. Scripting support is meant for getting help on code you wrote, but he didn’t write any code here. Code Review is for improving upon already working code.

#19

Nope. not secure at all, they can just remove it and start causing chaos.

you can put everything in one script, and put the anticheat in there (like Breaking Point) and if they remove it, the game will fail to function

#20

(cc @DaringAwesomeSauce)

There’s no need to spoof the property with metatables in the first place because WalkSpeed doesn’t replicate and likewise the server would ignore the change because updating the metatable is only applicable client-side.

1 Like
#21

Why not just check on the server side for speed exploits?

game.Players.PlayerAdded:Connect(function(player)

while wait()  do
        if player.Character.Humanoid.WalkSpeed ~= 16  then -- making sure it stays normal speed of 16

               player:kick()

        else
               --do nothing
        end
    end
end)

Which I don’t think works anyway…