Chapter 2, Backdooring Explained.
Hello there! Thanks for the overwhelming support on Chapter 1 of Backdooring Explained. I could not thank you enough for the support, and to help many developers overcome the trouble that is free models! To give thanks, I am continuing on with the old thread, this time focusing on the scripting part behind the free models within this trickery!
View Chapter 1 of Backdooring Explained here, which talks about the community/market of it all.
With that out of the way, letâs begin!
To start off, letâs discuss how Virus models work!
Virus Models
Virus models, some of which include Jumpscares, Game Destruction, are models which work simply.
Fire spread models are the most common of virus models, at least, back then of course.
The script starts off by defining a function, which will be called later on in the script. The function will look for a Fire instance with FindFirstChild(), defined by a variable. If the variable is nil, the function clones that Fire instance to every part in workspace multiple times. If the variable is not nil, the fireâs size and heat will increase by a large number. Not math.huge though. The function will then close. The script then connects the function on Touched, which basically spreads the script a LOT of times.
While that was very much common back then, not as common as some of the virus models we see now. Letâs move on!
PurchasePrompt Infection
A not so commonly used technique, this type of infection forces all users in game to purchase a specific model on the Library (assuming a virus model of course).
The virus works by using the MarketplaceService. Back then, this was quite common. That was, before Roblox introduced the new AllowThirdPartyPurchasePrompts setting.
It would force a purchase prompt to every user in game using PromptPurchase. Back then, this would also load Third Party Purchases. However, with the restriction setting enabled at all times, this stops that from happening. Only with the setting turned on, will it allow purchasing 3rd Party Items.
Plugin Viruses
Due to the nature of plugins having an extremely high level of security, they can be abused easily. Letâs talk about the most common plugin virus.
The spread virus is among the most common. Plugins have the ability to access a property called Source. This is a property with the Script instance which is NOT ReadOnly, and high permissions such as the Command bar can modify this. Why does this matter? Plugins that are malicious can modify a script once you touch it using the Selected property on an Instance! This means that plugins can insert their backdoor into your script once you touch it!
This common backdoor is known as RoSync. RoSync will trick the user into thinking that their scripts are synced and secured with Studio. However, that is not the case. It is a common backdoor with a certain malicious plugin developer.
Model Viruses
Model Viruses are models that load malicious scripts into your game via a Module. How does this work? Let me explain. Be prepared for a whole lesson.
Model Viruses are able to insert or load malicious scripts via Luauâs require(). require() is able to load scripts on the library via rbxassetid. require() is the main gateway to backdoors. Once the module is loaded, the script will instantly scan for many things. Simple backdoors will check if a player is whitelisted via IsInGroup() or GetRoleInGroup() which if that returns positive, the module will then copy a GUI to the users PlayerGui. Basic backdoors will usually contain 3 key parts of the GUI such as:
- An executor
- A script hub, for loading popular scripts
- An animation or opening sequence with TweenService.
The executor is able to run scripts on the server using 3 things. Firstly, the executor needs a Loadstring module, as loadstring() cannot be enabled via a script. Nextly, the executor needs a remote, for firing the loadstring to load scripts. Finally, the executor needs a server script, for defining what the remote does on ServerInvoke, which connects loadstring() from the module.
As soon as that is done, an Execute TextButton will be shown on the UI, which on pressing the button will connect a function and load all the text shown in a TextBox on the GUI. Since most scripts that people load with serversides (eg. Star Glitcher) are only compatible with the R6 rig, there is a button shown on the GUI which will load an R6 Conversion module onto the LocalPlayer. Also, there is a respawn button on the GUI which calls Humanoid:LoadCharacter(). Onto the script hub area.
The script hub is a section of the serverside which is able to load common scripts via require(). Examples of popular scripts are:
- Star Glitcher, or Nebula Glitcher.
- Dex Explorer 2.0 or Dex Explorer 1.0
- Other script hubs including Kasperâs Hub or Project Reptile 3.0.
- HD Admin Owner, Kohls Admin Owner, or Adonis Admin Owner scripts.
- Admin scripts, which include Infinite Yield, Quantom Admin.
- Grab Knife 3.0 or 4.0 (Grab Knife 4.0 has inappropriate scripts)
- F3X Building Tools or BTools.
These are just some examples, as there are THOUSANDS of more scripts to worry about. All of these are loaded with a similar method just like the Executor.
The only current way to detect executors are via their name in the PlayerGui. Some of these names include:
- âvermdoeâ, the GUI name of popular serverside named âVerm Doeâ.
- âDAONEâ, the GUI name of the popular serverside named âDynasty SSâ
- âSinner+â, the GUI name of the popular serverside named âSinner+â
These are just some of them, and there are way more! Always be suspicious!
How to protect against serversides
The best way to protect against serversides is to always delete suspicious scripts from models so that you ensure security over your game.
Has one of your own developers inserted a backdoor on purpose? Take action on them immediately!
Installed a malicious plugin and backdoors are in every one of your scripts? Well itâs about time to dust off those modules of yours and become the maid! Start cleaning up your scripts! Also, remove the plugin or disable it ASAP, to prevent more damage.
Lesson of the Story
Think of a model as getting background information on someone! Before you hire them, you need to look at their past information before hiring them! Before you allow the model into your place, check the model for anything suspicious such as lots of sales but very few likes and a lot of dislikes, suspicious groups, etc. Then you can add it/allow it into your game!