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

I have a ModuleScript used both in a LocalScript and a ServerScript.

-- LocalScript
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Module = require(ReplicatedStorage:WaitForChild('ModuleScript'))
-- Script (Server)
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Module = require(ReplicatedStorage:WaitForChild('ModuleScript'))

I know that an exploiter can tamper with code in LocalScript. I think he can do the same within the ModuleScript code that was loaded in LocalScript, right?

Now my question is if the exploiter can tamper with ModuleScript code, will this tampering be IMPORTED into ServerScript that uses the same module?

3 Likes

No. ModuleScripts are like functions that return in the highest level, A “standard” (example) ModuleScript returns an array of functions, those functions cannot be tampered with, as not only the client and server are separate and the return proccess is one way, If the ModuleScript indeed returns an array of functions, then the function in memory cannot be overwritten, only “which” function the value in the array points to.

Thanks, but there seems to be a different opinion below as to whether a ModuleScript is tamperproof in LocalScript:

The thread you have attatched asks if exploiters can use them (They can), Not what you originally asked (tamper with their content) (Which I already said, Depends).

Exploiters can modify module scripts, however it wont affect serverside at all.

2 Likes

No, Exploiters can not modify the ModuleScripts (unless they do some hardcore stuff which is pointless because of the following), they can modify what it already returned though.

Why?


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

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.

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…

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.

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:

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!?

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.

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?

1 Like

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

1 Like

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")

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.

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.