Your post is not correct. Please read the OP.
No, he’s correct. I read the post and it contained exactly what I suspected: you can steal client scripts. You can’t steal server sided things.
2 Likes
Is it possible for exploiters to read what local scripts say?
2 Likes
Yea, it is possible. [ Just adding this since there’s a requirement of 30 characters minimum in a reply. ]
Yeah, to be specific, people can see the code in LocalScripts, but only to a certain extent. All local variable names and comments are erased from them before they are sent to the client application. So, if you would have a script like this:
local game_time = workspace.DistributedGameTime
-- This function will compute the sum of two numbers
local function sum(number_a, number_b)
local sum = number_a + number_b
return sum
end
print(sum(game_time, 1))
Then people might be able to decompile it like this:
local v1 = workspace.DistributedGameTime
local function v2(v3, v4)
return v3 + v4
end
print(v2(v1, 1))
9 Likes
Are MetaMethods/MetaTables Replicated on the server and client?
An example would be:
--inside of the exploit's terminal local obj = --wherever it is local metatable = getrawmetatable(obj)
metatable.__index = function(_, k) return 16 end
print(obj.WalkSpeed) --16 if obj.WalkSpeed > 16 then --this is useless now
player:Kick("Yeet'd out of the universe")
end
(got the code from here)
2 Likes
Good question, which I didn’t actually cover in the article, metatables aren’t replicated from client to server, meaning if an exploiter messed with a Part’s metatable from the client, only the client’s part’s metatable would be messed, and not the server’s. Exploiters mainly do that to stop sanity checks in the client side, WalkSpeed for example doesn’t replicate from what I know, so even sanity checks from the server won’t work. But doing sanity checks on the client is just useless due to this technique, plus the fact that exploiters can remove scripts, so people commonly don’t do it, thus this exploiting technique isn’t always effective.
2 Likes
Not only that, but exploiters can even terminate a script’s execution without removing it or setting its Disabled property.
3 Likes
Only the server has the ability to compile Lua code. You’d need a RemoteEvent somewhere to be sending the string. Even then, it’s limited in API power but it’s access on the server-side which is much more destructive whether special API is available or not.
2 Likes
Source? Does Luau not allow loadstring() on the client even if you have the boolean checked in ServerScriptService?
No. The previous Lua compiler was stripped from the client, and so is the Luau one. It’s a major security issue to have the code for compiling Lua even be present in the client.
If the code was present, it wouldn’t matter whether or not you allowed loadstring through the server setting. One could just call the code regardless and get anything running on the client’s VM.
1 Like
…which is exactly what I outlined in my post. Read.
I didn’t know this was stripped from the client though. Thanks.
I believe it might be possible to make client-side anti-exploit scripting by having a remote make periodic checks to the client and make sure those values are the same on the server. If that remote didn’t respond in the correct format, the values didn’t match, or the remote didn’t respond at all, the server could kick the player.
When people say don’t trust the client, they mean everything (including this) is vulnerable to spoofing. If your idea starts at the client and ends at the client, it probably won’t be effective.
3 Likes
It doesn’t end at the client. The server would be checking every so often using the remote, and if the client script’s response was in any way different from the correct response format of the local script, or the client script didn’t respond, the player would be kicked. So, if the script was disabled, replaced, or compromised by client-side exploits, the player would get kicked at the next check.
No, the idea ends at the client. There is absolutely no way to confirm the information going over the remote is legit and could be easily spoofed.
A purpose of not trusting the client is so you don’t have to worry about workarounds and instead concentrate on the necessary traffic.
3 Likes
Well I’m not sure how you can be sure of what I saw… unless you know EVERYTHING about Roblox or you can see me 
. Based on your reply it seems neither is correct. This magical “I.D.” you are so skeptical of is the number or asset I.D. or whatever the official term is. Just like all assets such as textures, meshes, and places have a numerical I.D. there is/was a website that uses that unique number to download the asset. The person I watched do it opened a marketplace script in Studio and found it was calling another script inside a different place… so he took the place number from that script and copied it to that website. The website popped open a dialog to download. The file downloaded was actually a regular Studio file and could be opened and edited. I watched him do this in person. Not a Youtube video and not a scam website.
To be fair, I don’t know if the place was uncopylocked. It’s true and I hope it can be fixed. This platform is just a big file server. All our hard work is on http/https web servers. I’m not sure what can be done to stop this. I stand by what I said and hope someone official here takes it seriously.
1 Like
Well, I’d say that’s quite the flaw right?
Not sure how this happened, don’t think you can just run a script inside of another game remotely and view the source of server scripts.
I’ve never heard of nor seen exploiters being able to steal server scripts. It just isn’t possible. My point still stands. There was a website that allowed you to take animations and shirts with an ID, but a game? No. Even if they had a backdoor into your game, how would they view the source of your server side scripts? Don’t think you can even print .Source of a script anymore. I believe it requires a certain level permission.
Trust me, I’ve been on Vermillion, and other exploiting sites. I’ve seen what they have to offer, and even THEY know they can’t steal server scripts. It’s common knowledge. If there was a way to just easily steal a game as you described, I’m sure Roblox would know, and it would be going crazy on Vermillion.
I am in no way claiming to know everything about Roblox, but I know enough about exploiting to know that you can only decompile local code. The game must of been uncopylocked.
If your friend has done this, has he not reported it? Apparently your friend has access to some sort of roblox servers which allows him to download any game with some magical ID he wants. What else does he have access to? Sounds like a way to get into some big trouble! 
If your friend has a report to make, they can go to https://www.hackerone.com/roblox and file a report.
Sounds like you’re describing an uncopylocked place, as the only way an external website could access these assets is if they were uncopylocked. As @WorldPosition correctly stated, it’s pretty improbable that any “server script” stealing was going on, as there is a bounty of a few thousand USD going around for that.
Since Occam’s Razor states the most simple solution is most likely the correct one, we can effectively deduce that the place you describe was uncopylocked.
2 Likes
Awesome explanation and has tons of information in it. Great work. 