I am trying to figure out if localscripts are good for making anti-exploit scripts, since I know that localscripts only change things for the client. But the problem is that the exploits usually change the client scripts and doesn’t seem to affect the server scripts which brings a lot of problems, such as trying to detect if a player is flying, or if a player kills everyone at the same time.
Trying to find a quick response to making people stop using exploits as seen in this picture.
So you’re saying that I can still use client sided scripts but I’ll need a backup that is server sided so if it detects if the localscript is gone it will clone a localscript from ReplicatedStorage and place it back there and if it is disabled the server-sided script enables it again?
This won’t work, since the change won’t be replicated. And they don’t need to disable or delete anyway – they can just put it to a stop. cc @DoctorNO2106
Don’t waste your time trying to make any part of your anti-exploit run on the client. The server has no ability to see a player’s LocalScripts so an exploiter can delete them and the server can’t even tell. Also, making a secondary script to check if the main script got deleted doesn’t matter either. They can just delete all of them at once.
Exploiters have network ownership of their character, so if it’s replicated to the server it’s within there control. This is what allows exploiters to fly, teleport, etc. Now there is never a one size fits all solution for preventing these because depending on your game it might need to work differently to prevent the real players from being mistaken as hacking.
Raycasting and magnitude checks are useful in finding movement exploits, but just be careful of your enforcement of these methods as players with high ping will encounter issues.
I don’t think exploit protection on the client is that bad. Most exploiters are taking some stupid script made by someone else, and usually not even game-specific. So that script won’t be removed. Most exploiters would just stop. And it definitely helps. But you should have maximum protection in the server side as possible
LocalScripts should not be used at all for anticheats. THey can just be deleted.
Think of your game like a web server; Anyone can send a request to it, and you must validate which requests are valid and which are invalid. Run sanity checks everywhere. Do velocity and position checks. I would not rely on localscripts at all for any kind of exploit detection.
the only way to make a anti exploit is to access the CoreGui and when something gets added there you can kick the player, but with a client script you cannot access it. there might be other ways to do it but i have no idea what they are
Arsenal has a problem with this because they’re probably not effectively preventing things like no-clipping, lag switching, and teleportation. This can be fixed through raycasting and logging the player’s position on the server… with some major tweaking of course.
My guess is that they’re only doing a cooldown/ammo check locally which doesn’t prevent the exploiters who fire without a cooldown and with infinite ammo. Not really sure how else an exploiter can do this unless perhaps their time synchronization between the client and server is faulty (for the cooldown) … and there should never be a reason to have infinite ammo if the client is never trusted.
It may be a bit harsh, but if I were to ever design a fps I wouldn’t count shots made immediately after a lag spike that lasts x amount of time to prevent lag switching. I don’t think lag should be an advantage and a laggy player expects their shots to frequently miss … as opposed to a normal player getting back-stabbed through lag switching. You can try to get clever and force the shot to be fired from a distance at 3/4 between the starting and ending positions of the lag spike … but even this could probably be exploited (although it would be MUCH harder to effectively lag switch).
Best way to stop that (in the picture) is to implement shooting system properly, make sure that you’re not sending anything vulnerable from client to server, if you are, then validate it on the server and there won’t be any need for anti-exploit.
Also, most people replied saying LocalScript is absolutely useless since exploiters can just disable/delete it. Obviously it’ll be useless if you make it that simple. You could however implement an anti-cheat in some important LocalScript (important because if it gets deleted then game should stop functioning properly, so they can’t just delete it). To make it even harder for them you could implement the anti-cheat in some core function of that important script (that way they can’t just hook the function, because again, game will stop functioning properly if they do that). Finally you could obfuscate that script (which may very well cause an FPS drop) but I’m somewhat certain that this way they couldn’t avoid that anti-cheat (because obfuscation adds like hundreds of constants and hides the actual important ones)
Exploiters can read, modify or delete localscripts. iirc, exploiters can do anything client-sided, as they have full power. No point hiding your clientside anticheat in a corescript.
Obfuscation is NOT security!!!
Infact you are wasting more time and security by obfuscating your scripts than implementing complete simple sanity checks.
I’ve heard of games that ban players if the client detects a foreign GUI object created and parented to PlayerGui which isn’t good in terms of innocent bans, bad security etc but does something for inexperienced script kiddies
You could, but unfortunately laggy players get mixed with people intentionally lag switching. Sadly you only have 2 options that will never be fixed: Try to solve the problem which is slightly effective but includes innocent players to be affected or to do nothing.
I tried to detect Dex and it was… well… complicated, to say the least. GUI-insertion bans shouldnt exist, and even if they do the punishment should be the gui removed or the player re-joined with data saved yk
Hey, guys just came here.
Have you try to put an anti-exploit script inside “nil”?
If someone wonders, yes script will work fine, and to escape problem with Dex, protect it with gcinfo().
I know how to detect Dex Explorer and Remote Spy, here are some simple scripts I made for you to try :
Remote Spy
local Remote = Instance.new("RemoteEvent")
local FireServer = Remote.FireServer
while wait() do
if FireServer ~= Remote.FireServer then
print("Remote Spy Was Detected")
end
end
Dex Explorer
game:FindFirstChild("RemoteDebugWindow", true)
You can try using these scripts so that you can try to detect either of the things but I highly doubt they would work since the exploiters have access to the rawmetatable and also they can use hookfunction to not get kicked / punished…
The problem is that most exploits can detect and select instances without parents with custom made functions like getNilInstances() at this point so that kind of protection is pointless.
Everything I can say, is that I don’t fight the exploiters anymore, it is pointless. There is no perfect anti-exploit for that. I am just trying my best to handle remotes safely and use server anti-exploit protection.
