Anti-Exploit Ideas

Hi, so I got many hackers in-game, can someone give me ideas for the anti-exploit (like what to add)

1 Like

No point for btooling, filter enabled already fixed that issue. It’s now client sided.

What is your game genre?

1 Like

How this will affect on anti-exploit?

Because if your game isn’t fighting based then you won’t have to worry about hitbox expanding and resizing of weapons. It’s best to see what the genre of your game is, then find what can hurt the game.

Oh, ok. My game genre is fighting.

1 Like

Hitbox expanding, teleporting, resizing and flying is most common for fighting games.

I never had something like this.

Ok so BTools you can easily just check the players backpack for a tool named brooks are if your game dosent have. A tool,kick the player for having a tool,if ur characters walk speed dosent change in the game just say I’d the walk speed is greater than 17 than kick player

1 Like

This is the same thing for JumpPower,if it’s over a certain number kick the player

1 Like

I already use this, just i need more ideas to anti exploit.

You’ll mainly want to be monitoring the players distance traveled over a certain period of time. If i move 300 studs within 2 seconds and there is no reason in your game for that to happen then chances are something isn’t right. If my character isn’t on the ground, Isn’t falling and is constantly moving around again, something probably isn’t right. Monitoring things like this on the server could help with walkspeed, teleportation and flying.

The thing about monitoring WalkSpeed and JumpPower is that A lot of exploits don’t even use WalkSpeed and JumpPower to get the desired effects. There is numerous ways to walk faster and jump higher without actually having to touch those properties.

If you are okay with a somewhat unsecure method you can always check on the client to make sure a user isn’t tampering with other characters or their own, the map or their PlayerGui. This is often effective for the pesky people that don’t know what they are doing. Stuff like this should be done after you finished securing your game serverside however.

Important things to check:

  • Teleportation/speed
  • Flying
  • No-clipping (Players going through walls/other assets)

I’ve seen some exploiters changing the Workspace.Gravity property to something really low so they would be able to jump higher and stay in the air for longer. Maybe implement a check for that?

I’m going to be straight to the point here and say client side checks are 99% useless. Imo they aren’t worth the effort and often times they are often bypassed in hours or less if your game is popular. I wrote an article here which may be helpful: How you should secure your game - A beginner guide for secure networking and developing anticheats

It doesn’t cover everything but the main focuses I’d note are:

  1. Use Stepped to check for physics exploits. Stepped is run before physics calculations. Heartbeat is similar, but run after so it’s less useful for preventing exploits since they have 1 frame to trigger physics events and such.
  2. Learn how Velocity, Acceleration, etc work on a basic level. Velocity = studs per second, Acceleration = velocity increase per second.
  3. Humanoids are pretty easy to predict thankfully. Their max Y speed for jumping is equal to their JumpPower, their max X/Z speed is equal to their WalkSpeed.
  4. Know how to detect the difference between expected and unexpected movement (e.g. moving faster/slower than their velocity by a considerable (~2-4 studs) amount, moving in the wrong direction, etc)
  5. Know how to prevent the above (tracking and setting velocity, CFrame, etc)

There are plenty of articles on this type of information and I’d recommend taking a look at CFrame articles, the RunService.Stepped docs, and researching Newtonian physics.

I may incorporate some extra info into my article (e.g. flight detection/prevention) since it’s a common topic.

4 Likes

What if the client checks routinely sent a checksum to the server? If done correctly, that isn’t really hackable, as the server would know precisely when the client physics were altered and when they weren’t.

EDIT: Oh wait. I keep forgetting that Roblox Lua doesn’t allow any pre-compiled bytecode. The source code for this and/or any other clever tricks are 100% viewable by the client, meaning they could easily script inject and forge the checksum with the expected values. Blast!

Fake remote events are largely pointless and don’t solve anything in regards to anti-exploit. They’re a waste of your time as much as they are a waste of an exploiter’s time. Not to mention that you’re now bloating your instance count, memory usage and bandwidth consumption because of this.

Naturally. FilteringEnabled is standard in all games and can’t be disabled; it being enabled is implicit. Probably standard enough now not to call it a FilteringEnabled game and rather just a game on Roblox.