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.
1 Like
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.)
tl;dr: CTRL+Shift+F won’t find nor search the source of the majority of the plugin backdoors.
3 Likes
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.
8 Likes
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.
2 Likes
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.
2 Likes
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.
1 Like
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:
- Using the Equipped and Unequipped events
- Cooldowns
- Altering the character
I’m sure there are a lot more usecases but these are the few I can come up with now anyway.
5 Likes
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.
1 Like
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)
3 Likes
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.
1 Like
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. 
2 Likes
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.
5 Likes
Check all your plugins, and check their authors. If it’s some really reputable name (i.e. Quenty, Crazyman32, etc.), then keep it; else, check their profile. See if they have some kind of developer role in a group or are in the Dev Forum Community group.
Look up the name of the plugins from authors you’re not exactly sure of on the library, especially ones you got off the first few pages of the library. If there’s duplicates, there may be a chance that you got an illegitimate copy that’s a duplicate of the original except with backdoor code injected into it. Remove those plugins and install the originals.
If you want to take a look at the source code yourself, check the Plugins folder, go up a folder on the file tree, then check InstalledPlugins. You can find every plugin you have installed and their source code in .rbxm format. You can import these into Studio to check the source code. It’d be smart to run Chris’s scanner on these or check for any script that looks suspicious and/or contains obfuscated or suspicious code. Uninstall these as well.
I was stuck with some backdoor prompting model purchases for a solid week until I read somewhere here that I should try inspecting plugin code by hand. You probably should to; you’d be surprised by how many times people (myself included) install malicious duplicates of popular plugins.
4 Likes
This vulnerability is now patched. Scripts which were executing only because they were parented to a Backpack in some obscure location will no longer execute. The fix applies to both Studio and live games.
36 Likes
Thank you for the speedy fix. I’ll be sure to update tonight.
Can you mark this post as a solution to the OP?
Done.
3 Likes
Can you offer a way to remove the hidden script in Studio? I can see the malicious script when I export my game to XML, but I don’t know how to remove it from my live game.
The detector plugin they linked can do that for you, or you can just delete it via the XML