You mean server scripts. Client sided scripts can be decompiled.
Exploits like synapse x have level 7 access. They can modify the source of a local script
You’re probably talking about ModuleScripts. Anything else, you can’t just decompile, change some characters and re-run it with script.Source
What @x86_architecture is saying is correct, and, so is what you’re saying, ServerScriptService and ServerStorage are locations that can’t be accessed by the client at all so LocalScripts in there and things aren’t going to show up on the client.
But, things like Scripts do not send any data about themselves to the client because they don’t need to, server script source isn’t something accessible to the client.
@x86_architecture
Exploits can set the script.Source property it just doesn’t do anything in the engine, there is nothing to handle that.
Level 8 is not really a thing, its only recently that level 8 was technically a thing but it has less permissions that level 7 like I said. See this article:
Security context | Roblox Wiki | Fandom
Synapse can set its context level to anything (there is a function exploit scripts can use to change it iirc), it sets its context level to 7, because that’s the one with the most permissions.
4 Likes
Level 8 is a buzzword. There are charts that say what context levels do what, but 8 is not as good as 7 if it even exists. I don’t think 8 existed last I checked.
No, source can’t be set even with level five million. Even if you could access it legitimately, source just doesn’t work that way.
Your unragdoll function would be this:
local function Unragdoll()
for _,descendant in ipairs(character:GetDescendants()) do
if descendant:IsA("Motor6D") then
descendant.Enabled = true
elseif descendant:IsA("BallSocketConstraint") or descendant:IsA("NoCollisionConstraint") then
descendant:Destroy()
end
end
end
1 Like
Level 8 is technically now a thing, but it has less permissions.
See here:
Security context | Roblox Wiki | Fandom
Level 8 and level 7 are very similair
You can set the source. Mostly exploiters set it to “” and stop the script from running
1 Like
Where would I connect this and how, in a serverscriptservice script?
That’s easy though. You don’t even need level 7 for that, just just Cheat Engine.
Roblox detects cheat engine iirc.
Exploiters can access the Source property but the Source property does not do anything in the Roblox player, it only does anything in studio. Scripts are compiled meaning their data is a bunch of bytecode (a bunch of binary that the lua interpreter knows how to execute). Setting the script source property to "" does absolutely nothing in an exploit because the Source property is completely ignored in that case. It doesn’t get set to anything either, it will already be ""
No, they are not similar at all, level 8 has a lot less permissions, its meant for data being replicated from the server. It’s something completely different to level 7. You can read about it here like I mentioned:
Security context | Roblox Wiki | Fandom
1 Like
There are branches of CE. But even HxD will let you delete memory.
There are versions of cheat engine that are designed for Roblox.
@JarodOfOrbiter
Regardless, the script’s source is not stored in memory, scripts are compiled when they are in the Roblox player (not in studio), so, their source code won’t be anywhere. What decompilers do is take their bytecode and go from bytecode > some brand new lua code that would produce something similar.
When replicated it is just a bunch of byecode so the source is nothing, but if you set it using the exploit it will empty the contents and error. (Go into a game, and try setting the source of the localscript to “”. When disabled and enabled it will error)
PS: None of us here condone exploiting and we are not promoting the use of exploits. It is against Roblox’s TOS to exploit. Don’t do it
Correct, but the compiled code can be deleted. Roblox doesn’t make it easy though, at the very minimum they no longer just the same bytecode header as native Lua. And you can easily screw yourself over and crash.
1 Like
As far as I know the Source property does nothing in the Roblox player (though that would have been wayyyy before luau that I know that from), so, if Roblox changed some code regarding that (which is likely) then I guess that could happen, so, I might just be wrong here.
Exploiters can also just set the script’s .Disabled property to true and the script and any threads it spawned will be killed.
@JarodOfOrbiter Yeah, that’s absolutely true, you can modify script bytecode in memory though I would think that that would screw up the script state if you tried it which is probably a good reason why exploits don’t attempt to do this.
(The reason the length has to remain fixed is pretty common, usually stuff in memory has a fixed length, and that length is generally indicated by something at the beginning of the value, somewhere in the header data of the object usually, you could likely increase the length that Roblox is looking for, but then you’d extend into other memory in the program after the existing bytecode)
The reason exploiters don’t just disable it and change the source is that if there is a server script in the player’s character then the disabled property change will be replicated to the server (which is what exploiters don’t want. They can’t do anything about it because a server script is listening)
The .Disabled property does not replicate for LocalScripts under the character. You can test this easily by opening up a baseplate and disabling the Animate script in the client view, then switching to the server view.
Additionally, Synapse has the ability to prevent property changes from replicating to the server iirc via a special set method.
Client:
Server:
1 Like
If you have a look at a game such as mortem metallum, disabling a script will kick the exploiter. This is because there is a server script in the player’s character
Again, I just demonstrated, the .Disabled property does not replicate to the server. The reason is likely because they watch for changes on the client which is trivial to stop with an exploit and can be done in at least three different unique ways that I know of.
One of them is via the special function I mentioned which doesn’t fire changes. One of them is by disconnecting the changed event directly via the various APIs Synapse has to do that. One of them is by targeting the specific callback and breaking it. If the callback checks the Disabled property by getting it, a fourth way would be to spoof the property.
(Also, relying on stuff replicating to the server also isn’t secure, because again, exploits generally have control over that stuff)
Also, another way a script can be effectively disabled is by clearing its environment, in which case all functions with its environment will start erroring and such.
1 Like