Exploiters and ModuleScripts

I’ve been surfing the forum and I have not come across an answer to this scenario: Can exploiters still see the code of a required module script even if that module script was deleted? This would be a big win.

Destroyed modules would still be held in nil; so yes they could still see it.

1 Like

What do you mean by ‘held in nil?’ is that a service or something?

local m = Instance.new("ModuleScript")
m.Parent = workspace
print(m.Parent) -- Workspace
m:Destroy()
print(m.Parent) -- nil

Exploiters can just use getnilinstances() function to get all the instances in nil.

2 Likes

so then instead of destroying it, I would have to move it back into a ServerStorage then?

They can just get the module before you even do that. If it’s so important the module’s source is inaccessible to clients then don’t expose it to them in the first place. Put it in ServerScriptService.

1 Like

How does getting instances in nil work?

I don’t know how it works, but it just does. Exploiters can get anything in there

1 Like

So everything in ServerScriptStorage cannot be taken by exploiters?

1 Like

Neither in ServerScriptService nor ServerStorage - the children within those services don’t replicate to the client. The client’ll only see them as empty when attempting to view.

1 Like

If the client can’t view the service the client can’t view the script inside of it.

This makes it impossible for exploiters to view the script.

The only downside to this is that the client can’t actually do anything with the script directly.

The explorer on the right side of studio is only a way of organizing all of the mess that exists in a Roblox game. Imagine something like this for the sake of simplicity.

game
Workspace
Players
Script
Part
Model

That is everything that exists in our example game. Notice how there is no heirarchy or structure to it, they all just exist. So let’s add some order to it by assigning some Parents.

game
Workspace (parent game)
Players (parent game)
Script (parent Model)
Part (parent Model)
Model (parent Workspace)

or another way to view it

game
  Workspace
    Model
      Script
      Part
  Players

That looks a little more familiar, but all we did was assign some properties. If we remove the parent of Script, it will be hidden from the explorer because the explorer only shows descendants of game.
Script.Parent = nil or Script.Parent:Destroy() both set the parent of an object to nil. Destroy does some other important things that I won’t go into. Now, the explorer looks like this.

game
  Workspace
    Model
      Part
  Players

So Script no longer shows up, but it definitely still exists. It is just not a descendant of game. Our list looks like this now.

game
Workspace (parent game)
Players (parent game)
Model (parent Workspace)
Script (parent nil/nothing)
Part (parent Model)

So you can see that the object still exists, but it does not show up in our file system. This can be the case on Roblox, Unity, Windows, or any file system. I have not heard of GetNilInstances as a function, but what it would do is take a look at all objects in the game and then select all of the ones that don’t have a parent set and provide the list of nil instances to you.

2 Likes

Side note: If you do a speedy shift of a module from ServerStorage to RepStorage, have the client require that module, and then move said module back to Serverstorage, the client views that as nil so that doesn’t work either.

1 Like