Encryption: ASE-2


  • About

    I created a encryption that allows for safe data transfers from client to server.
    ASE-2 stands for Advanced Smart Encryption 2.0 and was changed to 2.0 from 1.0 because of how insecure the predecessor was. Both of them are very similar to AES-256 and can encrypt any type of string.

    Showcase

    ASE-1
    Decrypted: This is a string
    Encrypted: https://pastebin.com/raw/Ck0a4RXv
    Key: SmartKey_74bef8ad12f3bb5904db855a00d6c139c8bd

    ASE-2
    Decrypted: This is a string
    Encrypted: https://pastebin.com/raw/7Zn5PV1Y
    Key: SmartKey_74bef8ad12f3bb5904db855a00d6c139c8bd


    How it works

    It was made via Lua, and encrypts using 3 different encryption algorithms.

    Encrypting
    It works like this:

    function encrypt(message, key)
    

    And it returns the encrypted string. It has the key attached to the string.

    Decrypting
    It works like this:

    function decrypt(message, key)
    

    And if the message and the key doesn't match, it will return nothing, nothing at all.
    I understand that since this encryption was made in Lua, it can be easily reversed or something like that. But no, I currently own ASE-2 and will keep it private until further notice, and that the keys can easily be bruteforced, but I created a keygen that allows me to generate keys, much like the one listed in ASE-1 and ASE-2.

    Summary

    It is appreciated to show your thoughts, very positively, and if you see something that might be a problem, please respectfully show it. Thank you.


  • @SmartNode Too much work. Don't bother.


  • @SmartNode

    Nice, maybe I could use it for datastoring, but I really don't see much cases in ROBLOX where this may be useful.


  • Definitely uses this to send encrypted data via client to server and decrypting it serversided to get accurate information- to reduce the chances of exploiters knowing what kind of data is sent.


  • @SmartNode Oh but the client can decrypt it themselves, aaaaand...

    T O O M U C H W O R K

  • Global Moderator

    @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.


    About Encryption

    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 encrypt() and 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?
    • etc.

    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.


    Conclusion

    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.


    TL;DR:
    Encryption not good enough. Write server-side checks to ensure client requests valid.


  • @Link150 alright


  • @SmartNode I wanted to add in that developing your own encyption is a bad idea. Why? simply put it is easy to get wrong and there are a lot of ways in which encryption can go wrong.

    Stick to the standard encryption methods which have mathmatical proof of their secirity. Even standard encryption methods have faults and this is with a lot of researchers doing large amount of tests.

Log in to reply
 

Looks like your connection to Scripting Helpers was lost, please wait while we try to reconnect.