Yes, however these are the main models that use require() and are already confirmed to be safe.
No code will “conflict” with these changes, they only affect the marketplace, not the actual content in experiences / models.
3 Likes
I can confirm that 2018 Adonis barely functions and does not hold the quality standards we have today.
This is Roblox. We need solutions to be as idiot proof as possible for the consumer. HD Admin is a standard in “free admin” games because it’s just what’s done. I can’t wait for Nanoblox to deprecate that cursed system.
On the contrary, if an auto updating package gets malware in it, and the development is inactive, the game is now infected.
Again, security fixes take precedence over the possibility of the asset becoming infected. We’ve had dozens of patches yet not one hijacking. How would a user know if when they manually update the package is not infected? People had to install the node-ipc package update manually. Your point has some sense but is ultimately flawed in the market and context of Roblox where people don’t do things they should do. HD, Kohls, SimpleAdmin and Adonis still get people commenting on the damn thing claiming it’s malware, they should probably have checked!
2 Likes
I should probably clarify, when I said conflict, I did not mean it would break existing code, I just meant models containing this code would clash with these new marketplace rules.
1 Like
I haven’t looked through all the posts, so I am just going to state my thoughts about require(id): I benefit from this with my less popular Nexus Admin and with my much more important Nexus VR Character Model. Being able to push out major updates to fix major issues has been super important, which is why I use it. It isn’t something I and a lot of others wouldn’t want to give up. The downsides that others have stated are severe though: loading in malicious code directly through an update. See SolarWind’s supply chain attack in 2020.
I saw mentions of free model versioning, and I would love to see this. The problem for me is it would prevent me from pushing out major fixes to people who don’t know to care about updating models. Migrating from Nexus VR Character Model V1 to V2 was hell for me and required dozens of hours of just messaging people to update. I can see the models I have listed above still appear in the marketplace search when the… shouldn’t(?), which is good for now. The point where this will cost me a lot of time in replying to messages is when the MainModule or old versions being the only thing that comes up when searching becomes the normal reality with this update.
5 Likes
Reusable Packages will become the go-to solution for this if they can just slightly enhance Access Permissions. I’ve written up a feature request for this including more details here:
7 Likes
That’ll be Roblox in moderation I need to go in I have to be administration
Turn on Roblox that are used I want you to accept me from in the group Official of group Roblox
How about just making a option to whitelist certain require Id’s you trust, shouldn’t be that hard right?
1 Like
I have to do official of Group Roblox
But I think they will accept you from application
that property is currently bricked and doesn’t work for anything but Lua assets made by the game owner or Roblox
Correct me if I am misunderstanding something here.
Instead of creating tools within Studio providing granular permissions to control third party code (this has already been done with HttpService), the Creator marketplace is now censoring these assets?
I get it’s somewhat of a difficult situation to allow legitimate developers who don’t abuse these features along with the shear amount of malicious users, but these limitations make the Creator Marketplace almost pointless for legitimate closed source products. As it currently stands, it would be better to distribute such products outside the Creator Marketplace, such as a website or Discord …
2 Likes
I have to come back to this and bump it since I’ve just updated a plugin now that I’m in the Plugin Marketplace program, and I can’t see it in Studio or on create.roblox.com.
Does removing any references of require() stop your plugin from showing up still? I checked with a virus scanner that scans anything that has require code and I confirmed I removed the require() yet it still does not show up:
@tubin_tubs it would be incredibly appreciated if I could get a reason for this behaviour by search or get it fixed.
2 Likes
Or even better make it so you can select a certain id in the model page that can use it to import into games, It will prevent other people from calling it / using it ingame meaning it will be locked to one person or more depending on whoevers id is there!
I just was pointed to this recently due to issues regarding my model too and its general use. If Roblox’s goal is to help its developers then similar to the individual far above who mentioned he spends hours per day making models for the marketplace, his work is all in vain.
Though I’m certain Roblox has its reasons for the update namely in choosing average inexperienced developer experience over powerful tools that allow models to do something as important as auto-update, I do think that it’s taking away an important feature from developers and like me, half of them probably don’t even know this is happening to their models.
I just happened to realize about half a year later that my model is not displayed on the marketplace when I put a ton of time (about half a year lol) into developing models for general use. I’ve made many incredibly useful updates to the model and it utilizes an auto-updating style system that I planned to have used at a more general level until I realized this was a thing.
Having an individual staff team to whitelist certain models may seem like a waste but if you make it possible yet difficult, the people that are actually trying to get their models used in the marketplace will be the ones that get through.
There are various other methods that people here discussed as well such as warning about required scripts and having people trust the author. Plugins are far more dangerous than half of the free models thrown around to inexperienced developers but are filtered much more loosely.
Few to no developer believes this to be a good way of solving the issue because it doesn’t just end the “virus issue” (which is it does not solve… the people who fell for these fall for ANY type of ‘virus’ related script it takes one line to insert even worse ‘viruses’ but you took away something seriously important for developers like me and those above.
It’s discouraging in the fact that this update not only doesn’t stop any issue but it in fact can make things worse. Since my model will not be displayed in the marketplace but if people are aware my model is FREE to use, if they search it up on the marketplace they will see FAKE versions of my model and MINE will not even exist in the marketplace - making it even EASIER for people to get fooled.
Not to mention if I delve into the marketplace now there’s still equally ridiculous “virus’” flying around that have the exact same impact as require does. This update has ONLY harmed real developers while not even improving the inexperienced developer’s understanding of marketplace use with free models.
thanks for coming to my slightly salt infused ted talk
just 6 months thats all
1 Like
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.
1 Like
TLDR (too long didnt read)
-
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.
require(id) should be allowed
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.
Obfuscated Code
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.
Regarding the privately owned frameworks / systems and the ‘HttpService’ 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;
- you cannot hook onto the GET requests yourself, it can be done in the backend of studio but looking at the options below will circumvent them.
- code in http requests can be obfuscated, encrypted, encoded or a different format entirely (VMs), making it unreadable in packet analysis.
- analyzing completed request content will still not bare fruit as it may be obfuscated, encrypted, encoded, or a entirely different format (VMs) making it unusable in static analysis.
- the overhead and problems to analyze all the http requests in the first place would just be a nightmare to even consider as an option.
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.
getfenv and setfenv
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!
Solutions
This is the solution for require(id) and many other problems.
There is no solution for obfuscated code. You either:
- remove all obfuscated code, consequently removing any chance of privately-owned paid systems and frameworks to exist or grow, or
- You have obfuscated code where obfuscated viruses exist (small population) but you have communities that have privately owned paid frameworks and systems allowing developers to grow.
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!
6 Likes
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.
3 Likes
Read the update and for those wondering; assets that use ‘obfuscated code’ or require(id) no longer appear in search, which is considerably better!
3 Likes
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
2 Likes
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”
2 Likes