oh, was this helpful? I am trying to know if people like this topic. A few people do, what would you rate on a scale from 1 to 10? And also how can I improve your review?
Ah ok I thought you were talking about other tips to protect. I’m going to give you 9.5/10 because basically I’m not really a guy who thinks about exploit problems I didn’t know the tips to take but you said it! 
1 Like
Thank you for your review! 30CharLimit
Hey, thanks for the tips!
I just had a few more questions.
- Are the only things that can have backdoors/other bad things for your game scripts and plugins?
If yes, then would it be perfectly safe to get something like a sound or a mesh? - Would it be safe to get a free model but disable/delete any script?
- How safe are free models from verified users?
- Is it necessary to have an anticheat for a singleplayer game?
1:
As far as I know, Audios, Images/Decals, and Meshes are safe.
2:
Yes, but make sure to delete them all. Also, safety isn’t guaranteed, and sometimes Scripts aren’t detected. It should be sage to extract assets from free models and delete them after (make sure to delete remnants other than the model and check all of Workspace)
3:
Verified users are not that much more trustworthy than unverified users. It’s less likely to be a bot, but it could be botted. It can still be a human scammer, or bots could be slowly amassed.
4:
This is subjective, but in my opinion I’d say no. Cheaters wont affect other players, so if it’s entirely singleplayer you should be OK. Nobody cares if you cheat in your own singleplayer Minecraft world, unless you pass it off as legit (like a fake speedrun) Add one if you have badges though.
1 Like
Thank you, but could you please elaborate on this?
What do you mean by scripts not being detected, how would I extract an asset from a model, and how would I tell if something from the model went somewhere else in the workspace?
Also one more question I just thought of, do scripts only run once you run the game, or as soon as you insert the model into workspace?
Scripts run at runtime, not in Studio. Also, I know free models can add other stuff to workspace, that’s why I said check workspace and delete all remnants.
By Scripts being not detected, I mean the little script icon on the free model preview doesn’t always appear.
You can extract assets from free models like SpecialMeshes or MeshParts and Unions. You can also extract Sounds. Just rip it out of the hierarchy and remove scripts inside it. Then remove the rest of the free model.
This is getting offtopic xd
2 Likes
You don’t need a DLL injector for backdoors, you just need an internal UI executor which is pretty easy to make and doesn’t need to modify the Roblox client
Excellent guide.
I agree with everything except one thing: I don’t think you should obfuscate your code (not even your client code). The only thing renaming your variables and stuff like that will do is confuse you. You, the developer, are going to dedicate many hours over the course of your game’s lifespan to decyphering your own code. Meanwhile, all an exploiter needs to do is beautify your script and learn the variable names to know what the script does and can develop an exploit that works despite your best attempts to confuse him.
Most exploiters aren’t even looking through your scripts anyway (except, of course, to steal them or look at modules to exploit—in the former case, obfuscation is useless; in the latter, does you more harm than it does the exploiter). Instead, exploiters are usually executing code on their own and using remotespy. Obfuscated code won’t help you there.
The better solution is to design your systems assuming that the exploiter will gain a full understanding how they work (this is Kerckhoffs’s Principle). If you are sure to never trust the client and you implement good server side validation, the exploiter won’t really be able to do anything meaningful, no matter how well he understands your systems.
Of course, you are allowed to obfuscate your code. It might slow down some exploiters from doing some things. However, it really hurts you more than it hurts the exploiters. You will find your game easier to work on the closer your code looks to plain english and more secure the less you rely on the exploiter not knowing how your code works.
1 Like
how would they open the UI executor ? The owner of the game would find it easily. Most backdoors down give everyone the internal UI executor but they come with an executor. They mostly need DLL injectors/exploits to be opened or found.
Do you mean once it’s triggered it shows for everyone? So apparently that’s normal (
The More You Know). My experience with backdoors goes as follows:
I was playing 2 player prison tycoon. An exploiter opened the backdoor. I was confused on what the window was. I look at it and realize it’s a backdoor. I instantly assume I have a computer virus that installed Roblox exploits to my computer. I realize I don’t have exploits or a virus. I then kick the exploiter using their own exploits, and abuse the backdoor to kick all and loopkill (I didn’t have an F3X module yet). I never see the game or backdoor again. the end
Usually backdoors dont open for everyone. Most backdoors are supposed to only open for the person who chose to open it.
Backdoors just tend to be a remote under workspace, ReplicatedStorage or probably Lighting.
All they do is run a piece of code sent by the client, specifically require()s as it only runs native LuaU.
As for the UIs, it’s just to handle inputs and such, while also trying to find the first backdoor it could find and its accompanying RemoteEvent.
If the server is doing anything with the clients, such as saving data, then yes. If the game is purely client sided for some reason, then probably not.
1 Like