How would I make my melee weapon system more secure against exploits?

Help and Feedback Scripting Support
#1

Hello, so few months ago i made my melee “system” that can destroy the destructible objects on the map and kill other players, but i recently realized, that it has a big flaw…

How it works is I’m using Camera,ViewportSize (previously used Mouse.Hit.Position) to make a ray from the center of the Viewport to find a part I’m looking at, next, I create another ray from player’s head in the direction of that part with a length of 7 studs, and if I find a part - I send it to the server, and this is the big problem… because if they can just fire any parts, they can destroy everything in no time at all, doesn’t matter i have a magnitude check or not, if they can loop through all the parts, find player head’s and pretty much make an auto-killer.

Local script (not full):

function getMouseAndTargetLocation(cursorPosition)
    local viewportPoint = camera.ViewportSize/2
    local unitRay = camera:ViewportPointToRay(viewportPoint.X, viewportPoint.Y+36)
    local ray = Ray.new(unitRay.Origin, unitRay.Direction * 999)
   	local hitPart, hitPosition = game.Workspace:FindPartOnRayWithIgnoreList(ray, {char})
   	---
   	local origin = char.Head.Position
   	local direction = (hitPosition - origin).Unit * 7
   	local ray = Ray.new(origin, direction)
   	return workspace:FindPartOnRayWithIgnoreList(ray, {char})
end 
rswingTrack:GetMarkerReachedSignal("Hit"):Connect(function()
  	local part, pos = getMouseAndTargetLocation()
   	if part then
   		script.Parent.Server_Handle.Dest:FireServer(part)
   	end
end)

Server (not full):

script.Dest.OnServerEvent:Connect(function(plr,part)
	if part then
		if (part.Position - workspace:FindFirstChild(plr.Name).Head.Position).Magnitude <= 8 and part:IsDescendantOf(workspace.CurrentMap) then
			script.Parent.Boom:Play()
			part:Destroy()
		elseif part:IsDescendantOf(workspace) and part.Parent:FindFirstChild("Humanoid") then
			part.Parent.Humanoid:TakeDamage(part.Humanoid.Health)
			script.Parent.Boom:Play()
		elseif part:IsDescendantOf(workspace) and part.Parent.Parent:FindFirstChild("Humanoid") then
			part.Parent.Parent.Humanoid:TakeDamage(part.Parent.Parent.Humanoid.Health)
			script.Parent.Boom:Play()
		end
	end
end)

How could I make it more secure to exploits? (I know it’s quite messy, feel free to suggest how i can optimize it :wink: :smiley: )
It’s local script because of camera and mouse.
What could i change, or what could I check for in the server script?

I was thinking casting rays from server only, but I can’t send camera object or mouse with RemoteEvent, can I?
The best i can come up with is send the hitPart and hitPosition, and then do the rest on server.

1 Like
#2

You should put most of the detection on the server, because the server is more secure. In addition, if you use remote events, exploiters can utilize the server via remote events. So, how you can avoid that is do all the checking work on the server. From what I see, the script looks pretty secure

3 Likes
#3

Yes, i’m well aware of the server/client relationship, matter of fact, i wrote about what are my plans for this, too, but the question remains, what would i be checking on the server side? Could maybe check weather the part i’m destroying is in front, but how?

1 Like
#4

Anything that the hacker can do on the client, such as changing values, positions, etc. Even though it’s only visible to them. But, keep in mind, if that happens, and they change a position of a block and jump on it(because one of the blocks is placed from a local script then to the server via remote event), players would question why that hacker is floating in mid air. Basically it’s user data values(don’t get me wrong, that’s what I am doing, or trying to do in my game)

1 Like
#5

I learnt to have the player ask the server to do stuff. So “Hey server I just clicked my mouse!” The player sees and instant eye candy thing that actually does nothing other than look cool.

Server goes. “Ok you clicked so I’ll create the eye candy for others to see. I’ll also do a check to see if you hit anything. Yep you did so I’ll destroy that for you. Done.”

Point being, hackers can trigger mass spam melee at any rage and even one that hits the entire map. But the server ignores all that and only accepts the request from the player. The server only gets 3 messages maybe. Which player clicked, which button they clicked, and which weapon the player wants to use. If the server allows it, then it happens.

How to do that, the server would create a ray from the player model. Possibly using it’s LookVector (Not sure about that 1 specific part but you can look that up. Getting a player’s LookVector. If that ray returns a part, destroy the part.

1 Like
#6

Make sure you have server cooldowns so people aren’t just spamming your remotes

2 Likes
#7

The simplest, easiest solution is to add the distance check to the server as well (if the player is within 7 studs; allow it).

Keep in mind their character’s movement is generated from the client, so if they start moving away and it takes longer than a few milliseconds to reach the server, they may be farther than 7 studs.

From what I’ve seen, the best way to counter that issue is to just check a somewhat larger distance; so maybe if it’s 7 studs max on the client, do 15-20 on the server to account for latency.

This way, even if they create a loop to destroy everything, only objects within the radius you set can actually be destroyed.

Additionally, you can add some hacker-handling to automatically kick/ban players that are doing the impossible (via exploiting). So if someone tries to destroy something that is farther than say, 80 studs (to really make sure latency isn’t the issue here), you can then just kick them. Now, if you have movement speed modifiers or teleporters or anything that will move a player a large distance instantly (or very fast), you should be really careful about kicking players based on how far they are from what they are trying to destroy, since there are exceptions depending on how fast players can get around or how much delay they are experiencing.

A better way to kick them may be to say, if (on the server-side) a player is sending more than X amount of remotes in Y amount of time (maybe 10+ times in 0.1 seconds), warn or kick them.

1 Like
#8

Yeah, i decided i’ll add a limit to how quickly the remotes can be launched, which i should’ve done in the first place :smiley:
I already had the magnitude check. I’m also thinking of doing an angle check, that is to check weather the angle between RootPart’s lookVector and the vector from the RootPart to the part in question is greater than like ± 90 degrees, so 180 degrees total, but you’re right, it doesn’t run instantly and given you can turn really quickly, not sure if i should pursue it…
My biggest weapon in fighting exploits will be the time between the firing… Because it’ll go to a point where it’s quite useless to do for exploiters i think.
The biggest issue is if they can run their own script locally, they can just make a loop that finds player head’s or humanoids and kills them via this remote :confused:

1 Like
#10

Encrypted Remote Keys, Input Checks, Remote Rate Limiting

#11

Encrypted remote keys? For example?

#12

I’ve seen a number of people who say that encrypted remote keys are the way to go. This is false. Here’s why.

Encrypted remote keys will always be accessible to the client. The client (exploiting or not) needs these keys to send remotes for the general game to work properly. Since the client has access to these keys, it’s easy for them to send the same key over and over.

The best way to fix this, from what I’ve experience and your current codebase, is to add a cooldown. If you’re letting player’s perform actions (slash, slice, etc) freely and at an unlimited rate, you’re going to get people who spam it.

1 Like
Help Patching An Exploit!