Is This A Reasonable Way To Handle Exploits on the Client?

Hi all, I’ve recently been struggling coming up with solid ways to detect and deter exploiting. So, I have come up with the following:

A picture of the setup:
1
In a server script:

--In a player added function
while true do
		wait(1)
		if player.PlayerGui:FindFirstChild("PlayerHandler") then
			player.PlayerGui:FindFirstChild("PlayerHandler"):Destroy()
		end
		local antihack = script.AntiExploit:Clone()
		antihack.Name = "PlayerHandler"
		antihack.Parent = player.PlayerGui
	end
Then, in the local script:

(the following snippet modified from This Post to suit my needs)

local player = game.Players.LocalPlayer

local humanoid = player.Character:WaitForChild("Humanoid")

local MaxHealth = 100
local MaxSpeed = 16
local MaxJump = 50

local Character = player.Character
local Backpack = player:WaitForChild("Backpack")
local HumanoidRootPart = Character:WaitForChild("HumanoidRootPart")
local Bodys = {
	["BodyGyro"] = true,
	["BodyPosition"] = true,
	["Body Velocity"] = true
}
local Btools = {
	["HopperBin"] = true,
}

Backpack.ChildAdded:Connect(function(Obj)
	if Btools[Obj.ClassName] then
		player.Character.Humanoid.Health = 0
	end
end)

--Anti Fly
HumanoidRootPart.ChildAdded:Connect(function(Obj)
	if Bodys[Obj.ClassName] then
		player.Character.Humanoid.Health = 0
	end
end)

--Anti FE God / Anti Humanoid Destroyer
Character.ChildRemoved:Connect(function(Obj)
	if Obj:IsA("Humanoid") then
		player.Character.Humanoid.Health = 0
	end
end)

game:GetService("RunService").Stepped:Connect(function() -- get rid of bad stuff.
	print("running")
	humanoid:SetStateEnabled('GettingUp',true)
	humanoid.MaxHealth = MaxHealth
	humanoid.WalkSpeed = MaxSpeed
	if humanoid.JumpPower ~= 0 then
		humanoid.JumpPower = MaxJump
	end
end)
Video of it in progress

I understand that doing client-sided anti-exploits are not the best way of going about it, as anything on the client can be modified. However, this script is repeatedly copied into the player’s playergui, so even if they destroy it, it would still run, correct? I am pretty naïve when it comes to what exploiters are capable of. However, would this be enough to stop the average exploiter?

I am taking other measures on the server (protecting remotes, etc), but my efforts regarding the player’s humanoid seem to be futile without doing it on the client. What tips or suggestions do you have? What can I improve, or should change? Thank you for your help!

3 Likes

All an exploiter has to do is delete the local script though…

The script would automatically be re-inserted through the server script, so the hacker (in theory) would have to delete it every frame.

They’re using a SERVER script to insert the script every 1 second.

Are you sure that the client-sided deletion of the LocalScript would replicate to the server?

1 Like

It doesn’t replicate. The server still recognizes the local script as there, which is why I did the following (in the server script):

if player.PlayerGui:FindFirstChild("PlayerHandler") then
	player.PlayerGui:FindFirstChild("PlayerHandler"):Destroy()
end
local antihack = script.AntiExploit:Clone()
antihack.Name = "PlayerHandler"
antihack.Parent = player.PlayerGui

Ah, I see what you are doing now.
I haven’t been on ROBLOX in a while.

I can’t test anything right now, but I think the answer to your question can be found in the answers to a number of others.

  1. Will these loops have a noticeable impact on server-sided game performance?
  2. Are you sure you can access a Player’s PlayerGui from the server in that manner?
  3. If you can access PlayerGui in this manner, what impact will repeatedly creating and deleting your anti-virus (along with its loops and connections) have on the user’s client-sided game performance?

I think there are a few ways to achieve what you are trying to do that have a lower impact on performance. So long as exploiters can stealthily manipulate the game’s metatable, your anti-cheat will never get an accurate depiction of the client’s true game state. Also, restarting said anti-cheat would just make things worse, because it means your anti-cheat would start with spoofed values.

I will say, you can start a thread using a ModuleScript and parent the instance to nil. You can then use the invoked ModuleScript’s code to manage your local anti-cheat from nil. Again, there are ways to get around it, but it’s just another way to add a layer of obscurity and difficulty for less capable exploiters.

1 Like

Thanks for letting me know! This is one of my first time making an anti-exploit.

I don’t think so, there is a wait(1) in the while loop, so it shouldn’t fire too often.

This one is a definite yes, as you can see from the video in the post:

This is a great question that I am experimenting with. The game isn’t taxing on the client (there are hardly any local scripts in it, and the server scripts don’t spam). But, I’ll have to do some more research on my own about the effects of this method. I will look into parenting a ModuleScript to nil, thanks for the suggestion and feedback!

Can it handle if I insert fake playerhandler and remove the real one.

EDIT: K, I would execute local script like this:

game.Players.TomYoGaming.PlayerGui.ChildAdded:Connect(function(object)
object:Destroy()
end)

1 Like

its futile to do client security, just secure your game from the server

3 Likes

The real one is automatically re-inserted. The fake one would just stay in the playergui.

What prevents someone from disconnecting your connections every few seconds as well? Exploiters can listen to events like ChildAdded the same way you can, and more.

2 Likes

check old post, i responded a script against that

no this is not a good way, an exploiter can easily get around it.

What happens when you “copy” a local script from the server to the client. The server sends the client the information about a local script, and the client can choose to do whatever they want. If they don’t want to run it they don’t have to.

It’s futile to do client security, just secure your game from the server

3 Likes

I understand that client security is futile to a certain degree, but would this stop the majority of exploiters who don’t know how to manipulate the game as well? When the client makes changes to the humanoid, the server doesn’t seem to pick it up (from my tests), which is why I did this.

That is a fair point. I don’t know how easy it is to exploit, or what exploiters are truly capable of (I understand they have access to and can modify anything on the client), but beyond that, I am lost.

Would it work to randomize where this script appears in playerGui (I.e hidden inside one of the screen guis, or a textlabel, etc). Would this be enough to stump/irritate enough exploiters until they give up trying to erase it? Thanks for all of your help, I’m doing my best to understand everything. This is my first time trying to design my own anti-exploit.

you only need one exploiter to release the method for everyone to be able to do it – also you don’t need to listen to humanoid changes to combat a lot of stuff.

you can combat walk speed changes by checking player velocity, flying by raycasting, …

1 Like

no it wouldn’t “stump” exploiters.

99% of exploiters are just 15 y/o skids using synapse who don’t even know how to script.

1% of exploiters actually make the scripts and release them to the skids. the 1% are not noobs and can bypass any minor nuisance you send their way.

I recommend reading this thread

3 Likes

Thanks for the tip! I’ve always been confused on

while true do

vs

while wait() do

so the tip helps.

Let me tell you the basic security.
You never trust the client. Trusting that their anti-exploit is not defeated is not the best way of doing things.
No matter how much you try, you are never in control of the client. You can’t make it behave how you want it to be.

Simply put, you must handle anti-exploit server side.
A good amount of it is basically checking if they’re capable of being there. Implementation of that? Not sure. I can think of a couple but I guess I’ll try to implement it first before I’ll tell you.

1 Like

This can work, but it will likely fail.

The exploiter can delete the client anti-exploit then do whatever they want for the one second of no protection.

1 Like