You could have the same system you do now, but the server keep an eye on what the client is doing and respond if too many inaccuracies occur, e.g. the player going from one side of the map to the other in .02 seconds.
[ i mean that’s what basically all anti exploits do, but ]
What exactly would this do that isn’t already present in Roblox’s anti-exploit measures?
With the new VM I believe decompilers will become very hard for exploiters to use. Since Roblox isn’t storing debug information (e.g. local names, upvalue names, etc) anymore decompiled scripts will contain no useful information outside of string constants. This makes it much harder for exploiters to reverse engineer developer’s scripts and is essentially what a lot of obfuscation tools will do.
Reading this thread again I see a lot of new misinformation. Some things I’d like to point out:
I think a solution is just to create local script that checks if something is wrong with the client, then kick them if something is off. I don’t know if this works or not, but plz correct if i’m saying nonsense.
No, the exploiter can simply remove the script as if nothing have happened.
Suggesting a server-side ping check on client, if client fails to respond in time, something is off. Probably bypassable too if the exploiter manages to find the remote and fire it in time.
I have a good idea! Maybe we can just add 1 local script that handles all the client sided stuff and anti-exploit, and if the client tries to destroy it, they wouldn’t be able to play the game. Or maybe this is just a bad idea, because the client could steal/edit the code in local scripts? I’m probably just saying nonsense idk.
This is a bad idea. They are capable of stealing the script and then editing it. After edit, they replace the previous script.
I think the new Lua VM is a new filter for exploiting currently, especially decompiling.
Exploiters can hook any function and make it do nothing. Kicking/Banning/Logging the client from the client can be easily overridden by an exploiter.
The new VM does currently break decompiling scripts (it is unsure for how long this will be for) but I don’t think exploiters can replace the script. They can use the source to find out certain functions to prevent from being called but I’ve never heard of exploiters editing the source of a script in-game.
The only thing we can do now is probably just heavily obfuscate code so only users with past scripting knowledge can figure out how to delete the parts of the code that kick/ban/punish the exploiter I think.
Obfuscating only slows down, it does not prevent the exploiter from decoding it. Once they’re done decoding, they pretty much can butcher the code somehow.
Also increases difficulty of debugging.
Some obfuscators such as ironbrew are extremely secure while keeping performance in mind so using it is probably the best choice for developers. As for debugging, most places that use obfuscation now debug the code unobfuscated and before publishing, save a copy of the raw source and release the obfuscated source. Also, some obfuscators keep debug information so when you error you will be able to see what is wrong.
Something like that is good if you aren’t too experienced with Lua and are planning on making your own, i know most people on here recommend strictly server-sided anti-exploits as those are truly the best and most securt but the local ones honestly do help for the pesky skids that join games just to mess around, particularly small community driven games like cafes, just don’t trust them to always work. In the end its your choice what you use, you’ll benefit either way.
They can edit upvalues and locals for the scripts ( using debug library, or getreg() ), or, they could also just delete the script entirely and recreate what the script does ( based on it’s original source which they would obtain using a decompiler ) , allowing them to change the scripts behaviour.
But, like you said, the new VM stopped decompiling for now.
And, it will make this process a bit harder since variable names will no longer be sent to the client, instead they’ll get variable names generated by the compiler (I’m not too sure about this).
No exploit can access the server. Period. No server scripts, no server storage, no server script service. Backdoors are placed by the creator/someone who got direct access to the game.
You can see this yourself. Use Accurate Play Solo, go to Client mode and try to get something from the server- you can’t.
Or look at a game leaked with something like SaveInstance, if that’s still a thing, you’ll notice that things like universe-specific assets (e.g. images/meshes) and most scripts aren’t compiled, and if they are, it’s not in a very human-readable format (especially with the new VM)
Thats probably how his game got leaked.
Thanks for writing this! I think this may give some people a better understanding of all the exploits out there is they didn’t know about them yet, and this is well written.
I think we shouldn’t underestimate the capabilities of exploit developers. Take a look at games using Denuvo, for instance. It’s said to be a state-of-the-art DRM system, yet certain games may be cracked on the same day they are released. Now consider that warez groups are motivated solely by reputation, while exploit developers may often gain a lot of money from their affairs. It is true that Roblox is small compared to the entire warez scene, but the available obfuscation measures are also less sophisticated, due to limitations posed by Lua as well as the Roblox market volume.
Thus, I have come to think of the client as a black box that is completely out of my control. It won’t obey the server’s demands to create scripts or delete scripts. It can look at a script and pick out the behaviour necessary for keeping the server happy (periodical ping, realphysicsfps reports at 60), while not actually enforcing any integrity checks. And it magically understands the meaning of every piece of information that the server gives to it, no matter how misleadingly or non-descriptively named. I firmly believe this is the only sustainable way to think about security and anti-cheats. The new Luau VM has brought with it numerous improvements to performance, functionality, and ease of use, but we shouldn’t be lulled into a false sense of security. It doesn’t bring any.
The problem that Roblox has currently is that because of FilteringEnabled now being mandatory for games, the olden days of free exploits now no longer exist, but instead have been replaced with Free FE bypassing exploits, such as the ones you can get from large online personalities (not going to name anyone) that just spread them like wildfire.
Another issue, is that the attitude towards exploiters is getting worse, meaning that exploiters who are doing security research for the HackerOne program usually get abused and sometimes even banned from games they are testing in, before being able to explain that their motives are indeed good.
Another issue, is that despite the HackerOne program being an official program, it is hardly recognisable to the general population, as there is not enough publicity to it, meaning that members of the program are ridiculed for being “wannabe” hackers, when in fact they are trying to stop those exact people.