Would this be enough to secure authenticity for remotes?

Since there are things like remote spys, would the following be enough to provide a decent sort of authenticity for remotes? It doesn’t matter to me whether or not the player can view the traffic, but more so tamper with the parameters.

  1. Player enters game → is sent a secret key “p” via InvokeClient (other players can’t listen to this traffic). Ideally this is done instantaneously on player entry and player is unable to inject some listener (?) Maybe this assumption is false…?

  2. Each time a player wants to register a secure action to server, it uses p to encode a verification token. Token can be super simple like randomseed(p) → generate random string? Increment key p->p+1

  3. Server uses same key p to generate and verify that token matches. Transaction proceeds and server increments p.

Is this enough? And is my assumption on step 1 correct?

1 Like
  1. If you need to do this, you’ve done something wrong. You should never need to do this.
  2. Even if they don’t inject in time to detect the secret key, the key still has to be stored in memory, and thus, still can be seen.
2 Likes

InvokeClient is very unreliable. The remote can just hang there if the client lags a lot (exploiters can probably abuse this with a lag switch or something). Also, exploiters can see anything on the client, so keys and encryption are useless anyways. You are better off doing actual logic checks on the server

1 Like

Dang that’s disappointing. I was assuming that in-memory values would be harder to access especially because of lua being a sort of abstraction in itself. I mean, it has to be at least decently difficult to read memory values in the first place right? But yeah I guess it’s not a good guarantee…

Are sanity checks really the best we can do?

It is. The client can use their executors auto execute folder to inject scripts and have them run even before ReplicatedFirst triggers. This can be grabbed from the beginning, but that’s not even necessary with them having the ability to grab it from memory.

They have a function called getgc which gets everything in the garbage collection. So your keys are not secure wherever they are stored on the client.
Also, InvokeClient should never be using imo, exploiters can just set the function to be called to be an infinite wait loop/crash loop, causing the server to hang indefinitely (afaik).

Also, your encoding module’s encrypt can be hooked to retrieve the key (and even modify before its sent to the server)

If its done on the client (which it is), then the exploiter would have access to that increment process and would just track the increments since they join (and set the spoof increment into the place its being stored, when they fire events)

Focus more on securing your server than securing the traffic in between. They can change any value being sent to the server, by hooking __namecall. Any security wouldn’t take much time at all to bypass.