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

[absentdenik (dauser)]

They could replace the module script with thier own code using autoexec in thier executors.

[LuaBaseScript (Janx)]

I already explained why it is totally pointless and won’t replicate to the server. You should comment If you can give non-misleading, constructive and useful information.

[rogeriodec_games]

@LuaBaseScript

No, Exploiters can not modify the ModuleScripts

Sorry, but if you claim that a ModuleScript CAN NOT be tampered with by exploiters, that would be THE SOLUTION TO ALL PROBLEMS, because then it would be easy, just put all the scripts inside ModuleScript and that’s it, we would never have problems again.
I just don’t think it’s that easy…

[LuaBaseScript (Janx)]

I do not understand what you are talking about. Exploiters can not easily modify the source of ModuleScripts which is pointless which i explained in the same thread you quoted (And also it will only affect their client), and both cannot modify nor read the source of Scripts even if they tried.

[rogeriodec_games]

@LuaBaseScript

Exploiters can not easily modify the source of ModuleScripts

You seem a little impatient, but I have maybe a little experience in this area (40 years). I just don’t have that much experience in the Anti-Exploit process for Roblox. That’s why I’m asking.
I know exploiters cannot intercept source code, that goes without saying, but nothing prevents them from tampering with code compiled through a decompiler. And if the compiled bytes of the functions are inside or outside an array, as long as they are VISIBLE to the client, it can YES be tampered with.

And even more, going back to the original issue, apparently, if this ModuleScript is in the ReplicatedStorage, it can be tampered with even for the Server:

Can exploiters exploit Module Scripts?

Basically any script that’s in ServerStorage or ServerScriptService CANNOT be accessed in game. Now, If it’s in ReplicatedStorage, they can easily get to it,

[LuaBaseScript (Janx)]

You initially asked

will this tampering be IMPORTED into ServerScript that uses the same module

As everyone has stated, if those ‘bytes’ youre talking about can be modified in memory they will still not replicate to the server, it is only in the memory of the client.
So obviously not!?

[rogeriodec_games]

There was a derivation from my original question about Server, where you added that it would be impossible to tamper with a ModuleScript even on the client, so from your statement I wrote the last post, contrary to what you stated, it is YES possible to tamper with a ModuleScript.

[rogeriodec_games]

And to be clearer, I think the following:

1. A ModuleScript can be tampered with.
2. If the ModuleScript is stored in the ReplicatedStorage, it will be available to the client, so it can be tampered with in the source (ReplicatedStorage).
3. If ServerScript receives the module from ReplicatedStorage, then ServerScript can receive the ModuleScript PREVIOUSLY TAMPERED.

It was clear?

[ShaShxa (Sha)]

I’m pretty sure that if a ModuleScript is being tampered with on the client, the server will not ‘receive’ the changes.

Think of it like this:

You modify the code of the ModuleScript
The changes are only being made locally
The server requires the ModuleScript and ‘sees’ the original source code, because it didnt get the changes from the client.

So yes, it can be tampered with but not server-sided
Based on my knowledge

[Downrest]

@rogeriodec_games

If ServerScript receives the module from ReplicatedStorage, then ServerScript can receive the ModuleScript PREVIOUSLY TAMPERED.

Nope, not at all.

Like what @LuaBaseScript mentioned, yes technically it can be tampered. But it is negligible because the changes made will not apply to the server and other clients.

Here’s a small little test that you can do:

-- module script
local module = {}
module.test = 1

function module.AddValue(num)
	module.test += num
end

return module

-- local script
local RS = game:GetService("ReplicatedStorage")

local module = require(RS.ModuleScript)

module.AddValue(10)
warn(module.test, " on client")

-- server script
local RS = game:GetService("ReplicatedStorage")

local module = require(RS.ModuleScript)

task.wait(3)
warn(module.test, " on server")

[rogeriodec_games]

Thanks, but your test doesn’t demonstrate how ModuleScript would behave after tampering.
My question is: if the ModuleScript is in a ReplicatedStorage, as we know, any change in a ReplicatedStorage is replicated both to the client and to the server. This leads to believe that if tampering is committed within ModuleScript (which is in ReplicatedStorage), this tampering will also be replicated to the Server.
So far I have not had any technical arguments to refute this question.

[ShaShxa (Sha)]

You can check out Filtering Enabled

From the article:

When FilteringEnabled is disabled, the place is in ‘Experimental Mode’. In ‘Experimental Mode’, changes made to the game on the client replicate back to the server. For some, this makes games simpler to make, but means exploiters can change nearly anything in the game (such as deleting the baseplate).

When FilteringEnabled is enabled, everything continues to replicate from the server to the client (with a few exceptions such as ServerStorage and ServerScriptStorage ). However, actions made by the client will no longer freely replicate to the server. Instead, RemoteEvent s and RemoteFunction s need to be used by the client to ‘request’ the server preforms certain actions on its behalf.

[rogeriodec_games]

@ShaShxa

You can check out Filtering Enabled

[Downrest]

@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 (ThisMangaOnHiatus)]

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.