This is really cool! I definitely had a big scare when I read that post about a backdoor being added through a plugin in an area we can’t even see.
However, I do think it’s a bit unnerving to have it calling a module, although it’s open source, I’d personally much rather have the option of manually updating the plugin myself, rather than it being done automatically. While I understand it’s viewable by every user, the security of my games relies entirely on your account’s security and having it call an external module would allow for a wide range of attacks without the plugin user’s knowledge.
Perhaps I’m just too paranoid about these things, it’s a great plugin, but I’ll be removing that line or not using it at all. I may be the only person with this concern.
Would you feel better about it if I made it so you could toggle the require on/off with a setting in the settings gui?
Update: Just added this setting to the settings gui. You can now disable the plugin’s usage of require for auto-updating of the infections table. (If you do this then I recommend you check frequently to be sure the plugin is always up to date as I won’t be triggering an update notice for something small like updating the localized known infections table as the auto updater check is meant more for if I change the code in the plugin itself)
PSA: The infection scripts are now attempting to hijack pre-existing scripts by appending the backdoor code to them. (I was expecting and ready for this since yesterday) Due to this the plugin now uses 2 requires but it can automatically remove the infection hijack code and replace it with a harmless comment that the plugin removed it. (This can be turned off in the settings) (He also got smart and made the variable names randomize each time the plugin injects them so I built a smart string.find system that allows me to pass wildcards in the form of multiple strings in a table so there is no character he can put that my systems can’t locate)
If you haven’t updated the plugin I recommend doing so now! The version as of this post is V1.1.0
P.S. I’ve been talking with the exploit creator who has been distributing these backdoors and although our conversation started respectful (Basically us complimenting eachother on the creativeness/innovative approaches) it has now turned sour as he is quite salty about the plugin. He also claims his backdoor is in many games, some with 2k-4k active players so it might be worth mentioning to your dev friends that running a scan with this plugin couldn’t hurt. lol (As always the require modules are free to the public and the plugin source is easily viewable. I take great entertainment and personal satisfaction in producing a quality product… plus the exploit creator’s saltyness is like the cherry on top~) I’ll keep the plugin updated as the exploiter continues to attempt to circumvent it. Stay safe everyone~
I think ROBLOX need to mention about this issue because of the scale of the issue obviously when they completely know what’s going on
Thank you for publicising this. It’s paramount for the welfare of new developers and even experienced developers using plugins where it may ruin their creations.
Maybe the script already does this, but why not include a whitelist of instances that belong under services? This way, the blacklist can inform you of a virus while a whitelist can inform the user that something isn’t as expected under a service, whether it’s an instance with a name that doesn’t belong, or more than once instance of the same name when there shouldn’t be more than one.
Mainly because due to the open source nature of plugins and the exploit creator’s continued monitoring of the plugin it would open a security concern where the exploit creator could simply inject the infection script’s name into the whitelist (since the only way to save data in plugins is with the plugin:SetSetting() function) so for security purposes I have it scan the source code of the scripts in the game instead of the names or locations. I also have a setting (default to on) that if there is a script in any container that isn’t directly explorable in studio (meaning the service doesn’t show up in the Explorer window in studio) then it will treat the script as an infection and contain/delete it. For his recent attempt to circumvent my plugin where he injected code directly into the source of pre-existing scripts (which he ultimately reversed because he feels this makes it too easy to have his backdoor found and due to the low popularity of my plugin he is more concerned about having the games he already has infected find out about the infection and take steps to remove it) I built a secondary scanner which doesn’t quarantine the entire script but instead replaces his infection code with a harmless comment to prevent it from damaging the game. These two systems together make it extremely difficult to put infection code into a game and even more so to do so without being caught… and even if they do make a new infection script all it takes is one update to the modules/plugin and the system will be able to find and remove it the next time the developer opens studio with my plugin installed.
Didn’t realize we were playing Spy vs Spy here lol
By the way! As far as I know the settings for a plugin is basically impossible to access from outside that plugin. There’s one for local plugins and one per each installed setting and they’re self-contained, so you should be fine with settings.
Great to see this. Thank you for creating something that Roblox should probably be doing automatically anyway.
Found a few things in team create places I’m involved in but nothing in my own places. Makes sense given all I generally use is Stravant plugins
Yeah, the GUIs are terrible. They are meant to be temporary as I just kinda threw this plugin together rather quickly and such.
As far as the system marking your scripts as viruses I apologize for that. If you could send me one of the scripts that it’s incorrectly marking then I’ll look and find why it is marking the script as a virus. If it is a false negative I’ll remove the corresponding string that’s flagging it since it is too general.
I looked into it and saw that this plugin is parenting itself into “CoreGui” which is by default an unviewable location in ROBLOX Studio. I’ll work on making a whitelist system where if the plugin flags a script as infectious when it isn’t you can whitelist it (and send me the script so I can globally whitelist it if you want) to prevent the plugin from flagging it.
Until I push this update out you can stop this from removing it by disabling the setting for treat all nonviewable locations as infectious.
Version 2.0.0 is now out. Featuring a full GUI overhaul, full control over what services you allow “Scripts” to be inside of, script whitelisting (Note that if the script’s source is changed then it will have to be readded to the whitelist and enabling the script whitelisting setting will slow down the scan speed quite a bit… though I did make it not lag studio so you can continue working while it scans), a few more settings, and audio cue/response when you click buttons or events happen (can be turned off in the settings.)
Soon to come in V2.1.0: Automated infected plugin detection and alert system to alert the user if they have a plugin in their inventory that is known to be infected/malicious.
Patched. Please update the plugin (Now version V2.0.1) and it won’t do this anymore. Made a small mistake when I was building the service whitelist system and if the game wasn’t able to resolve the whitelist name to a service with game:GetService it would cause that error. I’ve fixed it so it knows if it needs to use GetService or not.
Edit: Also added a “Reset to default” button for the Service whitelist. Soft update push. Still V2.0.1 but you can update it for this button if you want to.
