11 posts were split to a new topic: Cannot find backdoor in my game
Thanks for looking into this! I really Enjoy Using Roblox and learning to script is always fun! Thanks for your Effort Roblox!
I think it would be an interesting idea where if a plugin wants to add a script to your game, it will give a popup (from roblox), stating where it wants to save to, allow you to view the code, and confirm/deny if you want it added. If you notice shady obfuscation or anything along those lines, you know immediatly to deny it. Just food for thought. I think it would help prevent many future instances that will try to add malicious code to hidden parts of your game.
I’ve got an Idea for how to prevent Users from seeing code like a modulescript, the dev can see the code it just hides it from the player by calling fuctions through remotefunction and remoteevent. Gotta develop it but I have school so after school I’ll create it!
Please do not link/discuss specific malicious plugins or rule violations.
To provide some more details about this vulnerability such as how it happens and what @Christbru01’s detection plugin is doing (it feels like the best way to combat this sort of injection is to be transparent):
Backpacks currently run scripts that are descendants of them. This is so that scripts can run while they’re parented to Players
This vulnerability is caused because Plugins can create Backpacks and Scripts and place them inside of Services that can’t be seen normally in the Roblox explorer.
Some services, such as the CSGDictionaryService, cannot be accessed by scripts, Plugins, or the Command Bar. Due to an oddity with how Roblox works, there are means to place things within these services but not get them out
Due to this, and how Backpacks allow scripts to run, a vulnerability is created by putting a script in these services.
Hopefully this better educates people on what’s going on here. I can absolutely vouch for Christbru01’s plugin. You can also do the trick Seranok suggested up at the top of the thread, as that’s a guaranteed method.
Specific to the injection done by the fake “Terrain Save and Load” plugin, scripts are also injected randomly in the Workspace, so make sure to check more than just scripts in Backpack objects.
Just as a tip for anyone checking plugin source code: If the image for the plugin button (the one that shows up in the toolbar along the top of Studio) isn’t uploaded by the same person who uploaded the plugin that’s using it, that’s usually a pretty good indicator that the plugin you have isn’t the original/genuine version.
This unfortunately cannot search scripts outside of normal locations. If a plugin injected a backdoor script into a protected service such as CSGDictionaryService then nothing you can do in studio or command bar (save for a few very tricky and sorta hacky methods) will be able to obtain an instance memory pointer much less be able to view the source or remove the infection. This is why I created the plugin as plugins have the highest execution authority and using the tricky/hacky methods (See above reply by @Dekkonot for a good explanation on what my plugin is doing) I am able to not only detect but also obtain the instance memory pointer and relocate or remove these hidden scripts or backdoors that are otherwise nearly impossible to detect without going into a place xml save file and reading line for line for anything that looks out of place (Which the exploiter has taken methods to make that method more tedious and irritating to do.)
CTRL+Shift+F won’t find nor search the source of the majority of the plugin backdoors.
Plugins insert scripts pretty frequently, perhaps a permissions system? When you install a plugin, it tells you exactly what the plugin will be allowed to do - insert scripts, edit instances in your game etc
Having said that, a good, well developed plugin shouldn’t have much need to insert scripts into the workspace unless it’s a very specific use case, so this could be very helpful in the case of most plugins.
Backpacks shouldn’t run code. This kind of script-running was superseded by the PlayerScripts container. The only qualm I can foresee is that legacy games may break, but that’s no excuse for making a reasonable patch. Rather than checking for descendants, just have them stop running code altogether.
For those who are still using Backpacks as containers, stop. Use folders. They were added for a reason.
Backpacks need to run code so that tools don’t break when they’re placed within them. There’s a good reason for it.
A better solution might just to make it so you can’t create them anymore. I have no idea why you can actively create them but it’s probably not a good idea.
Unequipped tools don’t run code, unless I’m missing something. What reason would you have to keep the scripts of unequipped tools running? Doesn’t make sense to me.
I’m not sure what you mean by this, unequipped tools in backpack do run code both scripts and localscripts, and I can think of a lot of reasons:
I’m sure there are a lot more usecases but these are the few I can come up with now anyway.
Can Roblox not offer a way to cleanse infected places?
- I don’t know how to manually edit a published game.
- I tried the plugin mentioned, but one of my games is too large to be scanned by it.
It will scan, just takes time. You can also lower the scan delay chance if you have a decent CPU. (It will increase lag the lower the delay chance gets)
I’m sure I clarified what I meant when I said that. In either case, this answers my use case question. Disabling the creation of Backpack tools, as Dekkonot suggested, would probably be ideal then.
wish I would’ve known this technique earlier with the script, I had a malicious plugin once. It’s all good now but one of my games was breached and I had to close it down.
The button to show hidden services should only show them if you are searching for them or if the service has children. A fix could also be to potentially alert the user when a script is parented from a plugin to one of those services for the first time.
A post was merged into an existing topic: Off-topic and bump posts