Fastest way to communicate from server > client?

Help and Feedback Scripting Support
#1

What do you want to achieve?
I am making a key system for remote events and I want the fastest way to transfer my key to the client

What is the issue?
So, how the script works is it generates a random key on the server and then fires a remote event to all the clients with the key. Then one LocalScript has a variable like _G.key or something and then you could fire events using that. Then the LocalScript fires the same remote event back to the server and the server saves that key. (so it can check if a remote event fires the right key). I have found a bypass to my key system and that would be firing the remote event with the arguments like " " or something simple and then you could fire the other remote event with " " because the server thinks that is the right key.

What solutions have you tried so far?
So far, I have thought of checking if the key was a guid but the exploiter could just fire the same guid so that would not work. Another thing I have tried is not sending a request to the server at all and just keeping the correct key in a variable on the server. The only problem with this is it takes like .3 or so seconds to send the key to the client and by then on the server the key is already changed. I changed the code so it would change the key only once every second but there is sometimes an error because it was too slow. Is there another way to send data from the server to the client other than remote events?

Also, before you say, “oMG kEy SySTeMs dOnT WoRk BeCAuSe ThE ClIEnt CaN sEe THe ScRiPt. NeVeR TrUSt ThE cLiEnT. JuST dO sErVeR SiDe CheCKs iNsTeAD!!!111111!!1!1!1!!1!1” know that my localscript is obfuscated (doesnt mean that it won’t get cracked, just a very low chance), this is not an actual game, just a key system i’m making for fun and might use it in later games (so if i made it into a game i would add checks but there is nothing to check in this).

Thanks!

1 Like
#2

I’m aware that you know cheaters can read client scripts, but obfuscating them isn’t really the best idea. It just gets in the way of future development and, as you said, there is a way to get around it.

I would assume the core issue you’re trying to fix by this system could be solved by really simple methods that make development easier and don’t require you to make a key system like this, because, I will repeat, this isn’t a good development practice.

What should you do about it:

I’d recommend securing all of your remotes with sanity checks when they’re fired to make sure the data sent by the client is valid.

An example of this:

Client: Hey server can I equip this gun
Server: *checks to see if the client has this gun*
Server: Well it says here that you don’t have this gun in your inventory, so no

Trust me, if you have a well designed game with the above practice you shouldn’t have to worry about making a key system. Inevitably, yes, people will try to exploit your remotes so it’s your job to make sure you validate any information sent by the client.

1 Like
#3

I have all my scripts saved on another game that is private and they are not obfuscated so i just edit them their and then obfuscate it and put it in the public game if it needs to be updated. Also, can you read the 4th paragraph? lmao.

#4

Obfuscated scripts can still get deobfuscated though? lmao. You can also just do a key system on the server?

#5

Again, script obfuscation is a bad practice, and as you’ve just said it takes extra steps to modify any scripts in your game.

In regards to your other statement, I still wouldn’t recommend making a key system like this because of what I’ve already talked about, but if you insist here’s what you want:

You can’t really speed up the time it take too communicate from server to client. That 0.3 second delay that you mention is variable is is due to change (this is ping). Anyways, you might want to check out BaseValues which are values that are instances (such as ObjectValue, IntValue, NumberValue, etc).

I’m not really sure if the information transfers faster, but it would basically let Roblox replicate the data for you through the instance. You’d ideally want to put something like this in ReplicatedStorage (do note that all clients can read this value).

#6

Yes, they still can get deobfuscated, but it is very hard to do so:

I have a key system on the server lmao…

#7

Thanks, I have tried this but it still has the delay and also is not that secure (the exploiter could just fire the remote event with like RemoteEvent:FireServer(game.ReplicatedStorage.keyValue.Value)). Thanks for the reply though!

#8

Well then I’m afraid that you can’t speed up the network transfer as it depends on the connectivity of the client to the server and so on. This is an issue with all online games, so you’ll just have to work around it.

#9

I would recommend looking into key exchanges like the Diffie Hellman Key Exchange if you want to look at a secure key exchange system for remotes. Obfuscation makes this sort of key exchange take an enormous amount of effort to break, and, while, people do consider it bad practice I can’t deny that fact. (Not that I recommend using it)

Key exchanges like this are the concept behind HTTPS. The actual key exchange system behind HTTPS is (was) RSA. Here’s some information on that: How Does HTTPS Work? RSA Encryption Explained « TipTopSecurity

As long as you are assuming your obfuscated script is not easily broken, you can assume that it will be enormously difficult for an exploiter to track down the client-side private key, hence, you can assume that intercepting, modifying, or producing requests will be just as difficult without brute forcing.

