How to identify altered RpcParams in NGO?

Im building a turn based card game.
Whenever the client does something on there end, they send an Rpc to the server, the server validates the Rpc and if the validation succeeds, sends it to every other client, if not the sender gets kicked.

Question:
Can the client who sent the Rpc to the server alter the information in RpcParams?
If yes, they could intentionally sent the Rpc with an id of another client to get that client kicked.

Is that possible? How can the server identify if the RpcParams contains the id of the client who actually send the Rpc?

Edit:
I did a little research and found out that it is possible to alter the RpcParams.
My solution would be to assign a randomly generated unique key to each client (by the server) and when the client sends an Rpc they also have to include that key.
If the id + key doesn’t match on the server, the server knows the Rpc was altered.

But the problem still remains that i can’t find out which client send the altered Rpc…

I’m not aware of anything NGO does to prevent modified parameters. I bet it would be pointless anyway because everything you get from a client could be altered. Between the application and the network send layer any process with high enough privileges could read and alter the data about to be sent, this doesn’t necessarily require modifying the application.

Although this sort of thing happens almost exclusively to prime targets, ie Counterstrike and the other Top 500 online games.

They might.

This would take another roundtrip, asking the client if he really wants to quit, and either the client says “yes” or “no”. In the latter case the disconnect RPC was spoofed and should be ignored (actually, kick the spoofing sender).

Although any effort beyond that is pretty much wasted until the game reaches the Top 1000 reliably. I’d say that translates to at least 100 CCU every day (Steam, not representative). Best to install only monitoring/logging for now, and whenever something fishy happens you can act upon that and publish an update. If cheating is a huge concern, that’ll be your workflow because cheaters will always find a way, you need to figure out what they’re cheating with, fix it. Rinse, repeat.

Exactly, that’s called a session token. Makes me wonder if NGO or Unity Transport doesn’t actually have or use one already. I mean there’s quite a lot of overhead in an RPC ie if you send a single byte as param the packet size is around 50 bytes if I recall correctly.

1 Like

What do you mean by this?
If the server detects a mismatch between the received id and the key, send a confirmation to that id and ask if that client actually send the previous rpc?
But in that case any client could just deny it (even the real sender) and the server would still not know who the real sender is, or am i understanding this wrong?

Say we have clients A and B and the server. Client A is the one spoofing a request on behalf of client B.

  • A sends RPC with spoofed clientID of B (masks as client B)
  • Server responds by asking client B for confirmation just to be sure
  • client B responds: nope, i didn’t do it
  • Server receives B’s response and ignores the request
  • optional: Server taking care of client A (ie kick, ban) if server can identify client A as the spoofing sender

This assumes client A did not, in whatever way, get B to run a hacked executable. Which is unlikely so you can trust B when the confirmation comes back.

1 Like

Thanks for clarifying.
I think for now I’ll just stick with the session token and implement the rest when it is really needed.