This is not the only way to make an anti-exploit, though…?
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).
its the only way to make the best one
because exploiters mostly inject guis
Most of them are in PlayerGui, and you’d need a localscript to do this as the ui instance is not replicated to the server.
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.
It’s not like they can remove specific characters from script or something… They just change upvalues and constants (or hook the function which won’t work on my method), now if you obfuscate it, they won’t be able to read it, therefore they won’t know exactly which upvalue/constant to change.
This method is almost flawless.
What can I do to prevent remotespy then? Do I… kick a player? somehow reload the remote event?
You can flood the output with prints or just kick the player. I made this to flood the exploiter’s output so that they get no information from any remote event :
for i=1, 40 do -- the 40 is how many lines will you print with an empty space
print(string.rep(" ", i%2))
end
But I think that you shouldn’t flood the exploiter’s output with a remote event that does nothing because the exploiter can add the remote event that is nonsense or just in his way to an ignore list which checks if the remote that was called was that remote and if it was it wouldn’t print anything dedicated to that remote event.
Obfuscation comes with deobfuscation.
As I said before, obfuscation is not security!!!
Why?
Multiple reasons:
- If you need to make changes to your obfuscated script (which you always will) it will be a pain to do
- It sucks on performance and readability
- Exploiters can do anything client-sided, I won’t repeat it again
False. There is ABSOLUTELY no way to prevent exploiting or exploits completely. There is no “perfect” method.
Just because your code is obfuscated doesn’t mean your code is safe or secret or hidden. Obfuscation is the same as deobfuscation: with a pattern and some reverse engineering. I am no professional on the cons of obfuscation so I’m not the right person to ask about the “good” and “bad” things about it, sorry for any lack of information as a result.
They would still know how to change upvalues and what are the upvalues and where they are. There is also a script called Hydroxide which is used for finding and changing upvalues and generating scripts that would change them…
How… does… this even protect your remoteevents?
iirc, RemoteSpy is a seperate Gui that records all inbound and outbound Remotes with data being passed on including your “flood”. Repeat sending RemoteEvents is very bad for an obvious reason (performance). RemoteSpy has scrolling (obviously), something I should very much point out. Even then, you can filter out certain Remotes because if the exploiter sees their output being flooded by the same RemoteEvent they would just blacklist it.
Implementing sanity checks should be the right way to do it. You should never pass valuable data along Remotes or allow a weak gatespot to exist and easily be passed through.
Edit: Implementing sanity checks should be the right and ONLY way to do it.
Top tier obfuscators even offer a real money for a person who can deobfuscate it, yet nobody managed to do so.
First two reason that you listed have nothing to do with security, they’re just prices you have to pay if you want your game to be secure. And about the third point, exploiters CAN NOT edit a script character by character, they change some values which results in a different (better for them) outcome. If they don’t know how script works, in which part is anti-cheat written and what method is used for that, it’s very difficult to bypass that.
Lastly, I never said that perfect method existed, they got control all over the client memory, it’s definitely not possible to just prevent all of them.