Hello!
Recently, I’ve been developing an anti-exploit script that runs on both the client and the server (no need to worry). I noticed mostly everybody frowns upon client-sided anti-exploit scripts or anything that needs to be accurate since exploiters can spoof results. The question I would like answered, is there any method of creating a “secret” so that a server can validate if data coming from a client came from a specific script. (Essentially, validating a scripts identity)
So far, I’ve tried having the server create random keys to use as a method of authentication, but a way of securely transferring this to the client probably isn’t possible (since remote events can be spied on).
No, I don’t somebody to write a script, that’s my job.
Is there any way of doing this, or is it just a lost cause (fine if it is, was just wondering)?
Yeah there is not a safe way to share a secret between a client script and server script. On the server side you should treat all information you get from the client as if it’s an exploiter trying to gain the system.
As you mentioned, it is true exploiters have methods to spy on remotes. They can even decompile and see the code you’ve written in a local script. Best way to circumvent exploiters is so check that messages/requests the server gets from the client are checked for consistency and make sense.
Example: If the client is trying to get a weapon from the shop, but is no where near the shop, do not give the weapon.
Like you said, exploiters can spoof the data and validation is pretty hard. Others here have pretty much sumed everything up (server checks, debounce…), so it can’t hurt if I mention something partially related. Using HttpService, you can generate GUID, which is a universally unique identifier, that may come in handy from time to time. We could safely say that there is no way a Roblox exploiter could predict the GUID in advance. When working with remote functions directed server-client-server, we have to be even more careful. We can’t let the client be the reason for server scripts breaking. Server is waiting for the response and the danger persists in the possibility of it not getting any and thus yelding. There is a very useful module called Postie (which I will link soon), intended to add timeout to remote functions. Back to the unique code. We pass newly generated GUID along as an argument. Because everything happens extremely quickly, exploiter has a harder time changing the values. Server expects the same GUID back fast to compare it with the sent one and accepts other data only under the circumstance that it matches.
I’ll give it a look, although seems like a little bit more trouble then its worth.
I’m pretty sure there are some exploits capable of intersecting remote events that happen instantly though.
I didn’t have to use Posie or server-client-server directed remote events much in the past. Of course that’s nothing new, because there is basically no way to prevent argument reading. This is a common problem we can’t do much about. I suppose what I said helps us make exploiter’s attempts harder by drastically limiting the response time. We add a small delay and expect GUID back. At the same time, we meet two problems that spoil everything. 1) Latency (we can’t securely synchronise ping time and delay) 2) Remote signal limit (the goal is to send as small amounts of data as possible across client-server boundary. So is this something revolutionary? Not at all. Is it useful? Perhaps in some cases. It’s useful to know what GUID is anyway, because it is, however, common in other development areas.
It doesn’t even have to be GUID, but rather a randomly generated 5 characters long string.
Is it possible, however, to fire a remote function to the server faster than an exploit can inject and start spying? For example, the moment a player joins a server?
