Can exploiters access the >>game.Players.(user).Backpack directory?

You shouldn’t have the ragdoll script be server-sided. It should instead be client-sided in a local script. When making a game the game logic should usually be handled on the server and the visual effects should be handled on the client. However, just be because the visual effects should be handled by the client doesn’t mean that the client should perform any game logic, as that would allow exploiters to do almost anything they wanted. Instead you should send all information to the server via RemoteEvent | Roblox Creator Documentation. Then the server should have a debounce that checks if the information received is valid. If it isn’t then an exploiter may be doing something.

However, there are some things that can only be handled on the server and for good reason.

NOTE:
This really is up to personal preference but is also a pretty safe method. Personally I go by the advice that you should never trust the client, meaning that if the client should never handle game logic because they can easily take advantage of it.

1 Like

In this case, there is no problem with having the ragdoll script be server sided, in fact I would recommend you use server sided ragdoll scripts because it will actually reduce the amount of data you’re sending and probably improve delay. This is different because its physics related, and, the physics for it should already be simulated by the client due to the way the engine works. The ragdoll code is most likely just creating and removing joints.

If your ragdoll script is a local script and you’re creating and removing joints, this actually wouldn’t replicate. The player’s body parts would fall through the ground since you delete their joints on the client but the creation of the new joints won’t replicate to the server.

There isn’t any reason to give the client control over whether or not they are ragdolled in this case, and, all of this code can be made server sided.

You should use LocalScripts for visual effects, and, anything that you might update a lot (e.g. lighting effects, or bullet effects), but this is not a visual effect, it involves physics and collisions and things.

2 Likes

No it is. Some executers have level 8 access, meaning they can modify the source

So would this be fine in starterpack, and I would just need to set the network ownership?

Thanks. I completely forgot about the BasePart:SetNetworkOwner command. Also, thanks for the info. I didn’t know that things like physics were not considered visual effects, although now that I think about it it does make more sense.

Actually you should do what @JodhaAT said and put the script in ServerScriptService | Roblox Creator Documentation. You can then have the ragdoll code be handled by a single function instead of an entire script. This is an ragdoll script I usually use:

local function Ragdoll(character : Model, killPlayer : boolean)
	-- Variables
	local humanoid = character:FindFirstChildWhichIsA("Humanoid")
	local hrp = character:FindFirstChild("HumanoidRootPart")

	-- Kill
	humanoid.RequiresNeck = killPlayer

	-- Ragdoll Rigging
	for _,descendant in ipairs(character:GetDescendants()) do
		if descendant:IsA("Motor6D") and (descendant.Part0 ~= hrp) then
			-- Attachments
			if not descendant.Parent:FindFirstChild(descendant.Name .. "RigAttachment") then
				local Attachment = Instance.new("Attachment")
				Attachment.Name = (descendant.Name .. "RigAttachment")
				Attachment.CFrame = descendant.C1
				Attachment.Parent = descendant.Part1

				Attachment = Attachment:Clone()
				Attachment.CFrame = descendant.C0
				Attachment.Parent = descendant.Part0
			end

			-- Socket
			local Socket = Instance.new("BallSocketConstraint")

			Socket.Attachment0 = descendant.Part0:FindFirstChild(descendant.Name .. "RigAttachment")
			Socket.Attachment1 = descendant.Part1:FindFirstChild(descendant.Name .. "RigAttachment")
			
			Socket.LimitsEnabled = true
			Socket.TwistLimitsEnabled = true
			
			Socket.Name = (descendant.Name .. "Joint")
			Socket.Parent = descendant.Parent
			
			-- Collision
			local collision = Instance.new("NoCollisionConstraint")
			collision.Part0 = descendant.Part0
			collision.Part1 = descendant.Part1
			collision.Parent = descendant.Parent

			-- Motor6D
			descendant.Enabled = false
		end
	end
	hrp.CanCollide = false
end

This is an old function I created a while back and I may have to change it with what I have learned since then, including today.

1 Like

Exploiters can access anything on the client (Localscripts). Anything on the server cannot be accessed by the exploiter or client (Regular scripts).

So no, exploiters cannot access the contents of a script at all. It’s contents are not even sent to the client.

This is not how exploiters change the contents of scripts.

@weeeeeeeeeel
@BuilderBob25620

A lot of exploits have the capability to run as a “Level 7” context (aka as a CoreScript). (Level 8 actually has less access than level 7)

The way that exploits modify scripts is not through the Source property though because in the player the Source property doesn’t actually do anything, its just blank and setting it will do nothing. That’s because scripts in the Roblox player are compiled scripts, they use a bunch of binary data.

Instead, most exploits actually just overwrite various functions and things in the engine. They can redirect the flow of your code, and, the effect is that they can modify your scripts, because, they can change absolutely any behaviour of the script, but, as far as I know they can’t easily directly modify the bytecode of the script. (Though I’m sure this is possible, its just not as easy for exploit programs to implement so its not necessary)

You cannot stop an exploit from doing anything, because, exploits have full control over how your code reacts to things, they can change how any aspect of the engine works no matter what. Any code you use to try and detect that can be stopped by an exploit, and, there is just no way around that. Your code is just some data in memory, and Roblox’s code is just some data in memory (despite being CPU instructions and stuff). All exploits are really doing is modifying a bunch of memory to achieve different results, and, that’s really all programs do too. Trying to detect them changing things relies on them using code which tells you that, like reusing the code in Roblox for setting properties which might fire changed events.

Exploits can modify and disconnect events, fire them, stop them from being fired, intercept anything going through them, and change how your callback will respond to a fire. Exploits can do this for RemoteFunctions & RemoteEvents to for data going to the client from the server and data going to the server from the client.

Exploits can change what code runs when you access a property, or call a function. They can change really anything, and, there is no way to safely detect an exploit in a LocalScript, because they can modify anything you can use to detect them.

@warycoolio

Most likely, yeah. As long as you set network ownership of their root part to nil the client won’t have control over the physics of their character, and, giving them back control would mean setting their network ownership back to their Player instance.

2 Likes

I’m not very experienced with ragdolling and rigging, so I don’t know how I would unragdoll them. I use a ragdoll and unragdoll function I found (which breaks alot) and connect it to a childadded.

I know how exploits work. What you have just said to me I already know.

This is incorrect. If they decompile the script, they can just set the source of the script and refresh it for it to run the new code. I have the tools to do it and have tried before. It does work

Edit: The scripts im talking about here are local

Actually I’m pretty sure that exploiters can access anything not in ServerScriptService or ServerStorage | Roblox Creator Documentation. Not only that though because like @JarodOfOrbiter mentioned, exploiters aren’t limited by the Roblox API and can access more than even developers can. However, this isn’t my area of expertise and I know that @Hexcede knows much more than me so I’ll stop responding on this post for the things I’m not certain about.

It kind of depends. It’s absolutely okay to do visual effects that rely on physics, its just in this case its not a visual effect since its not purely visual, it involves potentially effecting other things in the game.

You can do all kinds of physics stuff on the client only, without doing stuff on the server, and a lot of the time that’s a good thing to do, but, built in Roblox instances like joints and constraints and such will simulate for whoever owns the part, so in those cases its not a big deal if you create the joints on the server, and, sometimes, like in this case it might make sense to do that.

1 Like

Exploiters can’t decompile scripts period. Also, script.Source only works in plugins, if I recall correctly.

And no, you can’t set the source of a script, you can try this in studio yourself.

Wiki

EDIT: I never said localscript, I said script.

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