that’s so true
but this doesn’t prevent that. it makes it harder for someone who knows what theyre doing to see it
and people who know what they’re doing, if warned, will know not to allow it
the people that don’t know what they’re doing will have a malicious script inserted plain as could be and be none the wiser. it’s not prevention.
require(id) should have a ‘permission system’ instead of outright blocking it. The new ‘permission system’ also encapsulates other studio features like InsertService, HttpService (whitelisting domains), requiring external modules, etc.
More on ForeverHD’s post: Creator Marketplace: Improving Model Safety - #28 by ForeverHD
If packages are meant to replace the above, won’t it just have the same issues…? Lol.
The ‘whitelisted’ assets on toolbox that are allowed to use require(id) makes those developers targets for bad actors. Not all of them are super tech savvy and exploits can occur at any time for different applications and the such.
Obfuscated code should be allowed for privately owned frameworks/system and to avoid other issues regarding a replacement method with HttpService and leaks of the source code for all to see.
RIP getfenv and setfenv, if you have replacement functions, reply with them (<3 the function overhead), my opinion is that it should be kept.
I’m agreeing with @ForeverHD that require should not be blocked and instead you should have a permissions system instead (see bottom of page).
Outright blocking it and having this ‘whitelist’ for only certain assets is still not solving the problem and is incredibly unfair for those needing auto-update features for their modules, or in need of the redirect from a ‘loader script’ like how these ‘whitelisted’ admin command modules and similar work as well.
Understandably, the requiring a module, in a module, in a module, in a module, and so on creates a chain of possibilities for virus injection, however, the user would be at fault for depending on modules that have this problem in the first place and should use alternatives. Those developers should not be doing that either, they should have those specific modules they need in the MainModule.
There are good purposes for require(id) in public modules and its being blind-sided behind the bad actors.
Also packages replacing this would do nothing, its literally the same thing but is in Instance form instead of numerically passed in to a require function (virus code can be injected into the package and if auto-update is enabled then it’ll be distributed out in the blink of an eye to all active servers as well if the option is enabled.
For the statement autoupdate shouldn't be a thing because internal changes *can* break my code; you wouldn’t even be using these modules with require if you didn’t know what they were doing in the first place. For things like DataStore wrappers, gun frameworks and vehicle frameworks, you’d need to understand their interface, the ‘api’, as well as some understanding of how they work internally to use them. If there was an update to it, you’d know, I’ve seen a mixture of alerts for updates as well; some just run new and improved code, others alert the user that a new version is available to download.
For these ‘whitelisted popular assets’, its even worse for those developers. People would assume these popular modules are safe, which makes them incredibly high valued targets for bad actors, especially after this has taken effect right now.
All it takes is accidently running malicious code on your machine, in browser via extensions for example, or via application in a phishing attack, and you unknowingly caused all those games to have a live backdoor after an update was done without you knowing.
To remind you developers on the whitelist, you have a much, much bigger target on your back.
I believe that obfuscated code should still be allowed on the marketplace.
As noted by some, blocking the use of obfuscated code completely removes privately-owned purchasable systems altogether, airplane systems, weapon frameworks, etc. The authors don’t want the code to be public because its theirs and they have put their time to develop something they can distribute and make profits or funds from.
Understandably, obfuscated code was disallowed because bad actors obfuscate their code and moderation has to try deal with finding out whether this code is malicious or not when reports are made on said assets, or if static analysis determines its malicious.
I believe Roblox took the easiest way out of this by outright blocking it and lightened the load on moderation, but the cost was communities that funded themselves through having obfuscated frameworks and systems that use this approach because the lack of tools to do this with a different method.
Some say using HttpService to replace the removal of obfuscated is the solution. It is not
You can statically analyze obfuscated code, but you cannot ‘statically’ analyze ‘dynamic’ code, which is massive for finding ‘viruses’.
Also, ‘virus’ scripts will just do the same thing as your new and improved systems would; use HttpService requests to download code, loadstring it in a custom environment or using a publicly available module, and they would be undetectable unlike the required modules which output what ids were required. Any attempts at detection systems will give false positives because the two systems are so similar. For your new system to work, you need to have HttpService enabled, for these viruses to work you need to have HttpService enabled. Tadah, perfect environment.
No, you cannot analyze the network traffic in real-time across the roblox servers either.
Four simple examples;
And again, you can have a permissions system to allow certain domains! Why not just implement this for require so the http issue can just be avoided altogether and kept turned off.
Not my babies 
+1k lines to sandboxes (real)
Alternatives will be needed for this, if you have procured any, reply to this message so others can see for those that need it!
This is the solution for require(id) and many other problems.
There is no solution for obfuscated code. You either:
Also the removal of require(id) affects privately owned frameworks and systems as well.
R.I.P getfenv and setfenv, reply with replacement functions with tons of overhead, thanks!
This should not be the answer to potentially malicious or unwanted assets. I’d like to see more responsibility put in the developer to manage their own experience rather than restricting everyone from using features. There has to be another way to tackle this.
Read the update and for those wondering; assets that use ‘obfuscated code’ or require(id) no longer appear in search, which is considerably better!
I agree with you pretty stupid update bans getfenv/setfenv in mainmodule
(i managed to bypass this somehow and still upload module with getfenv/setfenv that uses it for legitmate purposes maybe they reverted this update and they only banned obfuscation after all???)
anyway
Now that explains why i got banned for “cheating/exploiting” while executing random server destroyers from youtube (via require id) and it all happend in my private test place and i think its stupid because its literally private no one else can join that private test place and the serverside executor is pretty much only for me
Why getfenv and setfenv? Developers already have secure measures against backdoors, like checking the scripts in free models and plugins and not putting things in vulnerable places, so if they can see that a script is doing setfenv(_G.func, backdoor()) and they look up how setfenv works, they might suspect something fishy going on.
What about anti-exploiting measures? Is doing getfenv(2).script == nil in an open-source ModuleScript to detect some skid doing require(module)() now ‘malicous’?
Can we manage our settings in Roblox Studio with at least a pop-up saying “WARNING: Models and Scripts with (g/setfenv, require, obfuscation) may have harmful/malicous intent. Proceed with caution and report any library items that breaks Roblox’s Terms of Use.”?
What is the threshold for obfuscation? Is a badly written script with funky variable names enough? Is MoonSec3/Luraph the threshold?
Why is there a whitelist? “Hes popular, hes good. But that unpopular, inexperienced, non-profitable scripter over there? Ban him for a day because he mentioned getfenv for use in global variables”
not really you have to Publish to Roblox (aka “update your experience”) every each time the framework updates
with require(id) you didn’t have to re-publish your experience and it updated immediately in new servers
(sorry for double reply)
they fixed that and now your model gets banned instead of your entire roblox account
new issue: the appeal is reviewed by AI so it gets always rejected regardless of whatever you say
Roblox really needs to develop a policy review of “if flagged by bot, hold for human verification” instead of an outright ban. Where’s that moderation improvement they keep yapping about at RDC?
Here is the catch
You can still update your “banned module” and you can get it unbanned instantly upon update (this is still better than entire account ban so they did actually improve it) if you removed the following functions from your script:
When I took it to Roblox support, it seems that the humans who email you are actually just bots too, they thought my model was correctly disabled even though I explained to them that it isn’t malicious at all.
Did you ensure that there’s none of the blacklisted functions in your script and that there’s no obfuscated code?
