while true do end can be hijacked. It’s just easier to kill the script.
Security through obscurity never works.
These are all terrible ideas.
Script obfuscation makes it annoying to debug in general, but if your obfuscation is just renaming variables it doesn’t make it any harder at all for an exploiter.
“Network keys” are useless. Hackers can read remote traffic and it’s trivial to decrypt. Even worse, most implementations harm bandwidth for real users.
If you’re talking about context level elevation, exploits haven’t changed the global script environment since 2014/2015.
Hackers can still just detour the methods you use in the end. You’re just making execution slow for the actual good guys.
Don’t do security through obscurity. It doesn’t matter at all if people can read your client scripts if you secure the server.
You can in theory. Clients have full access to their computer and to the Lua environment. Not through Lua, but through manipulation of the Lua/C++ bridge you can hijack while loops.
the lua api doesnt really allow for that. it wouldnt really be possible to do it on roblox due to the fact that you cant edit/hook lua on the client (memory checker)
I created a messy module a while back which uses the diffie-hellman key exchange to create a key, encrypt a localscript’s code on the server, and pass the code to the client for use with a lua VM… Looking back on it it really isn’t that secure but RSA or the diffie-hellman key exchange might be useful for encrypting remotes quickly and safely.
Here’s the module but I wouldn’t recommend using it the way it is since it’s completely insecure. The only valuable part might be the actual key exchange logic.
“Encrypting” remotes is completely useless due to the fact remote traffic can be sniffed and client scripts can be decompiled to figure out what they do.
Lua VM obfuscation can also be reversed pretty easy if you have a good understanding of how they work in the first place
The best way to prevent exploiters would be to optimize your sever side checks. I don’t see any reason checking 5 players once a second should cause any lag, even checking no clip on large maps. Do you have benchmarks and evaluated what is causing your performance issues? Perhaps we could help you solve some of those issues.
Diffie-hellman only actually works when your client’s memory isn’t free for the taking. Without that guarantee, it’s exactly the same as other forms of encryption.
When creating games I always use these methods to prevent exploiting. They don’t prevent all exploits, but the vast majority of them.
Never trust the client. All information being sent from the client to the server must go throught several checks to make sure it’s possible to do and won’t ruin the game for all the other players.
Run a while wait(1) do loop on the server and check if a player is spamming a remote. If so, kick them or something. I honestly don’t know what you’d prefer to do, but I’d kick them.
Create your own anti-exploit which patches speed hacks, noclipping and similar exploits.
I recommend doing server & client checks, even though quite a few people are against client-sided checks.
Pros and cons of both:
Client
Able to detect any changes done to the player’s character directly
Able to put the killswitch on any exploiters before they even begin to exploit. The moment an unauthorized object enters the CoreGui, that player is instantly kicked ( this should be a built in feature in my opinion )
Detect changes in the client-workspace that isn’t present in the server workspace ( player deletes a wall to walk through it. )
ESP and aimbots are easily patchable through the use of CoreGui detection
Cons
Exploiters who know what they’re doing can kill off the anti-exploit, though this can be avoided with multiple checks in all of your client scripts.
Server-Sided Checks
Pros
Very secure
Unable to be broken by any exploiter, so long as vulnerabilities are patched
Cons
Can be very expensive
Not always able to stop an exploiter as soon as they begin
ESPs, NoClip, Speed, and Aimbot cannot be as easily patched without false positives
Very annoying for players who already have a hard enough time with lag, so they’re constantly shot back with “rubberbanding” due to false positives
All in all, both have their pros and cons, and I prefer using both because Client-Sided checks give you that tiny bit more of security that could potentially stop hundreds of exploits, and Server side checks for those few people who are actually experienced with exploiting.
You can refer to this to get an understanding of how detecting exploit kits in CoreGuis works.
Ehhh. I really disagree with your weighting of the pros / cons. From what you have put, it sounds like Client-Side security is more effective than server-side sanity checks.
Exploiters who know what they’re doing can kill off the anti-exploit, though this can be avoided with multiple checks in all of your client scripts.
Can’t be avoided. They can literally disable the script, lie about data to the server, anything they want. It’s their client and you cannot stop them from modifying any part of your client code or netcode.
If I spent so much time obfuscating and thinking of ways to stop every possible exploit on the client then I don’t think I’d have any time to actually make games lol
In a way, it is more effective at stopping exploits before they even have a chance of starting, and they also don’t have to rely on hacky methods to detect certain exploits, unless you want to count detecting coregui elements that aren’t authorized, in which case, you do have to use a pretty hacky method to detect.
For example, noclip is very easy to pick up on because of the use of bodymovers, that are usually inserted into the player’s primarypart. Walkspeed is also considerably easier to detect on the client due to there not being a barrier between the Server & Client which fails to stop speedhacks in the first place.
I was also referring to writing your code securely on the server with remote events and stuff like that. It would be much harder to write an effective server-sided anti-exploit since you have to do constant checks, potentially making the experience for players much worse than it actually needs to be.
