Backdoors are scripts you would often found hidden in a model, snuck in by a scripter or builder you just hired, or even outdated plugins from ages ago. Backdoors could even be compared as a Trojan, as they are usually hidden in normal-looking models you can find in the toolbox, or in the library.
WHAT ARE THEM, EXACTLY?
Backdoors are scripts inside of your game that, when detecting a player joining with a certain UserID, or fire a certain code, will grant them a GUI that will allow them to execute commands similar to scripts inside your game, which makes the injector capable of abusing your server-side, which is impossible to do with client side executors that are injected to Roblox client.
This does not mean that any server-side exploits can mean you’re a victim of backdoors. It could also be from unsecured RemoteEvents. This is mostly of intuition to figure out which.
TRUTH ABOUT BACKDOORS
- Backdoors are not yet capable of stealing IPs, injecting code into your computer, or hacking others passwords. They work just like a regular script would.
- Backdoors don’t just make themselves into your games. They either come from Scripts, ModuleScripts, or Plugins.
- Most backdoors are paid services, and the majority are whitelisted products.
- Sometimes exploiters aren’t abusing backdoors they can be abusing RemoteEvents, for example using a RemoteEvent that harms players for a Kill All script.
Backdoors can simply be removed from your game if you do the steps below.
HOW TO LOCATE ALL SCRIPTS IN YOUR GAME
The actual way to locate every script in your game is simply by searching “classname:Script” inside of your Explorer. This will show every instance with the ClassName “Script” which is where most backdoors typically are hidden. “classname” can work with any instance as well.
HOW TO FIND THEM
Preferably, you should check the models you think are the problem first and look at the least of your worries last. Most backdoors are only in ModuleScripts or Scripts. LocalScripts don’t work as they are only client sided. They can be disguised as regular scripts, like “Weld” or another inconspicuous name… I will pull a random toolbox model and search “classname:Script” in the explorer search bar.
At first for the most part it looks pretty normal 'til you open the script.
If you open the script up, It looks like this.
If you notice either a long horizontal line or a long vertical line that extends outside where the actual code appears, its likely its hiding something. It also never uses the cFrame variable for some reason.
commonly the script is using spaces or indents in order to hide whatever is inside of it, so its possible to remove all the indents by copying a indent from the script into the Find & Replace tool (Ctrl+H) or just by scrolling through the lines slowly. If nothing still appears, you can also try removing all spaces if nothing pops up.
After splicing some of the code in the empty spaces you can find this odd code. This odd code appears to reverse “require” (hides it from people using Ctrl+F) then the use of the cFrame variable, which is decently resourceful.
By doing the equation present in the cFrame variable, you can find this Model.
This Model seems totally legit. Lets see what is inside it.
Another weld script apparently. It doesn’t make sense how there’s a need for 2 weld scripts, but lets try the same method.
What is that?
That is obfuscation. Obfuscation is commonly used to conceal the writings of scripts by creating code that is readable to the program yet unreadable to the programmer. This is useful if you’re running a paid service, but if you randomly see it in code in a toolbox, 9 times out of 10 it is most likely a backdoor, especially if they have odd writings within it. It may either be found packaged in a bunch of modules, or found within the indents and spaces.
Plugins with backdoors
Plugins are also a likely cause of a backdoor, where people could spend their whole time programming/building will never notice until players find out. If you have suspicions of such, you should either filter out your plugins or use a extension such as BTRoblox to download the file and scan through it like earlier. Others that have access to your game such as hired scripters/builders can also have these, and should be asked to clean out their plugin folder and do what is mentioned in the post.
TL:DR;
- search for classname:Script in explorer
- check scripts that have obscenely long bars
- remove scripts that require models as well as scripts with obfuscated code (unless paid script)
- clean out your plugins and check them with BTRoblox
3/27/24: Remade the majority of the tutorial, more information on them, as well as properly finding scripts in your game, with changes in tone and maturity.