Can the a exploiter access other characters

Help and Feedback Scripting Support
#1

Hello everyone, the question is this, I’m making a shot from a weapon and would like to know how to properly hit it from a exploiter. Can it access all the characters in the workspace and pass them to the kill function PistolAttackE:FireServer(raycastResult.Instance)? If it is possible, what is the best way to avoid it?


Tool.Activated:Connect(function(Tool)
	if CoolDown.atackAllowed then 
		CoolDown.atackAllowed = false					
		task.delay(CoolDown.atackRate, function()
			CoolDown.atackAllowed = true
		end)		

		local UnitRay =  Mouse.UnitRay					
		local raycastParams = RaycastParams.new()
		raycastParams.FilterType = Enum.RaycastFilterType.Blacklist
		raycastParams.FilterDescendantsInstances = {Character}
		raycastParams.IgnoreWater = true					

		local raycastResult = workspace:Raycast(UnitRay.Origin, UnitRay.Direction * 100,  raycastParams)
		
		PistolAttackE:FireServer(raycastResult.Instance)		
	end
end)
#2

What do you call a “game cracker”? An exploiter?

1 Like
#3

Do not RayCast on the client! That is vulnerable to exploits.

1 Like
#4

I’m assuming by game crackers you mean exploiters/cheaters/etc

Yes, they can easily pass anything they want to a remote event. To prevent this you should instead send the UnitRay to the server and do all the raycasting on the server.
Remember to not trust the client and only get what is absolutely necessary from it.

1 Like
#6

So he can transfer the player’s coordinates from the client so that the Ray hits these coordinates on the server and it will be the same

#7

Yes exploiter, cheater and Etc

#8

So he can transfer the player’s coordinates from the client so that the Ray hits these coordinates on the server and it will be the same

#9

You don’t need to reply to yourself with the exact same message.
Also it’s not game cracker, it’s exploiter.

But yes, that’s the general idea. Exploiters can use getsenv to get the environment of your local script, and require for your modules.

1 Like
#10

Exploiters can change the raycast result to what they want to that even if they didn’t it anyone they can make it look like so to the server. Basically raycast on the server

1 Like
#11

If you want to have a fluent gun system, client sided raycasting is a better option. There are consistent ways of catching illegal requests at low performance cost on the server, such as a distance check, hits rate, etc. This overall depends on the type of game you’re making, but if you want to keep it 100% safe, make it server sided. You’ll just have a poor game experience for players that have a bad internet.

2 Likes
#12

The exploiter can send any mouse coordinates and then the raycast on the server will also hit the player. Therefore, just a raycast on the server will not save

#13

And the mouse coordinates are on the client, how can I make them on the server?

#14

Actually if you raycast on the server, if there’s something on the way, you will drop the request, so it doesn’t really matter if the coordinates were faked. However, it’ll be possible to make aim bots.

1 Like
#15

how to make protection against aim bots?

#16

Short Answer: Yes, people can loop kill by doing something like

for _, character in pairs(workspace:GetChildren()) do
    pistolAttackE:FireServer(character.Head) -- As you're passing a PV Instance (basePart)
   -- they could maximise damage by passing the head (dealing the most damage)
end

To the people who are saying “just raycast on the server as it’s more secure”, it wouldn’t really change much as you’d need to pass the origin position and the mouse position.i.e

PistolAttackE:FireServer(origin, mousePosition, raycastResult.Instance)

The code above would still be a security issue even if you were to calculate the raycast on the server BECAUSE the server cannot validate the origin nor mouse position, the server cannot read the source of those values (client sided); they have to trust that they’re truly from the centre of the camera and within the player’s FOV. You could try your best to validate these but you’d still be hit with issues, i.e trying to use Dot Product to check if the mouse’s hit position is actually within the player’s FOV, wouldn’t be viable as latency could really mess up shots or even if you spin really fast (legitimately).

You could add a cooldown between the fires to make sure that they’re firing the event within the RPM (which can be done by storing the weapon fired in a module). If this is a first person game then it’s a lot more harder to validate these types of things as most calculations/rendering/handling is done on the client. i.e Equipping a gun, firing the gun, etc.

Trying to protect against aimbot is almost impossible, in the old days exploiters used to use BodyGyros for aimbot which you could detect but FE wasn’t a thing.

The most you could do would be to do the following

  • Thoroughly validate line of sight through the server
  • Validate RPM (not sure how you’d do that as the weapon would be equipped on the client and the client could lie about their RPM)

Now you understand why FPS games have so much exploiters. Trying to make things more secure would ruin player experience, so the most you could do would be to do the best you can to secure your events and improve your game’s moderation experience. Most games should give up trying to CRACK the amazing code to prevent exploiters, but rather find a way to detect and terminate them.

1 Like
#17

You don’t have to tell the server the shot’s origin and it’s even a bad idea. The shot’s origin is the weapon’s tip, which can be securely retrieved by the server. For server side raycasting, all you need to send to the server is the coordinates of the mouse projection, which obviously cannot be verified by the server. Thus, you can ensure that players can only fire shots from a legal origin position to a potentially illegal landing point. With consistent protection against illegal player movements, you should be able to achieve an acceptable level of security. However, aimbots will remain a problem but there’s no much you can do against it without expensive computations.

1 Like
#18

I know. I said that it depends on the type of shooter style you’re going for. If it’s third person you don’t have to retrieve the origin and if it’s first person you’re going to have to trust the client. The origin doesn’t matter as the shots can still be shot in any direction through the player’s mouse position (which is more difficult to verify and latency could cause some issues with those calculations). Yes, trying to solve aimbot is just a waste of time as well, could be spent doing other security works.

1 Like