Help with Anti-Cheat for client side

Help and Feedback Scripting Support
,
#1

hello, i need some help for an anti cheat system i made.

The anti-cheat i’m trying to make is for this game:

I just have one problem, trying to find out if you can stop local scripts from having their code inside modified, if they even can be modified by exploiters?

I thought of making a server script in ServerScriptService which would replace the local script in playerscripts every second or so with a fresh copy of the original client script
in case it was modified after the player joins the game.

All i need is to know is, if local scripts can be modified instead of replaced by a fake one, and if they can, then any help for preventing it could help.

4 Likes
#2

You can’t do anything on the client-side to stop exploiters. Any obfuscation and other security through obscurity might make it more difficult but it’s not going to prevent them from anything. Your best bet is to make a server-sided anti cheat.

4 Likes
#3

I know, the server script i was talking about is the actual anti cheat but i need the client script to only send specific information to the server with a remote event. That’s why i want to know if you can stop the code from inside being modified.

2 Likes
#4

Yes, LocalScripts can be modified, and even replaced in their entirety; the client has virtually free range over anything that exists on their device. There is nothing you can do to prevent this. In my opinion, anti-exploitation on this level is futile. Focus on securing your systems through good server-authorative design and sanity checks

3 Likes
#5

Ok, but can you at least replace the local script with a fresh one using a server script to make it harder to exploit (not to entirely prevent it)? Or any similar ways?

1 Like
#6

Nope. Futile. Forget it. Seriously.

1 Like
#7

Alright i’ll try something else, thanks anyways.

1 Like
#8

Stop trying altogether. If your system can be taken down by one small change in a LocalScript, then its design is the problem, not the exploiter. Trying to prevent exploits on this level truly is a waste of time, so don’t let it get in the way of your development schedule

4 Likes
#9

Exploiters can do literally anything on the client side. Anything you keep on the client can be modified or read. However whether or not they will actually do that depends on the exploiters competency. And considering roblox exploiters are 99.999% skids even the most basic measures can deter them.

The best thing to do is to keep your AC source with some important game functionality (preferably something that is important but not performance intensive), then obfuscate the code. There are also tricks you can do to hide the source from publicly available exploiting tools

3 Likes
#10

The design of the system isn’t the problem, i’m just wanting to get some information about this stuff, this isn’t also pointless, i can upgrade the system from mistakes or learn from them, everything else for the anti cheat system is already made. The stuff i’m looking for
is to add to the system as extra safety, not to fully protect the game. I know that it can be pointless but adding it can add extra safety and give me ways to extend it.
And about performance issues i’m careful, and i know what exploiters can cause with the game.

1 Like
#11

Server authority cannot detect a lot of exploits

1 Like
#12

The lot of client-sided exploits are harmless. Any client-sided anti-exploit measures can be eliminated, making them pointless. Server authoritative design essentially boils down to reducing the amount of influence the client has over what the server replicates, so focus should be put on ensuring the client isn’t sending critical information to the server when the the server can legitimately source that information on its own. The most you’re going to get out of client-sided anti exploitation measures is a filter that blocks out skids or exploit developers with a low drive to cause harm

1 Like
#13

Your current goal for anti-exploitation is pointless. Trying to secure the code of LocalScripts is going too far and cannot be done

1 Like
#14

Not securing but preventing the code inside a local script from being modified on the client side, it being viewed by a player doesn’t matter.
So like replacing the script every second like i said in the Topic, and to remove the modified one while replacing it.

1 Like
#15

That is what is meant by securing your code (holding it in place)

1 Like
#16

You overestimate roblox exploiters. Most of them including all public executor devs are skids.

And the server cannot detect stuff like aimbot, autoparry, ESP, saveinstance and macros. Granted all of these exploits can be made fully undetectable even by hyperion but roblox exploiters are not competent for all that

1 Like
#17

Alright but one LAST thing, is serverstorage safe? can you SEE local scripts in ServerStorage from the CLIENT side? if you CANT that means it could be stored there for the SERVER script to clone and replace the ORIGINAL one in playerscripts? I’m asking this because i have a Gui in there with a local script inside and when a server script puts it in playergui it works normally

1 Like
#18

Dude. Leave this idea be. Causing frequent interruptions in your scripts is no way to build a game, and will only cause problems. It’s not an elegant or functional solution

1 Like
#19

The local script is gonna be designed to run with interruptions, but is what i said true?
I only need an answer to that question nothing else.

1 Like
#20

Nothing inside of ServerStorage from the edit data model replicates to the client-sided runtime data model, even client-designated instances. I reiterate, you’re going too far for no return

1 Like