That is your choice and right as a developer, and is why I debated this point. Don’t get me wrong, I do agree it can be a waste, but at the same time it’s also not. It really depends on what you feel is necessary for your game, and I simply wanted to ensure that the developer as the choice in judging if this module is right for them. As long as the developer follows the initial practices and uses a resource which does as intended (in this case, provides an additional layer of security on top of proper security practices), then as the developer they should be able to make said decision with the proper information.
Interesting method, however this vulnerability can be fixed by storing the invoke server function instead of accessing through the remote object every time.
I fully understand how it works and I fully understand how an exploiter could bypass it in many ways, a couple of them include:
Hooking to InvokeServer/FireServer and getting the key(s), allowing them to fire the events.
Using getreg() (returns the Lua registry, some exploits have this) and some other exploit specific methods to find the “Channel” objects and using them from there.
No matter what you do exploiters are always gonna find a way to bypass it, you can’t win, server side sanity checks are all a game needs.
Of course it’s impossible to completely prevent exploits using client side methods, when it comes down to it the exploiter could create their own whole game client to do as they please.
Very true, and there’s no easy way to get around this vulnerability. However this would limit the exploiter to only using the remotes when the client calls them.
The API is made to be easy to use, once one knows how to use the API, it’s no more difficult or maybe even easier than using the remotes directly. The secondary use of this is as a simple organizational tool.
Basically the benefit to using this is that it’s no more difficult to use than normal remotes, and it adds a layer of abstraction to make things a little more difficult for exploiters. It’s up to the individual developer to decide whether it’s worth learning the API to use it. I’m confident it would significantly decrease the amount of exploiters, limiting it mostly to people who search exploit forums for scripts. Furthermore, this system actually wasn’t created for security, it was created for organization and convenience. Instead of having to create, name, and connect RemoteFunctions, you simply call a function to create a new connection.
A clever friend came up with a way to (kinda) fix this vulnerability, using string.dump.
string.dump errors if you call it on a C function, because you cannot dump them. InvokeServer is a C function by default, so if the exploiter replaces it with a normal function then string.dump won’t error.
To fix the vulnerability you simply do
pcall(string.dump(remote.InvokeServer))==false
As long as this is true the function hasn’t been replaced.
Which is why i said it only kinda fixes it, since it’s quite easy to bypass the fix. As clarified, the only point is to make it more difficult, not prevent it entirely.