@SmartNode @incapaz If you're thinking of using this as a universal solution to protect your game against hackers then I'm afraid to tell you that all of this is unnecessary and will leave your game vulnerable to hackers.
And Why Encryption Alone Isn't Enough
Know Your Enemy
Exploiters use software called "memory viewers" or "memory editors" to view and make changes to the Roblox process's memory space. That's how they hack games; by editing the memory such to inject their own code into an existing LocalScript's bytecode.
An exploiter can therefore view the Lua bytecode generated from your LocalScripts' source code, including your
decrypt() functions. Even if you don't make your source code publicly available, hackers can copy, reuse and reverse-engineer your bytecode to understand how it works*.
That being said, they could inject code that reuses these existing functions to send to the server, through your remotes, whatever data they want, or read whatever encrypted data the client receives.
So Then, Encryption Is Pointless?
Encryption is not really totally pointless, but it shouldn't be your only layer of defense. Encryption is not at all necessary if you wish to write a properly secure game, and only serves as a bonus to make client-server communications harder to hack, should there be a flaw you missed in your remote code somewhere.
I personally find encryption only adds unnecessary overhead and complexity to a game's code. I would say, first make your game, and then, once you're done with it, think about implementing additional defenses and protections. Instead of your primary line of defense, encryption should only be something you add on top of already secure remote code.
Good Remote Code
Write your remote code such that it is impossible to exploit them. Good remote code doesn't even care if a hacker makes malicious requests, not because it makes uses of "encryption" and "secret keys" or whatnot, but because the server first checks and decides whether a client's request is valid.
The most important think to know about remotes and that is not understood by newbies is that they are meant to make requests, not give orders. The server doesn't have to obey the client. The client merely makes a suggestion, and the server should be free to ignore their request.
A Little Example Scenario
Let's say you had a remote event to ask the server to grant a player some money for completing a quest after clicking on a GUI button. You wouldn't have the server blindly give the player some money without any form of verification, that would be begging for hackers to exploit your remote. Instead, you would have the server first verify the answer to the following questions:
- First of all, are the arguments of the remote request valid?
- are they of the of the right type?
- is their value valid? (e.g, for number arguments, is the number out of range?)
- Has the player really completed the quest?
- Is the player's wallet or bank account full?
If any of these conditions is not met, we ignore the error (i.e, we simply return from the remote callback function and do nothing).
Now, once your game was complete you could go ahead and make sure all your remote communications were encrypted with a strong encryption algorithm, but I would avoid it until then because it will only serve to increase the complexity of your code, making it less straightforward.
Futhermore, as I mentioned earlier, it adds additional overhead -- encrypting and decrypting the data everytime you send/receive a request takes time that could be spent elsewhere in your game. Ultimately it's up to you to decide if you have plenty of time to do this or prefer to leave out encryption.
In this post we saw how encryption can easily be bypassed by hackers, and how encryption alone isn't enough to make a Roblox game secure. We also talked about the benefits and disadvantages of encryption, and whether it is worth adding to your game.
I hope you've learned, and that you will accept my criticism as a way to better yourself to better write Roblox games.
* : Which brings me to this very important point. A good encryption algorithm should be hard to crack regardless if it's public or not. If your algorithm can easily be broken by someone reading your code or reverse-engineering it from the script's bytecode then it is not a good encryption algorithm.
In fact, it's so easy to get something like an encryption algorithm wrong that it's recommended to stick to existing algorithms.
Also, the fact that it was written in Lua is irrelevant. The language an encryption algorithm is written in does not in any way affect its security.
Encryption not good enough. Write server-side checks to ensure client requests valid.