Do I have malicious scripts in my game?

Help and Feedback Scripting Support
#18

I dont have access to that… New member

1 Like
#19

I’ve pulled all the versions of the module 2679263840. Turns out, there is only one version. Also, this module was created 2018-12-25 at 20:47:09 UTC. That report was from 5 days ago, meaning that the creator actually is requiring a different, new module instead of updating it. We need to find the plugin source to see if it every inserted a script that requires a module that actually has malicious code. Could you upload your plugin directories?

It also means the developer is actively working on this… I wouldn’t run studio any more with your plugins in case he updates it, or sees this discussion since it hasn’t been moved to a private place yet.

1 Like
#20

Sorry was that supposed to be a reply to me? If so how do i find the plugin files?

#21

It was kind of to both, going off of what he said. In studio go to Plugins → Plugins Folder which will bring up a gui for local plugins. Navigate up to the Roblox folder, then back down to Installed Plugins. These are your public plugins. For Built-in plugins, go to Robox → Versions → the folder containing the studio application, there should only be one → BuiltInPlugins. Once you have those three, I’d bet we’d all love to see them ^.^

1 Like
#22

Yes, this is a malicious script. You almost definitely ran a rigged plugin which inserted code at startup. The bright side is that private module support is being discontinued which hinders a good amount of malicious infection attempts like this. Check your plugins, check your assets, clean your game of foreign material.

#23

I find it interesting that the author used a public module for this attack… not that a private module would have saved them from our prying eyes. Private modules arn’t actually 100% private, consider it obfuscated.

1 Like
#24

“Exploit” developers who add infected code to plugins and bot them to a popular state assume that the user installing them isn’t knowledgeable about the methods they’re using, despite being “out in the open”, so those who don’t bother to properly check code get affected by this. It’s a bunch of redirection nonsense, I can only assume.

2 Likes
#25

This is slightly off topic, but one more post for me. I had mentioned earlier that having a trusted authority to certify code is probably a better method than requiring everything to be public. At least non-technical developers or those without the inclination would know which code they can trust and which might be risky at a glance. If someone wants to revive that post, I’d be happy to add some more comments xD

1 Like
#26

Ok ‘PluginsFolder’ is empty so no local plugins.

I can’t upload a folder to the forums for some reason but there are installed plugins and the same with built-in plugins

#27

How about a link to a file sharing service?

#28

Am I allowed to?

Bare with

#29

I just glanced through the rules quick and didn’t see anything about it. It is a common practice to post links to github with code and possibly executables. If you would like, you can upload each of the rbxmx files one by one instead of the file.

#30

I’ll risk it for the sake of time

Here: Dropbox
(for any moderators who might think this is leading people off-site for a bad reason, it is a link to a folder containing my current plugins)

#31

I’m not seeing the bad plugin. I’ve checked your 8 public plugins but haven’t gone through the built in ones (they are massive, and more trusted). The thread above does list an offending plugin, and the obfuscated code responsible is immediately apparent… unlike in your plugins. Now, installing the offending plugin listed in the thread above, it is shocking to me that the injected back doors exist in a new place even after the plugin has been removed. This may be the case with your plugins; the offending plugin has already been removed. When you found out about this issue, did you remove any plugins? What plugins have you used in the past couple months?

Note: I’m intentionally not listing the offending plugin’s name listed on the other thread; doing so is a breach of trust.

#32

The very concerning thing about this plugin attack is in the sourcecode, at least with the loader I found, it loads the infected script directly into game or the place itself.

i.e.

require(xxxx).Parent = game.PlaceId

Not sure if it’s actually parenting the backdoor to the place file itself, or if it’s sticking it somewhere else that we can’t decipher.

1 Like
#33

I haven’t removed anything today, when I found out about it but I have removed many plugins within the month. I have one in mind which I am going to investigate now though.

#34

Forgot that new members can’t access that area. For anyone still looking into how to remove the backdoor scripts I made a plugin to combat this. You can view/install it here: https://www.roblox.com/library/2670956620/Hidden-Infection-Script-Detector

#35

I had those in my place as well. And the place was new and I hadn’t inserted anything into it.

#36

@IdiomicLanguage and myself have found the solution to this.

What I did is I completely uninstalled both the Roblox Player and Studio and reinstalled them. I then went into my infected places and ran this code (credits to @IdiomicLanguage again):

local function scripts(instances, i)
	for i = (i or 0) + 1, #instances do
		local instance = instances[i]
		local success, result = pcall(instance.IsA, instance, 'LuaSourceContainer')
		if success and result then
			return i, instance
		end
	end
end

for i, source in scripts, game:GetDescendants() do
	print(source:GetFullName())
end

This will print every script in your game. If you have any thing coming up under the DebrisService, TweenService or InsertService with strange looking names, you’ll have to manually clean them out. The insertservice one is the dangerous one so make sure there is nothing there.

In order to get rid of them, run this code in the command bar like the other code:

game:GetService(“NAMEOFSERVICE”):ClearAllChildren()

We’re still in the process of trying to work out where this came from and because of this, I won’t be falsely naming the wrong offender.

Thank you everyone for all of your help in solving this! :smile:

10 Likes
#37

I found that it was a plugin I had installed that kept putting the script into InsertService, as well as one in Debris. It was a Object to Lua Serializer. Good thing they didn’t code it well so it had the errors showing up in my studio.

1 Like