As a Roblox developer, it is currently too hard to obfuscate our local scripts. Would it be possible to make an option to remove debug data from the bytecode of local scripts? Maybe with the exception of line numbers.
29 Likes
You can already use things like stravant’s beautifier/minifier to achieve things like these; removing debug data doesn’t mean it can’t be recreated.
5 Likes
It would be nice if local scripts were replicated to clients as some form of minified Lua byte-code outside of testing. You can still recreate the script but it increases the difficult tremendously.
2 Likes
Right now we only send encrypted bytecode to the client. The client is not even capable of compiling Lua code, it can only execute already-compiled bytecode. The problem is that Lua bytecode maps almost 1:1 to the original source code form, including line numbers, the names of local variables, and other stuff. You lose quirky indentation and comments and maybe do blocks as well, but you retain almost everything else. The reason for this almost 1:1 mapping is because it’s used to generate stack traces from errors.
If we were to add automatic obfuscation we’d have to add a complex system to de-obfuscate client-sided stack traces, otherwise stack traces from the developer console would be useless. We’d also have to add new APIs to ScriptContext where a client script error fires an event on the server instead of on the client. This would have to be on the server because otherwise we’d be leaking the debug information to the client anyway, defeating the point of removing it from the bytecode itself.
22 Likes
I am OK with stack traces being useless. This is actually exactly what I want.
But yeah if you could create a way to send back some data that lets the server reconstruct the error, that would be pretty 10/10, high quality, better than the standard. Really something to be proud of.
11 Likes
Honestly it shouldn’t be a big deal if the client can see client code. Any website works the same way. Anyone can see the client code. Sure, it might be obfuscated, but can easily be converted into readable code. (And usually this obfuscation is more-so minification for the sake of smaller download sizes.)
Put sensitive code server-side
5 Likes
You’re technically right. But then, why not just give out the roblox source code and make it easy to hack the client?
2 Likes
Serves a bad analogy; the Roblox client attempts to prevent naughty execution, but that’s to attempt to prevent the only worry you should have – local exploits (such as flight or speed). A well built client->server model should minimize or nullify any usage of these client scripts and their code should they be hijacked or recreated to change something with help of the server. Otherwise, you’re really going the security through obscurity route.
3 Likes
This isn’t a rational analogy. There’s a difference between the raw C++ source code and the instructions that the CPU is interpreting in the compiled program, much the same as there is a difference between the client receiving the actual raw Lua code and it receiving bytecode instructions based on the code. Encrypting it would make it not only difficult for you to debug, but also for Roblox engineers to debug crashes that may be caused by something in your code. Even if they did encrypt it completely, it wouldn’t prevent hackers from reverse engineering it into something they could work with.
3 Likes
OK.
this is a complete sentence
We’ve talked about this in the past, this seems reasonable as a option for developer to enable. We’d remove all local names and line info from the scripts; the stacktrace would probably still contain the script names and occasionally function names for global functions but of course it would be harder to debug the result. To debug, you’d need to re-enable this temporarily.
Note that this would still allow for Lua decompilation, it just would be somewhat less useful without the local names.
We’d probably need to do a poll to figure out how useful people think it would be. We could also theoretically send scripts as is to clients that are from the group that owns the game, so that the major usability impact is for error reports from other players, not from your own testing.
45 Likes
Please look into this for the 2019 Roadmap.
15 Likes
Yes please 
3 Likes