I have never tried to make an anti-exploit script in my life and I’m not too well-versed in exploiting in general, so I know this is probably a flawed idea, but it doesn’t hurt to ask.
Essentially, what I envision is that when the player joins, the server will fire an event to the client with a randomized key, and anti-exploit scripts on the client would pick up this event, and for each second passing the anti-exploit scripts would fire an event back to the server with the same key (and the server would validate the key and crash the client if it detected anything weird).
I thought it was all good until I realized the exploiter could also pick up this event, delete the anti-exploit scripts, then fake the event back to the server with the key it received from the event.
Although it seems nigh impossible, is there any way to prevent exploiters from receiving certain events (at least before the anti-exploits)?
Probably not, and the only methods that might be able to stop exploiters from seeing the event would probably be extremely hacky and patched very quickly. I would focus on designing your game to not have exploiters in the first place, or mitigate their effects.
Edit: grammar
As pokemon said, it’s pretty much pointless to depend on client-sided anti’s. Exploiters can easily spoof data or delete the event if they want to (or connect it to their own). I’m not saying it’s completely useless. You might be able to stop “script kiddies” who just copy-paste leaked exploits with no knowledge of how it works. However, anyone with decent enough knowledge could easily bypass any client-sided measures you have in place.
Your best bet is to make sure you’re verifying all important information via server. Never trust the client as data sent from it can easily be manipulated. Although depending on what kind of game you’re working on, you might need to rely on the client for certain things. E.g most gun games have their hit detection done on the client because having the server handle it would make the overall player experience “bad” (due to latency, lag, hits not registering, etc). So what most do is send the data to the server and try their best to verify that the player actually hit their target.
In the end, making an anti isn’t a one-time job. Its a tedious task and you’re going to have to constantly update your methods to counter new exploits.
Same as you stated. When working with client-information the following principles are very important:
Trust but verify: The server should never rely solely on user generated information. Some information is not obtainable from the server, in which case it would need to perform a Sanity check.
Request, not demand: The client should never demand the server to do something, only request it. The server should always have checks to make sure that the information received is correct to the extent it can, and should always check if the player should be able to do something. For example:
Let’s say you have a shop script. The local script conducts currency checks on the client and then send the event to buy if the client has enough cash it sends a remote event asking to buy the goods.
A bad solution would be to trust that the user didn’t spoof the event and actually has enough cash.
A good solution would be to check if the player has enough currency and then carry out the purchase.