Exploiter accessing unauthorized area

local Zone = require(modules.Zone)
local container = workspace:WaitForChild("Extra Objects"):WaitForChild("Check")
local zone = Zone.new(container)

zone.playerEntered:Connect(function(player)
	player:Kick("You should not be in here")
end)

I’m currently using the zone module ZonePlus to detect if a player is within a part called Check in the workspace. I’m doing the check on the server and the zone module automatically detects if the player is in the area and then I kick the player. Unfortunately, the exploiter is able to teleport into the part almost as if they are deleting the part or their character can’t be detected by the part. What can I do to improve my anti-cheat system or what are the best methods to prevent exploiters from accessing restricted areas?

All help is appreciated. Thank you!

2 Likes

Exploiters can definitely do this and they always were able to do it.
Your best bet is a distance check on a mandatory part (usually floor).

2 Likes

I’m positive that there are no backdoors or any malicious scripts in the game. Is there anything that they can abuse to delete the part on the server?

They can only delete parts on their client. (this includes the script too)
Like i said if the said area has a floor, you can make a server-script that detects if it’s touched by the exploiter or not, and if it got touched, kick them. they can also delete the floor but that’ll just make them fall. (Ruining the entire point of even getting there.)
Make sure the script is in ServerScriptService, otherwise they’ll view the content of it and return the hit function.

1 Like

Hello,

This script that I’m using is utilizing the zone module which handles players entering or touching the zone. This is all handled in serverscriptservice and the zone module is in replicatedstorage. Would deleting the module on the client in replicatedstorage cause it to not function?

No, the client cannot replicated to stuff in ReplicatedStorage, but deleting it won’t do anything anyway.

I think it’s best for you to see if you can find the exploit’s code, and work out how to patch it from there.

1 Like

I believe that I found a fix. My main issue is them teleporting onto a board where objects are being pushed. Since they can collide with the objects it will ruin the player experience. As a result, I’m disabling collisions between players and the objects in the board. Would that be sufficient or is there any issues that could potentially arise?

1 Like

I unfortunately can’t say because I don’t really know the full impact of disabling box-to-player collisions in your game. If it works and doesn’t ruin anything for normal players, then it’s probably a good idea… It could also stop you from having to worry about this issue in the future, for example if players find a way to glitch onto the board without using exploits.

1 Like

I believe this will be a nice temporary fix to prevent the user experience from being ruined however another idea I had was determining if the player’s position was anywhere in the restricted area’s position. How could I grab all the vectors in an area to determine if the player’s position is in there? Sorry if its confusing I’m trying my best to word it.

I believe you can use workspace:GetPartsInPart to do the heavy-lifting for you;

-- every frame, check collisions
RunService.Heartbeat:Connect(function()
    local Parts = workspace:GetPartsInPart(KickZone, nil)
    -- go through all parts in region
    for _, Part in Parts do
        -- does the part belong to someone's character? kick them if so
        local Exploiter = Players:GetPlayerFromCharacter(Part.Parent)
        if Exploiter then
            Exploiter:Kick("Out of bounds")
        end
    end
end)
2 Likes

I’m not well versed within the area but I can give a decent theory/explanation

check the players position every 2 seconds, (char.HumanoidRootPart.Position - part.Position).Magnitude
if its close than kick them, also if this is for exploiters it can easily be bypassed.

My suggestion is to just not put to much thought into this, think of the big games like “jailbreak” exploiters can still enter the jewerly store once its closed, same with the bank, and various other area’s, so yeah.

1 Like

If they were able to delete the part would the script this work? I want to rely on positions rather than physical objects to determine as if they are somehow able to remove them it’d still work

i suggest using the thing you are using but checking if the character is alive while humanoidrootpart doesnt exist which means that they are exploiting and abusing to bypass the script though that could be fixxed too

simple script :
Note that this should be a script and not local

game.Players.PlayerAdded:Connect(function(Player)
	Player.CharacterAdded:Connect(function(Character)
		print("Started checks") -- Use in case script errors
		Character.ChildRemoved:Connect(function(Child)
			if Child.Name == "HumanoidRootPart" then	
			wait(0.05) -- Delay if player fell in void so it doesnt detect falsely
			if	Character.Humanoid.Health ~= 0 then
		Player:Kick("YourKickMessageForDecetion")
				end		
				end
end)
end)
end)

They won’t be able to delete it if it is anchored.

Regardless of that they can still delete it with a simple

local map = game.workspace
local part = map.PartHere
part:Destroy()

ZonePlus checks the position of the HumanoidRootPart which seems the most intuitive since you can’t just query Character.WorldPivot; The Character is a physics body, and the engine doesn’t change the property for performance. However due to vanilla replication, exploiters are able to delete their HumanoidRootPart to bypass the server checks.

The best way to stop this would be to just kick the player if their HumanoidRootPart gets destroyed.

local Players: Players = game:GetService("Players")

Players.PlayerAdded:Connect(function(Player: Player)
	
	Player.CharacterAdded:Connect(function(Character: Model)
		
		local DescendantRemoving: RBXScriptConnection = Character.DescendantRemoving:Connect(function(Descendant: Instance)
			if Descendant:IsA("BasePart") and Descendant.Name == "HumanoidRootPart" then
				Player:Kick()
			end
		end)
		
		Player.CharacterRemoving:Once(function()
			DescendantRemoving:Disconnect()
		end)
		
	end)
	
end)

Players.PlayerRemoving:Connect(function(Player: Player) -- Makes sure Player.CharacterAdded get's Disconnected
	task.defer(game.Destroy, Player)
end)

Then again, this behavior shouldn’t be expected.

1 Like

That is completely false. If they do not have network ownership of an object, they cannot change it, which is exactly why they can’t manipulate values in ReplicatedStorage, as it’s Server → Client only.

Client view, after deleting Baseplate:

Server view (with Studio Server View feature):

I highly suggest you edit your reply, it’s complete misinformation that contradicts the literal reason FilteringEnabled exists, to limit what the client can manipulate, to stop stuff like this from happening.

And, the code you sent uses a deprecated API

1 Like

I want you try the same thing but with a part that kicks the player.
Delete the said part with the script on client-side and see if the player can go through it or not.

Also they can still edit the proprieties of parts. (Such as cancollide)

Here's how they do it.
for i,v in pairs(workspace:GetDescendants()) do
                    if v:IsA("Part") then
                      v.CanCollide = false
                    end
                 end
1 Like

The player will always be able to fake their position, entire character, humanoid, and etc. If you want to be server authorative for the players themselves, you’re going to be sacrificing latency no matter what, but the most secure option is server authorative player characters, or something similarly cloud-powered

1 Like

Perhaps check a region3 on the client and server as exploiters cant delete a region3 I think but if they can then dont do this im sorry

1 Like