Is it possible for exploiters to intercept Remotes, and possibly event edit them?

Hi, my game relies on a method of “Remote Keys” for keeping it safe, here’s how it works (for those who aren’t aware)

I’ll refer to each firing/invoking of a remote event/function as a “request”

  • Each request will have a key
  • Every time a request is sent, a repeatable math procedure happens to the key
  • If the key does not match what it should be, the server knows the player is exploiting.

Now, what I want to know, is if it’s possible for:

  • An exploiter to see when requests are being sent
    If this is possible, they could know how many requests are being sent; making it easier to bypass the key system

  • An exploiter to see what the content of requests are
    This way, an exploiter could just compare the differences between the keys and quite easily guess the algorithm used and even predict what the future keys will be

  • An exploiter to modify the content sent in requests
    This would bypass the need for trying to even get past the key system.

Now, I do have a good client/server infrastructure and ‘never trust the client’, but I would rather be sure that it is impossible (or near impossible) to send fradulant requests.

Thanks,
Elliott :slight_smile:

4 Likes

Yes, because a colon is used to call/invoke remotes, exploiters can hook the __namecall metamethod and read the arguments in the remote. (and as you probably already know, the client can fire any remote in the game whatever arguments they want)

3 Likes

Malicious players are able to read any network traffic and manufacture any network traffic. It is common practice to do important logic and sanity checks on the server to prevent any malicious behavior from effecting the game.

12 Likes

Stop. This doesn’t protect you against anything. You’re just making it slower and possibly worse on bandwidth to use remote events.

Yes.

Yes.

Yes.

This is impossible.

Clients have full control over their computer. Stop wasting your time and effort on client side security that stops nobody. If you already don’t trust the client on the server and your server side callbacks are bulletproof (which they should be), don’t bother. There is literally no point.

10 Likes

Thanks for all the replies, they have been very helpful!

1 Like

In doubt, remember these 2 rules of Client Server Communication.

  1. Don’t trust the client
  2. Do NOT trust the client
23 Likes

I’m not entirely against security through obscurity. You’re at the Lua level, and you have to take what you can get.

There’s nothing wrong with your approach, just don’t fall into the trap of thinking that this is any more than a mild barrier to people without much skill. The bandwith costs can be minimal depending on the use case.

As others have mentioned, it’s no replacement for proper network security, and won’t stop network inspection, but it’s not harmful to have in your game.

Many games have used a key system, and they’ve had it broken. I’d advise manually changing the key algorithm as often as reasonable to force bad actors to figure it out every time you change it.

“Near impossible” is more like “it might frustrate a couple people and maybe delay someone a couple hours”.

1 Like

Alright.

I employ other network security techniques anyway (including checking if the data makes sense, if the player can do that action [e.g. a random player trying to ban everyone], etc.) but I just wanted to see if this was a reliable method, or if it even caused harm with things like bandwidth issues, latency, etc.

1 Like

Changing the algorithm wont stop someone from calling his function to get the network key. The most you could do to stop that is to make it have a randomized name each game update but that’s the only thing you could do. They could also dig up everything you use to generate the key and generate it with their own function.

I mean the general key algorithm, not merely the key generation algorithm. You can do more than just randomize the name, it just depends on the level of effort you want to put in. The idea is merely to update it frequently enough to break some older malicious code. It’s not foolproof.

It doesn’t matter how frequently you update your remote key/name/location/obstacles to get it. The basic idea is: if your localscript can fire the remote, then the exploit can aswell. Have a remote key? The exploit can get it. The data needs to be encrypted? The exploit can grab the encrypt function. And so on and so on.

The thing is, you shouldn’t rely on exploiters not being able to fire your remote, but rather on the server-sided security and checks. Even if you manage to strip their access to your remotes, a determined exploiter can use other ways to do the same thing, even if it means simulating key presses and clicks.

My point isn’t that you shouldn’t use best practices, but it’s very much an oversimplification to pretend that security through obscurity can’t offer value. You’re not telling me anyything I’m not aware of here.

You’re not saying anything new by pointing out that countermeasures aren’t necessarily fullproof. That’s not the point.

Much of game security relies around obscurity, this is by necessity.

3 Likes

Actually, it’s fairly effective what they’re doing.

You need a highly functioning exploit with the ability to edit the game metatable and override the FireServer function to intercept the traffic, decode it, then return a new key. Not trivial at all, although ineffective in principle this was implemented by the Phantom Forces devs a while back iirc.

Not saying it’s secure, but it’s certainly not totally ineffective - if you ignore the bandwidth / time implications. And your other points are very true.

Ehhh, not true. Most, if not all game security relies on serverside checks. I don’t really know of any time Roblox does network communication and makes it super confusing just to hinder malicious attackers.

2 Likes

As has been said, it’s helpful for adding a slight extra barrier, but the point is that your game should not be manipulable through any kind of remote firing. As long as you’re doing this alongside proper networking security, and using the server and client appropriately, assuming this is not consuming too much bandwidth it’s fine. Just don’t replace networking security with this kind of thing, think about it, if it was that good it would have already been done professionally, there’s a reason the client server model and the secure networking that goes with it exist.

3 Likes