Here is an article I wrote on securing your game in a “more correct” way: How you should secure your game - A beginner guide for secure networking and developing anticheats

Here is a (bad) POC diffie hellman implementation in Roblox: Diffie Hellman Key Exchange Localscript Encryption - Roblox

There is no real way to transfer data faster than via remotes, property replication can still technically be faster in some cases however comes with huge caveats, and isn’t guaranteed to be faster.

3 Likes
#10

That module looks like a backdoor but whatever. Thanks for the information, it’s really helpful!

EDIT: The Diffie Hellman Key Exchange is a good idea but I want the key to be random every time (still probably possible) and also if my script gets deobfuscated then it would be very easy to just copy and paste the key generation system. Do you think it would be better to do the Diffie Hellman Key Exchange and have the risk of the localscript being deobfuscated or have the risk of someone checking when a remote gets fired from the server and grabbing the arguments and using that to fire a remote event?

#11

I have literally no clue why you’d think my module is a backdoor lmao
Effectively if I’m remembering, it takes source for a local script, communicates a shared key, and sends the encrypted source to the client, which then uses the shared key to decrypt the result and load it via a loadstring (basically a lua in lua interpreter) module.

Also, like I said, that’s just a POC, NOT something you should legitimately use in your game (don’t),

Deobfuscating a script does not reveal the shared key, the shared key is communicated between the client and the server when the game starts. This is exactly what a key exchange is, again, this is how HTTPS stops content from being intercepted or modified. A person intercepting the remotes cannot just magically use the arguments to fire it again, again, this is how a key exchange works, it prevents man in the middle attacks by never passing data at any point that might allow someone intercepting it to modify, forge, or view it.

The client and server both come up with the same key without ever actually sending that key, and they use that same shared key to encrypt and decrypt. Its entirely possible to randomize this (In fact, this is basically what HTTPS already does). An exploiter would need to be able to produce the same shared key as your localscript and server script, which means they would need to get access to the private key within the localscript.

Obfuscation makes this extremely difficult, which is why I recommended using key exchanges in combination with this. It prevents MITM attacks, and obfuscation helps keep the key secured. You should, absolutely NOT rely on it being secure. This is bad. Instead, you should use it as a way to help ensure even with proper remotes, an exploiter would have an extremely difficult time using them at all. You might, for example, include a timestamp in your encrypted data, and have the data expire. Or perhaps, use a rolling key or unique identifier of some kind in the encrypted data, and on the server use that to validate each request, and ensure the same request can’t be sent more than once.

1 Like
#12

This looks kind of sus, sorry.
Thanks for explaining more on the key exchange thing. How would I get the same key for encrypting/decrypting? Also how would having data expire/inculding a timestamp/rolling key (like user id?) do anything? Thanks for the detailed reply!

#13

I can maybe see why that might be sus, but I mean, read the source haha, it’s really not that much to look at. Again, its a proof of concept usage, not something you should be legitimately be using nor something I mean to say you should use. It’s something to look at to understand it, as an example, its not an API or a library, or a tool.

Also, that’s what I was saying, that’s what the key exchange does. The point of the key exchange is to come up with a shared key (you should research the Diffie Hellman key exchange as well as maybe RSA key exchange and public private key cryptography).

Secondly, the point of a timestamp/rolling key in the encrypted data, as I said is to make sure the exploiter doesn’t just fire the remote again. If the remote gets fired two times with the same intercepted content and it has a unique id of some kind that clearly matches, it clearly is a duplicate, and thus clearly was fired by an exploiter. (An easy way to do this is include os.clock for example)

#14

Yea, I researched the Diffie Hellman key exchange some more and I think I understand it now. I think one way I can implement it in my key system would be to encrypt the string I’m sending to the client and then decrypt it on the client so if the exploiter intercepts it they have the hashed version and not the key. The problem with this is that they could intercept the encrypted version and the encrypted version works as the key because on the server I could check if the first argument is the same as the encrypted version of the key but the exploiter could just send the encrypted key that they got from intercepting it when it was being transferred. I will look into the RSA key exchange later. The os.clock thing is a good idea but it would be easy to bypass (I’m still going to include it with the key).

EDIT: I researched the RSA key exchange a bit more and it is similar except it would be like encrypting the key on the server, sending it to the client, which the client can use until the key is changed again (every few seconds) and then when a remote gets fired to the server it decrypts the first argument and if its the same as the key that is stored on the server then let the remote go through. Again, the same problem would be someone intercepting the encrypted key and they don’t even have to decrypt it to fire the event.