How to fully patch reanimation exploits

UPDATE:

A month ago, RejectCharacterDeletions was forced to every roblox experience, to “patch” exploits regarding to removing welds from the client for them not to replicate animations.

This did not patch hats, which meant you could still mess with them from the client, and funny enough, even exploiters decided to make their own limbs to reanimate again:


I’m not going to explain how it works (If you have basic lua knowledge you might understand now), as it would probably get this thread deleted, but here’s my script to patch it.

-- Important
RespawnAntiDeath = true -- Respawns exploiters with antirespawn

--- Punishments 
ResetVelocity = true -- Resets it to default and makes the hats fall
Kick = false -- ONLY USE IF YOU ARE SURE YOUR SCRIPTS DONT MESS WITH VELOCITY

game:GetService("Players").PlayerAdded:Connect(function(Player)
	Player.CharacteracterAdded:Connect(function(Character)
		while Character do
			task.wait()
			
			if Character.Humanoid:GetState() == Enum.HumanoidStateType.Dead and RespawnAntiDeath == true then
				task.wait(game:GetService("Players").RespawnTime)
				Player:LoadCharacteracter()
			end
			
			for i,v in pairs(Character:GetChildren()) do
				if v:IsA("Accessory") and v:FindFirstChild("Handle") and v.Handle.Velocity.Y ~= 0 then
					if ResetVelocity == true then
						v.Handle.AssemblyLinearVelocity = Vector3.new(0,0,0)
						v.Handle.AssemblyAngularVelocity = Vector3.new(0,0,0)
					elseif Kick == true and Character.Humanoid:GetState() == Enum.HumanoidStateType.None then
						Player:Kick("Yo..")
						v.Handle.AssemblyLinearVelocity = Vector3.new(0,0,0)
						v.Handle.AssemblyAngularVelocity = Vector3.new(0,0,0)
						--print(Character.Humanoid:GetState())
					end
				end
			end
			
		end
	end)
end)

I don’t recommend using kick, unless you are 100% sure your game doesn’t mess with velocity in any way, now what resetting the velocity do? Exploiters wont have network ownership to their hats, and oof! They fall into the void.

10 Likes

Why would it? RejectCharacterDeletions is meant to patch a legacy behaviour prior to the introduction of a proper client-server model where a client can delete instances in their character and the change would authoritatively propagate to the server. It’s unrelated to physics exploits.

Resetting velocity doesn’t change the network ownership of accessories. A character is network owned by the player it belongs to and that includes the customisation assets its given on construction. Resetting velocity is just resetting velocity, it has no implications on network ownership.

1 Like

RejectCharacterDeletions does not patch the client-server when the character is dead, exploiters can delete their bodyparts on death, which is the current method exploiters use to “reanimate”.

Resetting velocity doesn’t change the network ownership of accessories. A character is network owned by the player it belongs to.

I mentioned this as you actually have to delete the welds off, and since the character is dead it will be replicated and you can mess with the accessories. The player with the most simulationradius would have networkownership of the hats and could do anything they want with it as it is unanchored. Exploiters usually set the velocity to a value higher than (0,20,0) to keep them intact.

3 Likes

Are you saying this because you’ve tested it or because you’ve seen it? I’m checking here in Studio and a quick repro doesn’t really match up to what you’re saying. If it’s the latter, then how can you be so sure that the experience in question hasn’t opted out of RejectCharacterDeletions?

-- Executed on client
workspace.colbert2677.Humanoid.Died:Connect(function () workspace.colbert2677.Head:Destroy() end)

-- Executed on server
workspace.colbert2677.Humanoid.Health = 0

-- Head does not disappear on the server view, ergo not replicating

If a character is dead and the physics of its parts are replicating, then as mentioned regarding the “seeing rather than testing”, how can you be so sure that the developer doesn’t restore the legacy behaviour of giving the client network ownership of their character on death? Currently, part of the automatic network ownership contract is that the server is given ownership of characters on death.

I’m interested in seeing a repro made by you showing the behaviours this code is supposedly trying to fix. As far as I’m aware, this fix is being provided on non-empirical grounds. Experiences that are still liable to this exploit either have different setup and requirements that incidentally enable this behaviour again, or I might be wrong as are my tests, but that doesn’t seem to be the case right now?

1 Like

It doesn’t directly work like this, I can PM you the script if you need it as I’m not going to explain more here I’m not trying to get banned for explaining how an exploit works.

Edit: heres me testing it and rcd is enabled

2 Likes

That’s fine if you want to, but you aren’t going to get banned by explaining how an exploit works at a high-level, that’s not how we do things here. On the other hand, you would be banned for encouraging or otherwise distributing exploits on the forum explicitly.

There are many threads here on the forum regarding exploit countermeasures that also need to do their due dilligence in explaining how something is a problem to present a solution - in this case, there is no such explanation for that problem.

I would also suggest writing a bug report (with a private message, if applicable) on this topic so it be triaged for engineers to review. It would help if you would be able to contribute to having a native fix in the engine as well rather than a code sample that may not be applicable to most experiences.

4 Likes

I second this, I’ve told people how exploits work before with no issue, so you can feel free to add further information here if you wish.

1 Like

Update on this situation lol:

Roblox staff ended up removing the limb accessories, but forgot about the torso:


image

UGC owner pretending like it’s completely normal:

1 Like

Update: this has finally been patched!!!

Well about that!

print("I love Roblox!") -- Definitely not for the limit.