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:
- A ModuleScript can be tampered with.
- 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).
- If ServerScript receives the module from ReplicatedStorage, then ServerScript can receive the ModuleScript PREVIOUSLY TAMPERED.
It was clear?
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
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
ServerStorageandServerScriptStorage). However, actions made by the client will no longer freely replicate to the server. Instead,RemoteEvents andRemoteFunctions need to be used by the client to ‘request’ the server preforms certain actions on its behalf.
Incorrect. My thread asked whether exploiters could access or modify the ModuleScripts in any way. Not only whether they can be used or not.
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).
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
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.
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?
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)
