New Require Introspection Feature

Absolutely love this, will help a lot in reducing the spread of malicious assets!

I would, even more, love it if there was a place in the console (serverside) that would list all required modules in a specific game, so a malicious module can’t fill the server logs in an attempt to hide, as well as the order in which they were required and if they were required by another module.

Either way, keep up the great work! Love seeing these sorts of things get added.

14 Likes

This is an amazing feature and I am happy it was implemented! From what I have seen from previous replies, having these in a different printing category would make it so much easier to find the sneaky requires. I’d even love to see it in a different colour to ensure that it cannot be mistaken for a print, warn, or error.

5 Likes

Seems like those annoying require chains are finally going bye bye

7 Likes

Appreciate it. I hope that in the future the next step is allowing us to disable MainModule requires in our experiences entirely. Roblox has made a few updates in order to secure us against backdoors, but I think the most important step that should’ve been done from the start is allowing us to cut off the source to begin with and reject third party requires in our experiences if we wish.

14 Likes

allowing us to disable MainModule requires in our experiences entirely

This to the moon!
It would also be handy to have a whitelist, so games that need them are able to prevent all other module assets from being loaded

8 Likes

If require was used on a client to run a cheat script, would that print in the server side console for the developer to see?

5 Likes

Is there any way to disable this as it may be annoying for some users.

13 Likes

nope, it doesnt.

Cheats are undetectable on the client, the best thing you can do is to have your game secure by design.

6 Likes

They aren’t ‘undetectable’. Client sided anti-cheats and honeypots are a good way to weed out a lot of exploiters, particularly common cheats that are used in lots of games.

This change won’t affect cheats, and they don’t use the require(id) method anyway, generally pulling information and code from external sources

7 Likes

Honestly, this is just annoying. I don’t see where you get the idea that people actually still hide viruses in requires, in my five years on Roblox I’ve only ever seen this happen a couple of times.
This almost seems like fearmongering at this point.

6 Likes

Here’s what I gathered from feedback:

  1. Make an option to disable this or print it elsewhere / a new category so it’s easier to hide / ignore.
    – That’s a great idea. It’s owned by another team, but I’ll bring it up with them for consideration.

  2. Make a mechanism to disallow some / all requires in a per place or universe mechanism.
    – This is on our agenda, but introspection and other features come first.

  3. Provide more information about the asset than just the id (name, creator).
    – We wanted to do this, but chose not to do this now for performance reasons because the network requests needed could delay place startup.

Thanks!

42 Likes

Maybe either add a special service to get all of the previous logs? Like how there’s logservice for hooking onto developer console. Or, you guys could add a specific function to logservice that only returns the require logs? (Or maybe even an event, just like the way you can hook onto dev console)
If a game is backdoored, they can always just print fake require logs, which could be annoying.

Another thing is, people can easily just spam something such as require(1), and the log would still be sent. Maybe make the log only get sent out if the module is actually valid?

Other than those two issues, this feature is very useful.

5 Likes

There should be an option for users to disable this feature just for plugins (or all plugin errors in general)

11 Likes

I’m quite curious what are you going to do with requires that are ran only if IsStudio() is false (which is the case for the most backdoors)? Seeing a module being required from a call located in eg. “workspace.Part.Script:2” in the in-game console can’t be helpful if the map’s big.

10 Likes

That a good point, there will just be no print. But i think there will be a solution for that later. As @Mr_Purrsalot say, you will maybe see a possible solution for this type of problem with this planned feature.

3 Likes

I see the benefits of this but I don’t want the log appearing every time I play on my studio.

It gets pretty distracting when debugging and testing codes, and this message gets in the way.

There should be a setting to disable this feature or a filter.

5 Likes

99% of backdoors gonna say adios when these drop

6 Likes

THANK YOU! I really dont like it when it prints all that stuff in the output from a plugin I have. thank you

4 Likes

They are undetectable if the exploit developer scripted it right.

This is a big misconception and is no true. In fact this is one of the reasons why there is so much exploiting, developers believe that security through obscurity can secure their games, this leads to them getting a false sense of security which prevents them from fixing the actual issue which is their game not being secure by design.

If your game is secure by design, all exploits would be patched. Expect legit aimbot and legit autofarm.

5 Likes

We really should have more control over this. In its current form it is annyoing. We should have seperate controls for plugins.

Also we should have a way to disable require IDs all torgether.

7 Likes