“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
This is true I guess but diffie-hellman is easy to put in place and it at least slows down anyone inexperienced.
I’d consider it more of a minor inconvenience. Exploits have features to hook and override lua methods, so it would be trivial to bypass most likely.
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:
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.
Big thanks to @Sebastian_Wilson for this.
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
Pretty much why it’s a bad idea. It’s only worth it when:
The time taken to implement / maintain the security feature is considerably (orders of magnitude) less than it takes to break it.
There is a minimal efficiency tradeoff
Very tricky to develop client-side security matching both criteria.
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.
The one I was experimenting with a few months ago to try and block it, was achieved through the use of BodyMovers.
Oh lol. Never seen a noclip that does that.
How do they even work - the ones that don’t use bodymovers.
Some change the HumanoidState to StrafingNoPhysics or just make all the parts in workspace non-cancollide (something like that)
(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)
Some change your humanoid state to StrafingNoPhysics, other ones set all your body parts CanCollide to false in a RenderStepped loop, and some just change the CanCollide of every part you touch to false.
So when I have a local script running an infinite loop does that mean that script can’t be modified? I have a custom camera script with :BindToRenderStep(). The script basicly never stop executing does this mean that all the hacker can do is change variables? Because if so why don’t we just put a while loop at the end of each script so the hacker can’t modify it?
No, it can’t. Their machine = their terms. Anything on their client can be modified and manipulated.
ModuleScripts return something, they do not run code. The code is ran on the code that required it, meaning they can be disabled if you disable the code that runs it.
The limits are still practically non-existent. A competent exploiter can manipulate practically anything on their client.
All data of a Lua proto can be modified at runtime. Code is not an exception.