Hi. I’m kinda curious about this. One of my close friends asked me if its against the roblox TOS to test games security. Like white hat hackers do. I really don’t know what to tell him… So yeah i thought i can ask here??
Any response or something like that is higly appreciated!
It’s not allowed. This question has been answered before:
https://devforum.roblox.com/t/is-it-okay-if-i-use-exploits-in-my-own-game/197313
Please search before making a thread in the future.
Ok i will search more next time!
You can legitimately test the security of your game using the studio command bar or creating a modified client script for testing purposes or creating a loadstring console. Other than that, please do not attempt to use external programs to modify the roblox client.
Ok i will tell him that. Tahnks!
This often isn’t the case.
Exploits not only have higher level execution, but also have custom functions such as getnilinstances(), getrawmetatable() and setrawmetatable() - just to name a few (they change depending on the exploit). You can’t use studio to test your game for vulnerabilities that would require that higher level execution (level 6) or use those custom functions.
I am thinking about creating some sort of sandbox that allows you to create these functions so that you can test these scripts, but we’ll see.
You don’t need a higher security context level to test these kinds of vulnerabilities yourself. You can make a repro that uses all developer-accessible identities just fine. The point you want to hammer down first and foremost is if the client is able to do anything that replicates to the server and harms player experience.
It’s probably a bad idea to use exploit scripts. Because of their very high permission levels, scripts you run can do malicious things to your Roblox account. (ex. Make you purchase catalog items without even getting a prompt.)
Having a basic command bar is enough to attack your own game with.
I have never in my time on Roblox seen this. Please can you give an example?
My point still stands about exploits which require the custom functions. It is not currently possible to do this on Roblox without an exploit client unless you make some sort of sandbox and recreate these functions in that.
See this function:
I know that the function for making a purchase exists. My point is that;
Script executors have very high permission levels in their scripts (or so I’ve read), so they have access to anything CoreScripts have access to. It’s safer to avoid using random exploits.
“Very high permission levels” doesn’t mean that they start making you buy stuff randomly. Obviously you shouldn’t go using/buying random exploits. My point is that it is very difficult to diagnose and patch these more complex exploit scripts that have access to a much larger set of functions and abilities that Roblox will never give us access too for obvious security reasons.
Custom functions just facilitate various functionality out-of-the-box. What kind of functionality do you need that isn’t provided by just running some code in the command bar or making assumptions when performing a test?
I find it very unrealistic that you would ever need to exploit your own game or have access to the same functions an exploiter does to test security when you have a perfectly good tool to use. You can very easily diagnose without the use of outlawed programs.
If you are trying to effectively security audit a ROBLOX game, you don’t really need extended functionality. You really just need the ability to read LocalScripts and fire events. If you want to do an even better audit, have your friend share the game with you and see what the server is doing (that is if he trusts you with game source). Doing an actual code review is going to be infinitely more effective than playing around in the dark.
@colbert2677 I agree that Studio should give people the tools to cheat-test their own game, but OP is right. Exploits tend to have functionality that can’t be re-created normally.
A quick example off the top of my head is the ability to play with locked metatables. The most common use is to change the __index metamethod of Instances (and __namecall now too) to return custom hook functions in place of Roblox methods. This lets hackers spy on arguments and change return values for calls made by other client scripts.
I’ve personally fixed vulns where the only way to exploit them was to change the return value for InvokeServer using this kind of hooking, something completely non-testable with the command bar or a normal vanilla script.
That’s just an example but there are many others. The custom functions implemented into exploits tend to be C functions that can’t be re-created by Roblox Lua devs, which is why cheat makers go through the trouble of including them.
I don’t find this to be a realistic enough reason to justify why outlawed behaviour should be allowed. As I mentioned earlier: you can test security very easily by running code in the command bar, making assumptions or designing tests around potential vulnerabilities you may encounter.
You will never need to access a locked metatable when it comes to designing against exploits, especially not if you’re focused on server-side security. If you’re able to make it so that the client isn’t able to leverage your systems and damage gameplay for other users, that’s good enough. Anything else is overboard and not required. There are games that design security well without relying on questionable practices.
Designing tests with exploits in mind is not too difficult. In regards to your custom hook functions and remote spying, you as the developer naturally know what kind of arguments are going to be passed between remotes. You use this mentality to design a test that uses “spoofed values” and sends them over to the server. Nearly the same as what an exploiter does, just without going out-of-the-box.
I’m not sure what kind of vulnerabilities you’ve encountered wherein the return value from InvokeServer needed to be changed, but that’s relatively extraneous. A return value from InvokeServer is only going to be used on the client. I don’t see any real reason to account for this case. If you are relying on the return value of InvokeServer, you’re almost certainly experiencing a case of bad design.
In addition to the above, if you do experience a vulnerability enough to supposedly need to simulate changing the return from InvokeServer, again, you can make assumptions. Retweak the server-side to include a debug mode and make it return values that you’d expect an exploiter to change them to.
Wrt the above two things, I’d like to hear of a situation where the return value would be required: as far as I’m concerned - I’m not - exploiters are free to change that return value and ruin their own game.
I agree that a proper dev workflow doesn’t need special permissions or capabilities to make your stuff secure. For example you explained that writing with a good client/server model in mind will automatically remove most vulnerabilities, including the ones I mentioned, which is true.
But there would be some advantages to being able to replicate the environment of an exploit. For example what if you want somebody with no knowledge of your codebase to try pentesting your game? Would you give them a command bar? You could, but they wouldn’t be able to modify your scripts to make certain assumptions, or do fancy unit tests with your code without actually viewing and editing it. Sometimes even with solid security practices things can pass by you, and that’s natural, so having your game poked by somebody who has a fresh perspective currently has to be done by waiting for an actual exploiter to cheat. And then you have to worry about setting up logging so you can understand what they did and how they did it.
This could be improved if Studio simply offered more functionality, or if authorizing somebody to use cheats on your own game wasn’t against the rules.
I could get into the ethics, but I’m not into that. I’m really just answering your original question on behalf of the OP, which is “what kind of functionality do you need that isn’t provided by just running some code in the command bar or making assumptions when performing a test?” And the answer is: either more flexibility with the scripting API, or special rules for creating your own security policy for your games. There are alternatives but they aren’t the same as the real deal. That is all. 