-
What do you want to achieve?
I’m currently making a framework and a flaw in it is that if you’re an exploiter you can require the modulescripts within the Framework and then execute the frameworks custom functions from there, would these be possible to prevent? -
What is the issue?
I can’t find a way to detect whether or not a module has been required more then once -
What solutions have you tried so far? Did you look for solutions on the Developer Hub?
Using a CollectionService to set a tag when required, it didn’t work. Destroying the module script after loading it in to a table didn’t work as an exploiter can access the nil’ed instances.
Yes and no. You can sort of prevent it but anything you do will immediately be bypassed by any exploiter who has some knowledge of how the exploit they’re using works. If you want to follow through coroutine.running in API functions is probably your best bet but that’ll be bypassed in minutes by someone with intermediate experience.
You can’t “detect multiple requires” since module code is only ran once. Once the script is required the same reference to the same value is returned.
You should not have sensitive code on the client because there is physically no way to protect anything on the client for very long. Strings, functions, etc can be viewed, and modified without you being able to detect it. This is a common problem in all games not just Roblox which leads to many easy to spot issues which usually tell you the game is secured well.
One example of this is missing hitmarkers during lag. If you’re missing hitmarkers in lag it means the developer probably knows what they’re doing in terms of network security since they don’t let the client make the hits on their own.
There really isn’t a proper way to check if a module has been required. Module scripts when required create their own environment where they are required into.
Can you provide more details as to what exploiters can do if they require the module?
Not only can you not do this but I get the feeling that you’re trying to do something you shouldn’t be doing, which is a client-side exploit detection. You’re already bound for failure the moment you want to be fighting the client on their own machine. Don’t try to patch bad architecture with a weak band-aid solution.
Redesign your architecture so that it doesn’t matter whether or not exploiters fire functions off the framework itself or rewrite them to simulate the function calls from the framework. You should focus more on securing the server-side of your framework and ensuring the client cannot leverage it.
Hello, you can return a function witch returns the module and count how many times the module has been required
local module = {}
local requires = 0
return function()
requires += 1
return module
end
the function is returned rather than called, so that solution won’t work (actually I see where you are going with this, but I’ve heard they can still get values inside a function and not need to call it)