Looking for more answers regarding this since some threads don’t directly refer to a question of this type (people mostly ask about the data of existing modules in-game, not requested ones).
For example, I’m looking to have the module be requested in a LocalScript inside of a tool.
Can I ask you for a more in-depth and contextual explanation of what exactly you are trying to prevent here? What requested module data? Perhaps an example would help.
Basically, I’m trying to make an extra anticheat for a specific combat tool that uses .Touched, but inside of it. Other than that, I’m running checks on both client and server.
Now, I did try various alternatives to .Touched that are exploit-proof, but recoding the tool with new approaches caused it to not have the 1:1 feel. The community doesn’t want to adapt to the new tool, so now I’m trying to find ways to combat them while still retaining the .Touched function.
With that, with the requested ModuleScript, it would allow me to somewhat “mask” the tool’s additional client-based checks.
So with that, I’m looking for information if the requested ModuleScript’s data is visible to exploiters in comparison to ModuleScripts that are pre-existing in the game itself.
Thank you for providing more context. I will answer your main question, but I want to share some background that might help.
First, any anti-cheat that runs on the client is ultimately insecure. Anything the client runs is visible and modifiable. This means that exploiters can access any ModuleScript used by the client, whether it is required at runtime or already present in the game. Simply requiring a ModuleScript in a LocalScript does not prevent an exploiter from viewing its contents or any data the module provides.
It is also important to realize that exploiters have tools that let them see all remote events and functions being called between the client and server. Even if they do not have your script’s code, they can still watch all remote communications and analyze what is happening. So, any security by obscurity you add in your scripts does not hide your RemoteEvent or RemoteFunction calls. Exploiters can see and even replicate these calls if they want to.
Some people might tell you that client-sided anti-cheats are useless because of these facts. While it is true that you cannot guarantee security, they can still help reduce basic or opportunistic exploits. Less experienced exploiters might be deterred, but anyone with motivation and some basic knowledge will be able to work around these systems if they target your game specifically. You can try to make things harder for exploiters, such as deleting your ModuleScript and LocalScript after use, but these only serve as very minor obstacles. Once a single exploiter figures out how to bypass your system, it is very common for them to share scripts or methods with others, which quickly leads to many more people exploiting your game in the same way.
The most reliable way to secure your game is to handle as much important logic and verification as possible on the server. Any checks or anti-cheat that actually matters should be server-sided. There is a balance to be found, since doing too many things on the server can hurt performance, but anything that cannot be trusted to the client should not run on the client.
In the end, it is a constant cat and mouse game between developers and exploiters. You can never make your game perfectly secure, but you can add layers that make it more difficult to exploit. Just remember that if someone wants to bypass your system enough, they likely will. That said, you can take steps to help reduce the number of simple exploits.
Hope this helps!
Any modulescript thats exposed to the client (not under serverscriptservice / serverstorage) can be required and thus expose its returned / cached data.
Regardless, if the purpose of these client checks is to then validate this data to fire a remote event, then it is not a fruitful endeavour as they can directly manipulate the remote event instead.
Thanks for the information, it does help a lot with seeing where I’m at. In that case, yeah - worst case scenario is that all combat checks are just gonna have to be ran server-sided.
Now, I do have some additional things to ask if both of you or anyone else on the forum can assist.
To clarify as to what the tool is: it’s basically the classic “sword”. Not in the sword shape, but it does inherit its system as to how it is used and deals damage.
And I know it sounds simple by me saying that it’s a “sword-like” system, but in this combat system, people typically shake their camera while having ShiftLock on. Detection is crucial.
If it was a regular sword, it would be far easier to implement a whole new detection system.
It’s funny that you ask this, since I was just answering a very similar question about sword hitbox exploits only an hour ago. Here’s a quote from my response:
In a nutshell, there isn’t a perfect solution. Server ownership of the hitbox isn’t really feasible if the handle is welded to a player’s character, but you can protect against the most blatant exploits with sanity checks, distance verification, and possibly custom collision detection. Handling everything fully on the server will feel less responsive due to latency, so you’ll always have to balance responsiveness and security. Whatever you decide, just know that even major studios with huge resources still face these same challenges. It’s always a tough balancing act. Good luck!
if module is loaded to a client yes.
It can read current data and its bytecode that can be reverse engineered into a source* code
Bytecode will likely not contain specific naming for variables (althrough will contain names of some global/local functions)
And will not have any comments (as far as i know) so don’t worry about your comments being leaked 
The thing exploiter will get is an attempt to recreate original code out of bytecode instructions
Yeah, I did see that thread months ago and tried the module myself. But then decided to rather make my own from scratch as well. Latency difference could really be felt, that’s why it’s so hard for me to implement this.
So basically, I should just “trust” the client with hits made on their end, and run a verification on the server? That’s what I’m basically trying to code right now as well. That’s like the best possible outcome if there really isn’t a better way to rely on server’s responsiveness.
He who seeks ideal gameplay must, at times, trust the client, and pray the server stands ever vigilant. May your code run smooth and your exploiters get bored and go play something else.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.