This is true I guess but diffie-hellman is easy to put in place and it at least slows down anyone inexperienced.
1 Like
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.
2 Likes
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.
3 Likes
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.
2 Likes
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.
2 Likes
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.
Big thanks to @Sebastian_Wilson for this.
11 Likes
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.
2 Likes
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
9 Likes
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.
1 Like
The one I was experimenting with a few months ago to try and block it, was achieved through the use of BodyMovers.
1 Like
Oh lol. Never seen a noclip that does that.
3 Likes
How do they even work - the ones that don’t use bodymovers.
1 Like
Some change the HumanoidState to StrafingNoPhysics or just make all the parts in workspace non-cancollide (something like that)
1 Like
(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)
1 Like
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?
2 Likes
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.
7 Likes
All data of a Lua proto can be modified at runtime. Code is not an exception.
3 Likes
To strengthen what you are saying, let me add some examples.
I have installed a SSL certificate on my machine which allows me to perform a MitM attack on any program performing network requests on my machine over SSL/TLS/HTTPS (like Roblox). I can see and write simple scripts (with the tools I use, in Lua) to replace any values I want. This means that if the client tries to tell the server in any way that I’m misbehaving, I can just edit it transparently without my machine or the server knowing what I did. I can also send any messages I want, duplicate them, or even block them for a time or indefinitely. The server will never know if a local anti-cheat detects anything.
Since Lua is a VM language, editing its memory is easier than a normal compiled program like the engine. The interpreter has a defined (open source, mind you), predictable, and consistent behavior. This makes editing its memory easy. Editing the variables in a script is easy. Since editing variables in a script is easy, controlling its logic is also easy. You see where I’m going with this? I can make any script see anything I want it to see. Since I don’t want to see the bad things I’m doing, I’ll just make it see that I’m not doing anything bad. All client anti-exploits have just been defeated by a single method that is easy to slightly change for every use case.
If I really wanted to mess with things, I’d make it easier by running Roblox on Linux using Wine (Wine Is Not an Emulator, the implementation of windows libraries in linux) and use Linux’s extra freedom to really screw around. All OS functionality can be relatively easily edited to do whatever I want; report on whatever memory or arguments I want it too, and lots more.
I’ve repeatedly told you, and am telling you again along with the two other respectable people above me, client side anti exploits are easily avoided and are only suitable for a quick and dirty emergency patch while a more robust method of prevention is developed.
4 Likes