I’m not very knowledgeable in this kind of stuff, but I think they can. If the module was required by the exploiter’s client, then they could access it’s contents (since the client needs the code to run it). That means that they would have the address as well.
I believe that requiring a module script again returns an entirely different environment, so the function wouldn’t have the same address, so it wouldn’t make sense for them to get it that way
When a client requires a module, it creates it’s own copy of the module’s contents. They wouldn’t be able to directly change the module itself, but they can change the code in their copy to whatever they want.
It is 100% possible, and easy, to access localscript variables, modulescript variables, or anything else that happens to be on the client, even if they are marked as local variables.
When a module script isn’t first required in a environment the code is ran and whatever the module script returns is returned, the next time the module script is ran in the same environment, the same thing is returned (the memory addresses will be the same)
And the client and a the server both have separate environments.
The exact address doesn’t really matter, since exploiters use lua which means they only need the function reference, not its address.
And yes they can easily grab any local variables that you use within at least one function defined outside of it (it’s called an upvalue). Same for table values and global variables.
Locals not used in any function are slightly harder for them to obtain, but not impossible.
Also
this is wrong. ModuleScripts only run the first time they are required. Next times they only return their cached return value.
Modules are supposed to be a sort of container. It wouldn’t make sense if different scripts received different copies of the container, and it surely wouldn’t boost the security significantly.