Insights on exploit prevention

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.

14 Likes

You can’t really hijack a while loop, however it is possible to use ScriptContext:SetTimeout to stop it from running.

3 Likes

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.

2 Likes

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)

2 Likes

You absolutely can. Exploits get around the memory checker, because it’s client side security that can always be bypassed.

1 Like

no exploit (free or paid) bypasses the memory checker (currently)

we have found ways to achieve execution without needing it

3 Likes

It’s still possible in theory though, it’s just that nobody does it (like detouring while loops).

What did you mean by “we”? :thinking:

5 Likes

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.

3 Likes

“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

5 Likes

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