Does loadstring() being enabled matter?

[ultrareaper87 (Atomic)]

Does loadstring() being enabled even matter?

Like you can have it disabled, but can’t exploiters just enable the setting?
Or does Roblox make it so you cannot enable loadstring() in Roblox and only studio?
And even if it is enabled, does it matter that much?

Lots of questions I hope to get answers to.

[Abcreator]

@ultrareaper87

Like you can have it disabled, but can’t exploiters just enable the setting?

loadstring can only be run on the server so even if an exploiter were to change it to be enabled on their end, the server wouldn’t respect that change (because of FilteringEnabled) and loadstring would continue to fail when called.

@ultrareaper87

Or does Roblox make it so you cannot enable loadstring() in Roblox and only studio?

Sort of, it is set to non-scriptable so no scripts can modify the property; afaik there’s no difference between the property in-Studio vs at-runtime though. Just that the explorer has elevated permissions to enable / disable it; not even plugins or the command-bar can change the property value.

@ultrareaper87

And even if it is enabled, does it matter that much?

This post is a good read for this:

PSA: Enabling LoadStringEnabled doesn't instantly jeopardise your games

Often within the Scripting Support categories, I’ve taken notice to a lot of responses informing you that you need to disable LoadStringEnabled otherwise your game is up for exploiter attacks or some kind of other nonsense. The Game Security article to which is mentioned in the LoadStringEnabled warning doesn’t do much of a good job explaining the potential risks of it either. Due to all these responses, misconceptions and lack of information, I’d like to respond semi-decisively to the debacle …

An extra thing to add is that there are multiple other ways to run lua code without using loadstring, so disabling it isn’t a 100% backdoor safety net either. Albeit, if you don’t need the functionality; it is best not to enable it just for the extra line of defence.

[deleteables (dele)]

@ultrareaper87

even if it is enabled, does it matter that much?

It grants arbitrary code execution. In an already compromised game, the only input it can receive for new code to execute is user input from a client (common for a serverside executor) or an HTTP request (disabled by default, also locked down as much as LoadstringEnabled is). Any code that was inserted at the moment of publishing the game will still be able to run, and loadstring lends that code an ability to run additional code, perhaps specialized for some purpose on a specific server or for patches to an exploit). The “arbitrary” distinction of new code is separate from existing code, even if the existing code was wrongly published.

Malicious code that needs what loadstring offers relies on calls that are easy to search for, especially for something like a VM that inefficiently imitates loadstring. Developers or antivirus plugins can unearth them easily if they care to. This toggle inconveniences attackers, but it isn’t a full defense.

Unless you’re responsibly using it with code you’ve vetted or with sandboxing, it should stay disabled.

[GE_0E]

@ultrareaper87

Does loadstring() being enabled even matter?

I don’t really know about that but

you only have access to enable it on the server
it executes the string in the 1st argument as code
example if you ran this on the server Hello will be printed

loadstring(`print("Hello")`)()

additionally, even though you cannot use loadstring on the client exploiters are able to use it and there are modules that act like loadstring() on the client