Hey Scripters!
I have a question that I need answered.
What are the best ways for protecting my scripts for my product?
My product is SmartOrders, a Cafe and Restaurant system. We are currently in the Beta Testing phases, and we need a way to use script protection. Currently our provider Devable has been going through a lot of changes, and they state that Script Protection is coming soon, but I really need another solution in case it fails. Its a pain that Private Modules are gone
We are selling the product, which is why we are protecting it, so people donât steal our code and take credit for it.
If it helps, the on-game script protection is what we are using, and its when our scripts are sent to the game as obfuscated bytecode. Their obfuscation is powered by Ironbrew.
Iâm no Roblox scripter, so please avoid real technical explanations.
I assume youâre referring to protecting your scripts from being leaked by exploiters?
I know minimal regarding this topic. Although, thereâs a few things I can tell you. Make sure to put your scripts in the proper place. ServerScriptService for server scripts, not workspace. Descendants of workspace will replicate to clients; including scripts. By placing your core scripts into ServerScriptService, youâre cancelling any replication those scripts will have to clients. Obviously you need some scripts on the client, but just make sure to maximize usage of RemoteEvents and server calls to get the information you need, without exposing important data to the client that they really shouldnât have complete access to.
I hope this helps, and I hope this was your question.
I mean, if youâre selling a product then theyâll have full access to your product; which they can then do whatever they want with, which I think is fair if theyâre paying you for it.
Weâre using Devable Script Protection as we are selling it, but we need alternatives due to timing issues. Itâs like @wind_o product CheckMeIn, if we sell a license with the code exposed, they will take the code and claim credit for themself. We need an alternative to devable, for the meantime.
Discussion about selling products with closed-source code has been discussed in great lengths on the forums many times before. It would do you well to search through those threads to see if you can glean over any information that might help you out here.
The long and short of it is that without a medium from a third party or obscuring your code so that reading it is difficult to do, the market for closed-source products has been wiped as per the removal of the ability to require modules by id if theyâre private.
No alternatives realistically exist that run with the same effectiveness that the aforementioned removed feature gave. I donât know of any other mediums that allow you to call code from external sources and if youâre hoping to do it all in Roblox, then there definitely is no way besides not selling your items.
Consider repping a feature request or writing one yourself. Roblox has evidently been implementing more permissions layers to protect against both bad actors and give developers greater control over what outsourced assets in their games can do and theyâre definitely aware of the ModuleScript problem, so thereâs always room to improve the dynamic and possibly reintroduce closed source materials.
When it comes to securing code, there is no one answer as there used to be and certainly no answer can give you the level of security that closed source modules gave at one point. One thing to ALWAYS steer away from is minifiers posing as script obfuscators, as they are easily by passable with a beautifier.
There are a few ways to go about truly obfuscating your code, the first is self obfuscation. In my own experience simply shortening some variables, removing indentation, combining lines, etc, is a good enough way to self-obfuscate your code. This isnât always the most secure though it certainly is a viable option.
Alternatively, you could look into opensource script obfuscators (Ironbrew, Xen, etc), though they certainly come with their risks and rewards. From my understanding, Xen is more secure though takes significantly longer to obfuscate code, where-as vice versa for the opposite.
I will offer a question: why not just make a white list? I have made many secured source projects in my day, and using a white list as opposed to pure obfuscation has always made it significantly easier on me. Perhaps I am misunderstanding the goal of obfuscation though.
Your best bet is to use a lua obfuscator. You can look around for them on Google.
The goal of your obfuscation should be to slow down anyone trying to steal your work, and once it becomes popular, a leak will not destroy your business. This is exactly how I did it. If you want more advice, feel free to send me a DM. Iâve spent a lot of time researching this subject.
As for what @TerryMichaelBrunk said, I think a white list is exactly what heâs trying to make here, however, the whitelist will probably be a database that updates automatically when someone buys a âlicenseâ. With the way modules work right now, they can only be require()'d when the model has the âAllow Copyingâ setting enabled. Because of this, an attacker could simply take the model and steal the code. This is where the obfuscation comes in.
By âwhitelistâ, I am specifically referring to making the code ONLY work if a name can be found in said database, which, along with the extensively aforementioned obfuscation would make the script practically impenetrable.
Currently from what it looks like (Iâm not much of a roblox scripter), the code calls for a User ID in our databases. If it recognizes there is a User ID there, it will look for a value, STAN or ENT. Iâm assuming once this value is found it will run the code. We just need to hide that code.
As most people are saying, using a whitelist along with obfustication can go a long way. Another thing I might add that I like to do, although it requires more work, is to put any processing things on HTTP. All the inputs go straight off roblox and onto a secure server. Itâs more work and you have to worry about downtime, but if those are not concerns of yours go for it.
