Currently I have an input module which reads and handles all inputs sent from the client, I do know for a fact that any thing replicated to the client can be viewed and accessed by an exploiter. So how do I go about knowing which modules should be replicated to the client and what shouldn’t be.
Of course this is a subjective question but from a general standpoint, can I safely let clients have access to my input module? Or should client modules only be restricted to effects such as abilities, weather, etc?
Or as an alternative, can I instead move the client module into a server one and instead invoke a request using remote functions and get the calculated data from the server?
Exploiters can see and change modules replicated to their client, but unless it’s secret code you don’t want anyone to see, you can replicate it to the client safely.
Changes of the exploiter for module scripts won’t replicate to the server.
I’d say, if only the server needs the module, place it in serverstorage.
I see, however wouldn’t this still mean that the client can change and manipulate values in a module script since the information is being sent to the client BY the client?
i.e LocalScript → ModuleScript (Located in ReplicatedStorage) → LocalScript (Same one as before)
Yeah you shouldn’t rely on client logic for important things, the client can always change that.
For example:
when making a shop, you should process the purchases on the server, the visual aspect of the shop can be done on the client. The prices of each item may be available to the client (to visualise the prices in the game) and server in a module script but the check if the player has enough money must be done on both client (for normal players) and server (if something went wrong/exploiter)
Edit: But changing values in the shared module won’t replicate to others, only the client can see the changes
You could invoke a remote event/function to a server script in the serverscriptservice that handles private modules inside the serverscriptservice so the client can’t see them. The serverstorage could work too but the serverscriptservice is designed for server scripts and modules.
I would use remotes instead. Use :InvokeServer or :InvokeClient its much safer than just using :FireServer or :FireClient. When passing information through I would encrypt it and decrypt it on either end.
(Do not make the encryption in a module or bind it to a event)
Right, as I stated in my post I did mention “Invoking” which correlates to RemoteFunctions.
However, as many others have already said on the DevForums, I do not believe in security through obfuscation.
edit: @Premedius Modules are mostly used for making your code cleaner and introducing code reusability. This is why I wouldn’t place event listeners in modules but it’s up to you what you do ofcourse
well Imagine ive got a key with 104 characters in it (Same as keyboard)
The total number of possible combinations for just simply swapping characters is:
380380
Top this with adding in a random character between each of them and well. exploiter wont even bother because of how long it will take.
Edit:
So yes there is a point in doing it. So long as you actually properly do it. And what ive just shown is just a basic encryption. Theres so many different things I could do to make it harder. For example encrypting it twice would make the different possibilites 39939900. So its very useful. I used stuido to try to calculate that, and belive me, it did not like it.
Right, but keep in mind that there are automatic deobfuscators, although I do understand where you’re coming from, I would assume that this would keep most script kiddies from exploiting.
I believe creating a safe and secure system with appropriate sanity checks, and a good server-client communication model is a far better time investment compared to obfuscation.
Server sided sanity checks can’t be “figured” out just like that, and even if they do manage to somehow figure it out, it’s impossible for a client to get past any proper sanity checks on the server as long as your game is built on a proper server sided foundation.
Not true, you can do sanity checks server-side that completely eliminate exploits for that particular problem, even if the exploiters know what you check for (example: store system with server side validation). Ofcourse, securing everything is not always possible…
It may be server sided but if you want to check the sanity of the client. There will be communication between client and server in order to do that. Anything that reaches the client can be accessed by an exploiter.
You can always use the messaging service to do a sanity check, exploiters only really look at the events as most of the time that is the main means of communication for most games. They cant see it if they arent aware you are using a different type of communication.
