On this thread, Woot3 posted:
I don’t know what progress this has made, but the inability to use loadstring clientside on FE games is preventing me from making a ROBLOX University-esque game with an in-house script editor to help teach people scripting because I wouldn’t be able to emulate any of their local scripts. loadstring was removed clientside because of security issues, but FE games aren’t subject to this issue and loadstring should be enabled for clients in these FE games.
This will never happen. Please stop asking for it. This has been discussed time and time again on this forum.
For server-side the only restriction is that PointsService access is blocked. This was back when PointsService had a global leaderboard so I feel like maybe we can just drop this restriction now without even checking for FE. If you have an exploitable admin panel then your points can be botted, tough luck.
[quote] This will never happen. Please stop asking for it. This has been discussed time and time again on this forum.
For server-side the only restriction is that PointsService access is blocked. This was back when PointsService had a global leaderboard so I feel like maybe we can just drop this restriction now without even checking for FE. If you have an exploitable admin panel then your points can be botted, tough luck. [/quote]
If they could exploit the script in the first place to call loadstring, why couldn’t they also just exploit the functions they want directly without having to mess with loadstring? Or are you saying admin panels that allow non-admins to loadstring? if it’s the case that the admin script allows any player to load string, aren’t you kind of asking for trouble anyway?
It just seems that it’d be easier as an exploiter to just change a script than to mess with changing a script and making it loadstring a hack.
[quote] If they could exploit the script in the first place to call loadstring, why couldn’t they also just exploit the functions they want directly without having to mess with loadstring? Or are you saying admin panels that allow non-admins to loadstring? if it’s the case that the admin script allows any player to load string, aren’t you kind of asking for trouble anyway?
It just seems that it’d be easier as an exploiter to just change a script than to mess with changing a script and making it loadstring a hack. [/quote]
Assuming you mean server-side, here’s the reason why the PointsService restriction exists:
The only way to block this for sure was to block point awarding from loadstring. We have discussed multiple complicated schemes to split Lua code into trusted and untrusted (some were similar to how CLR trusted/untrusted assemblies interact) but it ultimately got way too complicated to use and hard to implement so we implemented a simple solution.
[quote] If they could exploit the script in the first place to call loadstring, why couldn’t they also just exploit the functions they want directly without having to mess with loadstring? Or are you saying admin panels that allow non-admins to loadstring? if it’s the case that the admin script allows any player to load string, aren’t you kind of asking for trouble anyway?
It just seems that it’d be easier as an exploiter to just change a script than to mess with changing a script and making it loadstring a hack. [/quote]
Assuming you mean server-side, here’s the reason why the PointsService restriction exists:
The only way to block this for sure was to block point awarding from loadstring. We have discussed multiple complicated schemes to split Lua code into trusted and untrusted (some were similar to how CLR trusted/untrusted assemblies interact) but it ultimately got way too complicated to use and hard to implement so we implemented a simple solution.[/quote]
In a FE game changing the value client side would be blocked unless it was a remote specifically made for that purpose, in which case, you shouldn’t be surprised when someone abuses a remote that you give them.
And no, I was talking about the OP’s point, where the client can do a few things that the server can’t (like Gui work, things that don’t distribute, and RenderStepped, etc,) it would be nice to have loadstring work on the client for that reason. I doubt the OP cares much about PointService being blocked, he just wants to have his users be able to make local scripts and not just server scripts in his scripting game.
The issues described above obviously only apply to games without FE. But given a global points leaderboard (that we thankfully abandoned) it does not matter what your game does - any exploitable game affects global results.
So why is it we can’t use loadstring clientside on a FE game?
I spoke to Zeuxcg specifically about loadstring on the server and the rules put in place by Insert service on the server. Personally I want to see all the rules reduced back to how it used to be when Filtering is enabled without any penalty such as the loss of PointsService and inserting models that we own or are on public domain.
Make your own Lua VM in Lua?
What if server scripts could set .Source with loadstring enabled?
[quote] Make your own Lua VM in Lua?
What if server scripts could set .Source with loadstring enabled? [/quote]
I wouldn’t be able to emulate local scripts perfectly. I could go in and try to replace game.Players.LocalPlayer with their player, RenderStepped with Stepped (even though that would change the functionality of the code), etc, but there are things like GUI events not replicating to the server (I think) and the server’s inability to access the client’s camera that would make that impossible.
If you submitted a program to the server, which then sent the program to a module that loadstrings the program and returns a function, could the client call that module and run the program on the client?
Modules are different on the server and client. If I modify it from the server and then call it from the client, it will use the unmodified module since the server’s use of the module was separate.
loadstring returns a function, but I don’t think there’s any easy way for me to give that function to the client. I don’t think we can pass functions with remote* objects, so the only way I know of would be to set up my own server, send the code to the server, have the server publish the code as a local script model, and then have the client insert it, but I don’t want to have to pay for a server, and I don’t know how to set that up either. My only option is to use what’s available to me by default.
[quote] Modules are different on the server and client. If I modify it from the server and then call it from the client, it will use the unmodified module since the server’s use of the module was separate.
loadstring returns a function, but I don’t think there’s any easy way for me to give that function to the client. I don’t think we can pass functions with remote* objects, so the only way I know of would be to set up my own server, send the code to the server, have the server publish the code as a local script model, and then have the client insert it, but I don’t want to have to pay for a server, and I don’t know how to set that up either. My only option is to use what’s available to me by default. [/quote]
Server:game.ReplicatedStorage.RemoteFunction.OnServerInvoke=function(_,x)
return require(script.Parent.ModuleScript)(x)
end
Module:return function(x)
return loadstring(x)
end
Client:game.Players.LocalPlayer.Chatted:connect(function(source)
game.ReplicatedStorage.RemoteFunction:InvokeServer(source)()
end)
?
edit: server returns a function, client gets nil.
Why would I need to use the module? All you’re doing is passing it through a function that does nothing. You could just do:
function remotefunction oninvoke (x)
return loadstring(x)
It returns the same thing as your code.
Also, does this mean you can pass functions through a remotefunction?
right, there is no need for a module. RemoteFunctions don’t appear to be able to return functions (or coroutines) when FE is on (didn’t check for when it’s off). The next best thing would be to write a sandbox and hope they don’t write any infinite loops.
This will also never happen. In case there is an exploit that allows you to execute arbitrary Lua code on the server, this would lead to place stealing (assuming we actually implement getting the .Source as well, which we’ll kinda have to do!)
Lua VM in Lua looks like a reasonable option. I believe you don’t have to write it yourself.
I’m sorry that this is painful, but there is a reason why all these obstructions exist. loadstring on client will never come back because client no longer knows anything about Lua source code.
How about what I personally requested originally? This was unlocking anything that was locked before filtering enabled while it is enabled. This includes Loadstring on the server, InsertService being able to insert public domain models or any model the creator owns.
A Lua VM in Lua is a good idea, I think. Allowing students in a virtual school to script anything they want could be problematic. There is a reason university mainframes and scriptable MUDs have incredibly strong code sandboxing.
There are 3 Lua-in-Lua implementations listed here.
A potentially nice side affect of this is that you can gate what parts of Lua, and your Place, your students have access to. Turning off collections until they’ve reached a lesson that covers it, and only allowing them script access to Parts within a certain position range defined as a Scripting Lab, for example.
FYI I was thinking about the same issues while considering building a Roblox remake of the old Robot War game in which users could script their own battle robots to compete with. Being able to strictly sandbox players code would be critical to such a game.