Is there's any ways to prevent exploiters from reading Local Scripts?

Help and Feedback Scripting Support
#22 
                                               ⚠️ Warning ⚠️

I’m only trying to help

This code was made by AI

You are correct that the names of variables are not saved in compiled bytecode, and an exploiter will not be able to see the original names of your variables. However, there are still a few reasons why you might choose to rename your variables:

  1. To make it more difficult for someone to understand your code: As I mentioned earlier, even though the names of your variables are not saved in the bytecode, an exploiter may still be able to understand what your code is doing by reading the function names and bodies. By renaming your variables, you can make it more difficult for someone to understand your code, which can deter some exploiters from attempting to reverse engineer it.
  2. To reduce the size of your code: Renaming your variables to shorter names can help reduce the overall size of your code, which can be beneficial if you are trying to minimize the amount of data that needs to be transmitted or stored.
  3. To improve the readability of your code: In some cases, you might choose to rename your variables to make your code more readable for yourself or for other developers who are working on the same codebase. This can be especially useful if you are working on a large or complex project and need to keep track of many different variables.

Overall, while renaming your variables is not a foolproof method for preventing exploits, it can be a useful tool for making your code more difficult to understand and for improving its readability and maintainability.

#23

I mean this in the sincerest way possible: if you use AI to try and help people, you aren’t helping them. It looks extremely bad on your part, especially in discussions like these, and putting;

Won’t make you look any better. It just makes you look ignorant because, well, the AI has written the exact same thing, and you still decided to post it here. You aren’t helping anyone, by knowingly or unknowingly spreading misinformation. Please, delete your replies.

#24

Stop using ChatGPT, and start using your brain.

1 Like
#27

Thanks, your posts are always such a help to everyone, we all love you.Thanks, your posts are always such a help to everyone, we all love you.

#28

Thanks, your posts are always such a help to everyone, we all love you.

#29

There are ways to break decompilers, but honestly, I think they are all a waste of your time.

Look, decompilers arent a 1:1 recreation of your code. Anyone trying to make a game based on a decompiled localscript is going to have a very difficult time because every decompiler has errors.

SV2 gets operators confused all the time so it swaps “and” and “or” instructions. SV3 renders your code extremely unreadable to any exploiter who would want to steal your game.

You could obfuscate your code, but users can grab the instructions for the onfuscator from getgc and manually deobfuscate the entire thing.

To make it easier for yourself and to spare your sanity, trying to prevent decompilation is not going to be your thing.

It would be much easier for you to issue DMCA takedowns on any games stealing your assets, this is what BIGGames does whenever someone uploads the reverse-engineered copy of psx.

If you want to hide your scripts and make it much harder for potential exploiters, put this chunk of code on top of any localscript you want to protect.

script.Parent = nil
script = Instance.new("LocalScript")

This hides your script from saveinstance exploits, and it hides it from functions that try to bypass scripts hiding themselves in nil.

It’s not much, but it will put a layer of protection over your code if that is what you want.

#30

Local scripts are always executed by a client, so client can read them.
It’s not a good idea to have a local script that does a lot of work. You will have problems with syncing.