I hereby present to you, the first developer-aimed Roblox Studio Luau Executor. Made for the ground up with the intent of trying to penetrate your own games and execute exploiter written scripts in your game to work towards patching them.
Currently, I’m working towards implementing the Exploiter UNC spec, what they call “Unified Naming Convention”, which makes their scripts code more uniform. The more I support in the UNC, the more scripts it will be able to execute, and the more you will be able to patch.
Currently the core functions for it are in place. You should be able to enter and begin playing around with it for the purpose of testing it on its current pre-release state. It contains a Websockets library, so you can use Exploiter-written extensions, meant to make writing their scripts easier to write, easier for you as well (Remote Execute on Visual Studio Code, for example)
I believe we as Roblox developers, should NOT need to worry so much about exploiting and we should work together towards mitigating the most breaking damages exploiters can do (Such as Data Rollbacks, which allow exploiters to break a games economy entirely if they know how to do it right)
After comments on this thread, and personal consideration, I have decided to open source the module, you can find it on my GitHub under the name “StudioExecutor”.
If you like the idea or would want to support it, star the repo and share it with others who may be having problems with exploiters, or are considering getting something like Krampus/Ro-Exec to pen test their own game for anticheat development or related aspects of it.
The thing is terribly unstable, my vision for it is to not have to restart the game once you are done with your pentesting, else if you mess it up, you would have to completely restart studio just to get to the same point, so my vision is being able to interchangebly change between edit and game
You can, but the key here is that it is meant to run scripts written by exploiters. The normal Roblox environment lacks many functions exploiters use to cheat, things like hookfunction for hooking, and hookmetamethod for hooking metamethods just lack in the actual console tab, which is quite a shame. Also to note that on Local Tests, you cannot use the console tab, which limits the extent it can be used at. The best would be for Roblox to do this themselves, but I haven’t heard any updates on the proposal they did back on RDC.
Here is the project with some code executed in a Local Test, you can see the Lua code I wrote on the right, and on the left the outcome of it, the executor works using a normal lua way of hijacking a state (Hooking a function like pseudo2addr), which gets me a way of executing code in the game, the problem is that most actual executors back them use things like the Task Scheduler to do this I’m doing, but much more stable.
The current most stable way of executing using this tool is by using Local Test and injecting into that process of studio that was started by the Local Test (As Client), without crashing the actual studio, I could release it right now, but it is one update behind, so I’d have to update it.
It also works on a team test, even though I’d not see a reason to use it on one at all, honestly.
Why can’t you just make localscripts ( such as tests of your remote events ) to “pentest”? Or honestly, just read and properly protect your server code. You are risking your account to do in a 3rd party program what you can do in studio as is.
There practically isn’t anything outside of testing your remote events (or client-to-server logic) that you can prevent with anti-exploit anyway.
That doesn’t change the fact that anything that you CAN prevent is in your client-to-server logic, which is what it ultimately comes down to. Sure exploiters have a bunch of fancy functions for example meddling with your local variables. This is only effective if you do not have proper server protection. Furthermore, you can pentest simply by changing the variable to huge values or invalid value types.
Ultimately any explots will:
Be client sided, thus impossible to prevent. You can make it annoying, but any client protections you add are under the full control of cheaters.
Be server sided, and a result of you not adding proper checks.
It really isn’t worth intentionally bypassing protections and risking your account. And I’d highly doubt the vast majority of the people who want to use this will even really find many “vulnerabilities” in their code using this executor.
Not entirely sure on what the extent of Hyperion flagging is when it comes to studio. iirc- the studio client doesn’t have the exact hyperion model as the main game client, but it still retains some of it. it could have nothing in terms of flags, don’t remember exactly
Overall, there hasn’t “really” been any drawback to community members who have modded studio, albeit, most of the time it’s not through an executor that these “mods” are done (such as fflageditor).
The reality is this is sort of a grey zone. If we’re talking strictly terms of service wise, I don’t believe this would be allowed, although I guess it really depends, studio plugins have never really been punished for.
If you are reading and writing memory directly to the application, then I’d be a little skeptical on what ROBLOX’s stance is for that in terms of strictly studio.
Studio from what I know holds no Hyperion, else it would be packed and many Lua functions I have to get and one I have to hook would be inlined, at most the RCC service, but that’s about all I know about how studio is personally
The main reason is not to make your own local scripts, you are also forgetting exploits don’t necessarily run on your same permission level, and there are functions like getconnections, hookfunction, firetouchdetector and many more, do as much pen testing as you can on a local script, but the workflow for it would not be the same, as you cannot “hot reload” it if you will, which is what this tool can do if you will, which makes testing things much quicker
You can make a lot of things from a client, even when server validated, you cannot make the server own the player of someone, because that’s plain ridiculous for performance overall. “Meddling with local variables” has a lot of power if you know how to do things right. This tool as far as I know, this doesn’t put your account at risk of any kind, I’m not affecting anyone’s ability to play Roblox in any way or manner, and you are truly only capable of using it on games you develop/own, since you cannot just get into production Roblox games using this, Roblox studio doesn’t allow you to do that lol. Client protections work just fine when you add the correct ones, the main point is to deter those who aren’t determined enough, that’s why obfuscation is abused on many places, by packing, obfuscating and virtualizing your code, you throw off less-persistent exploiters who would have otherwise wasted their time on your game doing their scripts.
Hyperion also uses packing and obfuscation as well, yet it’s fully client-sided, but it has kept us safe for plenty of time off from dealing with cheaters.
And even then, it’s completely useless if you do something like a save instance, because you are lacking all of the server logic. I don’t see this as a bad idea, it’s just a tool that we can add to our tool belt when dealing with exploiters. If it is bannable, though, I truly don’t know, but I don’t believe it is.
I’m implementing those, but I work on my free time in it, and I have started it a week ago, I figured some crashes earlier two days ago, so right now I’m currently implementing functions, although they may not behave 1:1 like they used to, because this is studio, not client, a behaviour 1:1 to that of old exploits isn’t really possible in my opinion.
The environment has the basics, although they should be enough for quite of what exploiters do.
hookfunction (Only Lua functions due to me not implementing C yet)
clonefunction (Lua only)
getgenv
getrenv
setidentity
getidentity
require (Has to be modified for the purposes of requiring in high permission scripts)
consoleprint/warn
getgc
getrenv
httpget
checkcaller
I will try to implement as much of the spec so scripts run just alright.
