Can exploiters tamper a ModuleScript used in LocalScript when it is used in ServerScript?

[rogeriodec_games]

@ShaShxa

You can check out Filtering Enabled

[Downrest (Down)]

@anon66957764

@Defegne

If a client makes changes to the module, it won’t replicate to the server

Correct. Through the use of exploits the client can theoretically do anything, but the server will reject source code changes among other things.

And if you do something like module.x = 5 on the client, it won’t replicate to the server unless you established some sort of auto-replication via RemoteEvents or what have you. And this is all your code doing this explicitly, Roblox does not do it for you.

@colbert2677

If your current way of handling objectives is that a LocalScript updates these variables then yes it can be compromised as an exploiter could change these values to whatever they’d like. On the other hand, the server wouldn’t be able to see the object progress change if you update the values from a LocalScript and then expect a Script to be able to read and see the new values.

Here is a chart that shows what the engine sees when changes are made in ModuleScripts:

[ValiantWind (Val)]

@LuaBaseScript

The thread you have attatched asks if exploiters can use them (They can), Not what you originally asked ( tamper with their content )

Incorrect. My thread asked whether exploiters could access or modify the ModuleScripts in any way. Not only whether they can be used or not.

---

@rogeriodec_games

Exploiters can tamper with ModuleScripts, but the changes will only be replicated to the client. (In other words, the exploiter is the only who can see the changes. No one else can).

[ShaShxa (Sha)]

If you continue reading the article, you will notice Experimnetal Mode basically means FilteringEnabled is disabled.

This has changed and FilteringEnabled is now forced by roblox, which means you cannot disable it anymore and you cannot go into Experimental Mode

[StrategicPlayZ (Strat)]

The simplest answer to this is the client and server receive different copies of the module they require. The copy the server has of the module is different from the client, any changes the server makes inside the module for example changing a value in a dictionary in the module will not replicate to the client, you will need to use a RemoteEvent for this.

Similarly, if the client edits the ModuleScript’s bytecode or whatever it returned, it will be editing the copy it received, which is different from what the server has, and from what every other player has.

Note: This only applies to the code of the module and the values it returns. If the server edits the name of the modulescript for example, it will replicate to the client, but not vice versa, just like every other instance.

“ReplicatedStorage” just simply means a place where you want to put objects which are visible to both the server and the client. If you place a script in ServerScriptService, it will not be visible to the client, but in ReplicatedStorage, it will (but it will only be visible, the bytecode of the script will still not be shared with the client, because there is no reason to), but it doesn’t mean that if you put a module there any changes the client makes will be replicated, as this is not what ReplicatedStorage does.

[rogeriodec_games]

@Downrest

image960×720 64.3 KB

That’s an excellent chart made by @colbert2677, however from what I could understand, after the diamond (require), a copy is made (for the Server and for the Client), which leads to the belief that the code can be tampered with BEFORE that, generating tampering that will also be imported to the Server, right?

[Forummer]

Yes, a client can modify a ModuleScript’s source, fortunately this will not replicate to the server. ModuleScripts that are required by both the client and the server will return a unique value for each, this can be verified by running the following scripts.

--MODULE

local module = {}

return module

--SERVER

local Game = game
local ReplicatedStorage = Game:GetService("ReplicatedStorage")
local Module = require(ReplicatedStorage.ModuleScript)
print(Module)

--CLIENT

local Game = game
local ReplicatedStorage = Game:GetService("ReplicatedStorage")
local Module = require(ReplicatedStorage:WaitForChild("ModuleScript"))
print(Module)

[colbert2677 (ImagineerColbert)]

I think an important mindset to approach this conversation with should be divorced from the type of script being used - to us, the difference is mostly only eager versus lazy. The process changes for how exploiters modify the client but the result at the end of the day is the same.

Once code is compiled it can’t be tampered with. Exploits generally don’t focus on manipulating the actual execution of code which in itself is nigh or completely impossible; what it focuses on is memory and arbitrary execution. That is, either changing what certain variables point to or running something on their own end that is passable (and understood by the engine) as genuine code.

The chart in question is to show that interactions between the server and client between the same ModuleScript do not propagate to each other. Every VM (server, client, command bar, actor server and actor client) receives a different instance of the ModuleScript. For this you are correct.

When it comes to any form of tampering however, the client-server model is still applicable. Even if hypothetically it was possible to change the execution content (source) of a script, client changes cannot replicate to the server. The server cannot see anything a client does except in the case of the client having authority over replication (e.g. network ownership).

My explanation for this chart was on another developer’s worry that ModuleScript content could be changed by an exploiter. That is true, so the chart and accompanying explanation are showing that it is still fine to use ModuleScripts in lieu of this but to use a different approach when incorporating them into game-critical systems. The developer originally intended to store mission progress on the client’s instance of the ModuleScript but an exploiter could change that so I simply recommended tracking it from the server instead.