I’m pointing it out because, for at least one person, it was not clear that this is not a gray area. Whether Roblox enforces the TOS on this issue, I do not know, nor am I in a position to make a decision on it one way or another. However, I can, as I have before, let the community know that there are no plans to protect Studio with Hyperion at the moment.
4 Likes
Why hasn’t someone made a Offline Studio patch coded in C++? If people are willingly to go trough the effort to make Studio Executors, can someone make a offline patch (that as in, allow me to open .rbxl files even without internet?) I hate i must connect to the internet if i need to work on a local project
2 Likes
That is a project idea you can do on your own I suppose.
Yeah, time to learn C++ which by at that point i might just make my own engine
A byte patch cannot be compared with a whole game engine by any means.
1 Like
Forget it, another developer looking at this forum has sent me it GitHub - Roblox-Devs/studio-offline: Using ROBLOX Studio without Internet Connection although its AOBs are old from what he has said
3 Likes
Thanks! Just needed the clarification, can I just ask - before that happens we have some form of warning?
In the extent, that we are going to use these sorts of tools to pentest our game’s security.
1 Like
I certainly will let the community know if Roblox changes its stance on not protecting Studio with Hyperion.
4 Likes
Really cool! Play tested with it and was able to make an anticheat dedicated to detecting a script that is really prevalent in a popular game.
Are there any plans to make an official studio executor? You guys promised us that I think
I highly doubt it. Exploits have their own massive set of additional features and it would only be a matter of time before obfuscators figure out how to block Studio execution.
Plus, it’s just not needed. If you see an exploiter constantly changing car color, you know they’re abusing a customization remote. If exploiters kill all players instantly, it’s definitely a flaw with a melee/gun system.
1 Like
It’s a different feeling when your trying to hack your own game with simple spy 
I have a slight feeling that the product team prioritizes needs over “discover how fun it is to exploit”
just a feeling
2 Likes
exploits bring alot of functions to the table which simply isn’t possible to replicate from a normal localscript, such as being able to intercept,block and modify calls to remote events, spoofing values and much more, the goal of RbxStu is to create a way for developers to be able to test these functions against their games in a safe environment
I can definitely see value in this as open-source hobby project, more tools to combat exploiters is always better. My reply was targeted at the question if a Roblox Studio “executor” would be realistic to expect, which is obviously no.
from roblox themselves likely not as if something were to go wrong such as the executor being vulnerable to an ACE it’d fall back on them.
Yeah, that’s one of the major concerns I have with RbxStu, and why I have not tried completing the FileSystem library, I refuse to make vulnerable code, and things like the FS library are REALLY notable for being exploited by malicious actors to do things, which is why I have not done it yet, and if I do, I’ll have to put it behind an “Unsafe” mode of some kind, just to prevent issues from the get go for developers who run generic scripts/not trusted cheat scripts for their game.
Yeah it does. Remote Spies are not supported officially, and if you want to make one, you will have to use different methods, as the current methods that things like SimpleSpyV3 or Hydroxide use do not work on Studio (And I will NOT research why at all).
One of the things I added with the purpose of patching is what I called an Instrumented Environment, it basically traces all C function calls, and prints out the arguments of __namecall and __index on elevated lua states (threads running over Level 4 I believe, I don’t remember how I implemented checkcaller at this point…). You can use the Instrumented Environment calling enable_environment_instrumentation using Lua.
And its a 50/50 team if you will, Shadow had the original idea, he wrote an implementation for it using a Lua C wrapper, but it fell short on some aspects (Too unstable), so I wrote another version using an RVM, we treated development as a competition with Shadow over who could make the best thing, we ended up in somewhat of a neutral stance in that, I think he is restarting his personal version but don’t take my word for that, but it is completely different from RbxStu I can assure you.
Shadows’ participation on RbxStu is that he is the first contributor of the project other than me, other people that I could mention would be Hisoka, he wrote a full dumper for me to use to update RbxStu, but I don’t use it (Mainly because its a vcproj, and not CMake), he is also a contributor to the project as well, as he gave me some offsets when I was in a hurry, which if you want to for some reason try, is this little beauty → nhisoka/RbxStuDumper: A Dumper made for roblox studio (github.com)
Although little people have contributed, and 90% of them (By not saying all of them) have a background on anti-cheat lua solutions or cheat development in general, I’m quite happy with how it has turned out 
, I have also been made aware of detections for hookfunction, but quite honestly, this is not about making an anticheat that is able to detect an executor that is present, its more about running exploiter written scripts to patch them on your own game, so patching detections, unless they have an impact, such as the broken newcclosure handler I don’t find necessary, but if I do find it mid development, I’ll probably fix it, I don’t like half baked things.
If remote spies are your goal, wouldn’t a plugin suited for that purpose be more reliable?
Non-tested example:
I have used that plugin and it does not work