Hackers can fire remotes containing fake positions to gain points, how do i fix this?

That would be an aimbot. An aimbot is basically artificial good aim.

You can’t do much to fix it. Telling a legitimate headshot from an aimbotted one is gonna be very difficult, and even more difficult since the mouse position is from the client. You can add bullet drop and bullet spread to help relieve this.

EDIT: you can instead count how many headshots in a row the player has made. If there are too many, you could flag them as a potential exploiter. Though this can result in false-positives. Some players just do have real good aim. And a player can also have tons of headshots in a row with a lot of time in between each hit.

Could you explain please? Take your time :slight_smile:

If they are getting a headshot every time they fire the weapon, you can determine they are an exploiter. It is safe to assume that literally nobody is good enough to get a headshot every single time they shoot the weapon.

I say every time they fire the weapon instead of every time they fire a bullet, because in the event that they are shooting an automatic weapon, they may miss a couple times.

There are ways to get around this, but it should get rid of most aimbotters.

Basically you wanna check if the player’s/gun fire location is the same on the server script, using magnitude to compare the positions fired from the event.

I think he means that the players are shooting from a different area that’s not coming from the gun. If you get what I meant.

He said that the exploiters are changing the mouse.Hit position for a players head position. This is swapping the end goal, not the origin of fire.

1 Like

Found a good post from my research

https://devforum.roblox.com/t/anti-aimbot-methods/24528/12

@KeysOfFate so I can be considered an exploiter if I headshot an idle player for the entire clip

I think detecting if hackers are doing too much headshots is not a good idea, because maybe a pro player can get kicked from the server because… he is too good.

You can check if the player that was shot is moving / or has recently moved.

And if they are moving slowly for whatever reason? There would be a lot to account for for little benefit. If you check out the post I linked, it gives good ideas on what to add to the gun (like bullet drop as I mentioned in my first post) so that aim bot won’t always work well

If the player is afk, it would make sense to place them in a safe zone or a character container when they are killed, until they decide to play again / re-deploy. They shouldn’t be moving at all.

@KeysOfFate, @sjr04 - Well, those are more like tricks and small hacks to get rid of some hackers, the problem of that is that it can affect gameplay, the gun is designed to be fast, maybe like a sniper. I want to keep a simple gameplay.

Then there is not much to do. Aimbots are often client-sided, and as you know, you can’t fully secure the client. You can just continue searching for tricks to mitigate aimbot.

https://devforum.roblox.com/search?q=anti%20aimbot

If your projectiles travel instantaneously, your solution will have to be incredibly complex. At that scenario, my approach would be to take the client’s information about orientation, last mouse movement, etc. and try and interpret if the movements made to connect the headshot (or any shot) were sensical.

If your projectiles travel based on a parametric equation, then you will have a much easier time, since you can judge the time taken for the projectile to move in order to determine if the client has moved their projectile realistically.

You could always go more complex; you could make your own aimbot, and use something like a Neural Network Library on Roblox . Feed it fabricated aimbot scenarios and let it judge the player. Personally I don’t think this approach is very practical because it will not be capable of handling new aimbot systems developed for your game. But it is a neat concept.

1 Like

Although plently of people have explained before, preventing aim-bot can be very trivial and at times, bad for user-experience. If you have a player who dedicates their time to improving aim, it can begin to look alot like aimbot even to a normal person let alone a bot or script:

Weird but ok example:

If you want to try to prevent this as best as you can, you can detect over the top speed/rotational movements in the body/camera though do be warned as they can manipulate it if you’re not careful.

Basically, check overkill movements, it will always be because of a certain exploit however if you want to be on the safe side, kick them, dont ban them. Of course, have a warning system that checks how many times they’ve been kicked, if alot, ban. Glitches and accidents can occur and you should be ready to combat those issues.

Only “real” way of preventing aim-bot as of now would just to be to rely on vote-kick systems and although hacky and could lead to false kicks, it is, imo, much better than writing complicated code that could lead to worst failure rates of just checking aim-bot. Anything that is done on the client, cameras, rotation, movement, can all and always be manipulated by the client no matter how hard you try, yes you can write a custom humanoid, yes you can do nearly everything on the server, no you can cannot always find a firm way to prevent it.

I’m fairly certain that the only way to prevent exploiters from firing RemoteEvents at will, is to make checks on the server, like the server will check if the position is real. Not sure how you’d go by it, but yeah.

What do you mean with that? I thought about Checks on the server, but i didn’t know how i could do it.


@3rdhoan123 - I don’t think this requires camera rotation, i’m not talking about FPS aimbot where the camera is automatically aiming players, i meant about normal guns in a normal character/camera, where hackers can fire an event with the position of the head. And also they can shoot between walls.


@Pavalineox - Could you explain:

?

@Conejin_Alt

Then I firmly believe this is an issue with your code, make sure you’re doing proper raycast checks on the server as always to confirm possible shooting positions and issues, if a ray is going through the wall somehow, correct it on the server to prevent damage being done. DO NOT handle remote events/important events on the client NEVER trust the client, zilch. (unless the remotes are just for visual purposes in which case I think its fine :man_shrugging:)

If they’re teleporting heads towards them to shoot at, verify their magnitude, ray possibles from gun to character, if its literally impossible, ban, you know for a sure fact that it’ll be impossible to shoot from within a room to the literal border.

It’s the same logic that those “I’m not a robot” boxes use; You’d just want to know what they were doing before the gunshot that you are checking.

If they make a sudden and very large mouse movement (say, 120 pixels in one frame) onto the target player, and then shoot, then that could be a red flag, for example. A normal player would have relatively smooth acceleration and deceleration of their mouse.

Theres many ways to combat this form of hacking. Most solutions will not prevent the problem entirely, but may make a hackers job harder.

Server vote kick regulation

You might find it useful in implementing a server kick feature, where a server can vote to kick players that may be playing unfairly.

Real world variables

You can also add in real world variables on the server. Apply gravity, and spread to the bullet with a very small delay in between fire and impact.

Ignore bot-like precision

If that position provided hits a player, you might try to compare it with the hit object’s position. If they are within a certain bounds of similarity, then ignore the bullet. Most shots will not be on the level of precision as a bot.

Add false targets, only hittable by bots, to confuse bots

I might even look into manipulating what the bot targets. A bot will take information given by the client, so if you can forge multiple targets, a bot may try to hit these instead. So say you have 4 invisible targets 5 studs behind the player relative to the clients position and angle. A bot might falsify a fake position because it’s chosen one of those false targets, but you as a developer know that those targets can’t be hit. A player can’t shoot a target behind another object.

Note
With all exploits and attacks, a developer should learn how the attack works to properly defend against it. These are some of the idea’s I’ve had under my impression on how this attack operates, but I have not practiced it, and can’t say for certain if these will be successful counters. So definetly research the attack and how other developers have countered it.

3 Likes