I wanna design a anti-exploit for my roblox game, I didn’t really wanna make it movement based though because hackers might abuse server-sided movement checks, Does anyone know a way on how to detect if someone injects scripts or gui’s?
1 Like
To prevent injecting, you want to have scans for 3 major things:
- Additional scripts or guis added to explorer
- Modifications to scripts
- Calls to remote events
Id highly suggest using a registry to store all the client scripts by calling them during loading and using your registry as a source for information. I do that for my current games and it works wonders as I am able to delete all client scripts explorer side after theyre loaded in; if an exploiter can’t access a client script then that saves a ton of work.
Having a networker serialize calls from certain clients and connecting said networker to the registry is how you handle the remote aspect. Use a hash at start, send it through server to client. Make it so each network call requires a hash verification to check origin.
Injecting is a bit complicated, but best bet is to just identify if a script is added client-side after registry is setup, and comparing it to your verified scripts.
Heres my registry that I use: [v1.0.1] Registry: A lightweight, type-safe module management system for Roblox
2 Likes
Exploits don’t create Script Instances to execute code, and most GUIs will either be in CoreGui, the exploits hidden GUI env or use the exploits Drawing API.
Deleting scripts doesn’t really do anything. If they are running you can find them one way or another.
The only exploits that really harm the game for players are those that manipulate the player’s character. Since every client has network ownership of their own character there’s nothing you can really do. Until server authority comes out.
In the mean time you could create your own character movement system instead of using roblox’s default one if you’re that bothered.
The answer is actually depends the exploit, I was talking more-so with my experience especially as someone who used to create such form of exploits pre-byfron. The point of the registry I was discussing was (and I didnt really bother stating) is anti-save instance for client-side scripts. As for the case of still running the thing with the registry system is that those scripts become 10x more difficult to find as they literally are turned into strictly a meta data table within a script that doesn’t exist to the explorer or in-game instance outside of prior replication.
Either way I completely get the point your making; it’s just never been an issue in my case as I was suggesting one of my forms of enforcement.
The wall can always be broken, it’s just a question how reinforced you make it.
2 Likes
I know some people will disagree with me here, but in all seriousness the most important thing to do is ensure enforcement against exploiting; as there always is a crack in the wall if your game is scaled enough.
Votekick systems and Buckets are your friends, having checks also on certain functions for abnormal behavior helps obviously.
2 Likes
But a good exploiter can simply delete your clientside “scanner” script.
There are a lot of injection script detections out there, all you have to do is search “anti” in the search bar.
If you’re planning to use any of those, I highly recommend digging into how they work and reading through replies and disclaimers since they can use methods (i.e., memory spike checks) that carry risk to detecting innocent players. If so, you shouldn’t risk using it then.
Also a caveat, since these resources are out online, exploit developers are bound to find and patch those methods, which is why most solutions from at most 1 year ago would’ve been patched by now. You should consider whether it’s worth the effort.
Overall, me (and many others) would say client-sided anti-cheats are not worth it, but it’s always good to research deepen your understanding of how exploits work. And maybe you’ll even come up with your own patches. Just don’t forget that the most important thing of all is sever-sided security.
I never use scanner scripts personally; they sometimes work though; I was just giving an example. As I said, layered security is always the answer.
Also as I mentioned previously best-practice is to have the least amount of access-points for them to access, hence the whole registry thing I was talking about.
Hence why I mentioned the whole votekick point – you never will be able to make a perfect anti-cheat, but you can use slaves players as itself a layer of enforcement.
Depends; for enforcement not at all; as part of a layer of detection yes. It’s the client that sends requests to the server, so having it pass flags even if a person can disable them at-least handles lower-level exploiters.
This is probably the most important point; especially since most exploits deal with character, and lag-spikes are bound to happen.
eventually some actual exploiter is gonna write a script that just deletes these anticheats for script kiddies to abuse. Anyway it does actually kinda discourage many exploiters tho.
That’s the point everyone else has made. Again as said 5x so far; it’s about 500 wooden walls instead of putting full trust in a single brick wall. Both are able to be knocked down; it’s just you want to make it as annoying as possible with layering.
The brick-wall I’ve presented now about 2x is simply trusting in player moderation through vote-kicking systems.
you can’t really just rely on players to take responsiblity for exploiters. most roblox players are just children wanting quick dopamine and not trying to moderate. Again, I do kind of support your idea of making it annoying to exploit, as it does discourage many exploiters.
oh wait do you mean that the brick wall is unreliable. im kinda confused wether ur supporting the player moderation idea or not
I’m not saying entirely relying on that; I’m making a statement that all of it is required. Thinking just on handling exploiters on the game-side only is able to run as far as your checks are able to handle.
I think the way to think of it is like this:
The low-level checks (client-side anti-cheats, injection checks, etc) are to catch and kick the 5-dollah exploit client; the stuff kids get to get an ‘advantage’ ingame.
The annoyance factor (obfuscation, registry, etc) prevent a person from being able to walk off with your hard work in terms of client-side code. That and to discourage someone who has medium-experience from continuing to make attempts.
The server-level checks should be used more-so for calls through network; checking character simulation has to be extra lenient to void false-positives. This is where the issue of server-authority comes in.
These together won’t stop every single exploiter, which is why you then move to the player level
Votekicking and Modcalls are the player-side, player moderation has it’s flaws; however, it’s your last line of defense if the game itself cannot detect someone exploiting.
2 Likes
Yes unfortunately when your game has some reason to exploit, someone will be determined to write tools for the public to exploit with ease, and probably will make a few bucks. I believe pouring valuable dev time on anticheats is pointless in the end, I hope Roblox rolls out a working server authority system soon.
i was talking about client sided anti-exploits deterring away skids. you should actually spend time on making antiexploits; you dont want ur game to be easily ruined by exploiters.
1 Like