I’ve looked up multiple times If the client can edit local scripts in real time but I haven’t really found the answer I’m looking for.
I know how unsafe the client is and to never handle anything important on the client, but are they able to actually edit the script while it’s running in real time?
Correct me if I’m wrong but couldn’t I just check if my local script is nil and kick the player if so?
Hackers are not able to edit, nor even view most scripts, anything that isn’t local to the player can not be edited nor even viewed by hackers, due to the roblox protections put in place.
I don’t think I worded this right, I mean if they can edit local scripts, let me fix that
Ah, sorry if the misreading was on my side. Although if you are just talking about local scripts, they are not able to edit it real time, without the use of a backdoor in your scripts.
it is physically impossible for a hacker without some third party backdoor to realtime edit your scripts. Ever since filtering was enabled on roblox, that pretty much removed any possibilities of them doing it without a type of backdoor, until a new vulnerability is found, it is impossible.
Although again, I would say do not put anything important in local scripts, due to the hackers being able to view them freely.
So, from what you are saying, if the player is hacking they are able to edit local scripts in real time?
Incorrect, I am saying that it is impossible for a hacker at this time to edit local scripts in real time.
I was saying that they are able too, if there is a third party use of a backdoor, if you make sure that you have no backdoors in your game, then it is impossible.
Oh, I’m sorry, I misinterpreted when you said backdoor. So if this is the case, why aren’t there more client-sides anti cheats? Couldn’t the anti cheat just detect if the script is nil?
Hm, you are correct there, although the way I see it is that a lot of the developers in this community are more focusing on server-side anticheats. Although, this might be incorrect, from my development on the site, I’ve noticed a lot more developers focus on the other parts. I’ll check if I can get a answer for you in a moment. Sorry for the wait.
Okay, well it doesn’t seem your too sure on your answer which is fine. I’m not going to mark solution and see if anyone else has a better solution
This is a little snippet of code from my main client script which is a simple check to see if the script is nil
Yeah, I understand what you mean, I’ll try to rephrase it better in a bit, sorry for causing confusion. Good luck getting a answer.
Exploiters can disconnect the Kick function on the LocalPlayer. Along with that, they can disable the LocalScript entirely
I’m still a little confused about what you are asking in this thread, are you asking if a exploiter is able to fully delete / remove a local script, or are you talking about disabling a function to bypass either kick or some action that the function is allowing/denying, if the ladder then they are able too although if you are talking about the top, exploiters are physically not able too.
Okay, so what if I was to use while task.wait(etc) do? Disabling the script does not effect the loop
I’m wondering if a hacker would be able to edit a local script while inside of a running game. If they can’t, this brings me the question why more anti-cheats aren’t client based and check if the script is disabled or nil via loop
They can’t edit it in real time I think although they can just hook functions like :kick() and your local scripts are useless.
You can have the best obfuscation and the best internal script security, but if you’re relying on something on the client (e.g. LocalPlayer:Kick()) that wouldn’t matter. Exploiters have access to the game’s metatable and change whatever they want (to an extent). ServerSide security is what you should rely on as exploiters don’t have access to the server
ClientSided anti-cheats only stop script kiddies. Experienced exploiters know how client → server replication works and how the Roblox client functions. Setting your script’s parent to nil or checking if the Parent is set to nil will merely slow them down
They are not able to “edit” local scripts (this depends on your definition ofc), but they can do pretty much anything else on the client. A lot of the other posts on this thread are misleading. They can modify variables, disconnect connections such as the heartbeat, hook functions (like kicks and remote event firing). They can also change ANY function that exists in the environment to what they wish. This is oversimplification, but client anticheats aren’t usually very effective. There’s usually a way to bypass them, but server ones are trickier since they can’t use all their tricks on them. I’d recommend just keeping your remotes etc secure.
They cannot view LocalScripts (fully at least). When LuaU was implemented, it basically removed all of the information that was unnecessary to super optimize the code, like comments, local variable names, and basic things like that. When they “view” or decompile local scripts, it’s just the decompiler’s interpretation of the script. It does not include variable names (unless they’re global) or things like that. The code basically looks like it was placed in a blender.
And incase you didn’t know, it’s impossible for them to ever view server scripts unless there’s a backdoor plugin you have or somebody has access to the game in studio.
(Some people don’t know this, so I’m going to include this on here)
Note: I agree with all of the points that zyro made above because I was almost done when he sent his message.
Thank you for helping!
cha r s
I don’t think this will work as .Heartbeat:Connect(function() runs every heartbeat of the render engine. More details on that here:
So basically, since it runs every frame, if the user deleted the script before the next frame, the script wouldn’t be able to run because it was deleted before the frame was there to fire the event.
I would personally connect a :GetPropertyChangedSignal() event that fires when the parent of Script appears nil, or not where it’s supposed to be. Ex: workspace.
Reason why:
Hope that helps.
