I’m finalizing things on a project I’m making for a friend, and arriving at road’s end we realize we’ve yet to start on security and anti-exploit routines. I’ve never had any practice with it seeing as I neglected the concept as a whole prior to the large-scale update mandating all games be made with FE in mind, and I have almost no idea where to start or what to do. I’ve been perusing threads on general etiquette, techniques, and behavior, and what I’ve learned insofar is:
Obfuscation is no substitute for actual security
The client has full control over all data and processes on their side of the field
A strong server-based security obsoletes the need for client-side security
Cutting parameters too broadly when checking for cheats via server can result in false positives
I’m confident I can handle very basic anti-cheats in regards to clipping, speed hacking, and fly hacking - what I’m interesting in learning are ways in which I can protect my own game logic - hopefully without an egregious reinvention of the code I have in place so far. I have a sizable number of remotes that control everything from gameplay to data manipulation, and they’re totally unprotected. My normal solution would simply be to key the remotes, but I’ve been told that counts as obfuscation, and well - you know the rest.
I’ll describe what a few of these do, and it should give some insight on how illegal firing of these remotes could be potentially hazardous.
Damage - Client sends an arbitrary number to the server with a few hit properties, server scales the damage in accordance with the user’s stats/enemy’s defenses etc. and applies the result itself.
ApplyStatus - Client sends the name of a status effect along with the percentage of completion towards its full application, and the server sends that data to the target’s personal status effect handler module.
DataEdit - Self-explanatory - allows the client to request a change to its own stored data, specifying the parameter and the desired end result.
EditProperty - Client sends an object, name of the property it wants to edit, and the desired result. This one has the most hazardous exploit potential.
In summary, what I’m asking for are simply ways in which I can secure these remotes so only legitimate requests and signals are processed - is there a catch-all, do I need to implement multiple sanity queries in each designated remote, etc. etc.
When dealing with damage, you almost never want to send the actual number. That number should be obtainable by the server rather than sent by client.
Example would be gun damage, you should keep track of what gun the player has equipped and retrieve that specific gun’s damage.
Applying statuses shouldn’t be handled on client at all, but I guess it would depend on the game you’re making. If the status is “bleeding”, etc. you should apply those on some specfic events such as getting shot.
Data edit is also never done by the client. Exceptions would be editing the keybinds or stuff like that which you want to save to retain data persistance.
Property editing is also never done by the client. It should also be done on specific events, etc. player hits npc, change the health value.
An exploiter could potentially make your local script encrypt the arguments, and send it to the server.
Being completely honest, finish developing your game (with enough server sanity checks to prevent exploiters), and if you have an actual exploiter issue, you can focus on that particular issue. I am saying this because there is not a whole lot you can do besides “not trusting the client”, and having the server check remote event arguments. Obviously no game is “exploit-proof”, but there are ways on preventing exploits to some extent.
Your goal should remain on getting rid of script kiddies. Big exploiters will always find a way through.
As I’m sure everyone has told you above, your remotes are VERY hazardous. It’s highly recommended that you remake them (and the code sadly). Don’t forget the usual server sanity checks.
Some tips:
A strike system is appealing for when the check can mess up, to avoid false positives the strike system allows the anti system to mess up but also catch true perps.
The goal should not be to remove every exploiter, they always come back. So focus on the smaller and more frequent “script kiddies”
Never allow the client to send data through a remote without checking and reason (IE your remotes you pointed out)
Maybe you meant to say “pay attention to your game’s security”? Suggesting that common exploits should be paid any attention to is a pointless endeavour unless you focus on the structure of your code first, since the majority of small exploits are based on faults of your own code.
The two are fairly different concepts that have been taken literally (as in, I’ve seen developers try to specifically counteract exploits instead of touching up on their own code). It’s important to distinguish priorities when it comes to game security and the majority of it begins at your own code.
Protecting remotes should be your #1 priority. Exploiters can manipulate their client as much as they please, but you NEVER want to have a faulty remote that allows exploiters to change stuff server-side. Adding a lot of sanity checks to remotes is recommended. For example, having a shop buy remote, handle all purchasing on the server and checking if they have enough money for it. Or for a damage remote, if it’s for a gun or melee, check: the range between the target, what weapon they have equipped, the speed at which the remote has been fired, etc.
