I’m here to write about a topic that has barely been discussed on here, only 1 vague article on “Hitbox Expanding” and other articles that only ask how to prevent it and other exploits but there’s no depth in any of those.
There’s also a ton of misinformation about hitbox expanders, I’ll start off with what it is NOT.
Hitbox Expansion is NOT Aimbot
A lot of developers and fellow Robloxians mistake hitbox expansion as aimbot, this is fundamentally misleading and it makes it very hard to combat this cheat since no one truly knows how to describe it. It doesn’t make you aim better, it doesn’t control your mouse for you.
How Hitbox Expansion Works
It is basically an exploit script that increases the size of another player’s body part (Usually the “Head” or the “HumanoidRootPart”). This is usually seen in gunfighter games, sword games, games that involve damaging another player - basically.
Big Head (Hitbox Expander - seen in Phantom Forces):
How To Prevent/Mitigate:
This one’s tricky since it’ll rely on client-side protection typically to detect if the client is expanding other player’s hitboxes.
You’ll want to get the normal sizes of what each body part should be (or shouldn’t be for this example, {10,10,10} is not {2,2,1} (HRP size).
then check if the client has increased the size of any of these. If they have, then you can punish them either…kicking…or re-sizing it to a tiny hitbox as punishment!
I totally recommend downloading and using PhantomVisual’s PVEye tool, ignore the “hit unexisting target” readings, but if you see a logged line of “Client side = 5,5,5” or something like that, then that’s very likely an increased hitbox. I did a video on how to use it too, it’s a script that is meant to go on your serverscriptservice and you just got to put your name in the admin list of this one.
Welp! That’s a wrap! I hope I helped the community out on this!
No. Nobody ever seems to learn that the client can’t ever be trusted.
Exploiters can quite literally change anything on the client, including script code.
In addition, they can intercept a remote with using getrawmetatable, a method available to users using services like Synapse X.
The simple solution is just to handle damaging instances (such as bullets and melee) on the server. Exploiters can’t touch the server, so it’s automatically and permanently patched.
So in conclusion, this entire topic is misinformation and will harm developers rather than help them.
I guess…another alternative would be to clone a localscript into the player’s Character and run a while loop to make sure all body parts are their correct sizes, and if they get larger, then fire a remoteEvent to the serverscript and punish from there.
Relying on a Server script to ensure the hitbox sizes are not being altered would definitely be a bad idea as latency would result is frequent false positives. In some instances, the reliance of localscripts (for things like renderedstep()) and for optimal monitoring is sometimes unavoidable.
Not a great idea. If the client can change part sizes they can easily disable a script.
I don’t think that’s what was being suggested. The suggestion from @iGottic was to handle whether or not a user gets damaged from the server, a place where the parts are all their correct size. It sounds like you missed the point and still think you should trust the client to tell you when they hit something. You shouldn’t.
Here’s another issue, I’m an active developer, and I do admit I have synapse, HOWEVER, I don’t use it for hacking, I’m making a secure anti-cheat for my game. Things you can do is do any client side, see the script’s contents, and even copy scripts, only thing they can’t do is modify scripts in-game (I believe, haven’t actually tried) and they can’t see stuff under ServerScriptService and I believe ServerStorage. The problem with this solution is that the hacker and simply just delete the script that prevents this, SO, what I propose is a better solution, you can make a LocalScript and name it something weird or sounding like it’s apart of roblox, have it do whatever you want to the hacker when the hitbox changes, but after the entire LocalScript is done loading, you set its own parent to nil, that way they have no way of knowing that that LocalScript exists.
I don’t see the problem with using a LocalScript as one way to prevent this. Like yea, they can disable it, but most exploiters on Roblox are script kiddies and won’t know to do that.
Edit: OH but wait… It does sound like you may be handling your hit detection on the client so nevermind
The script kiddies will just be copying someone else’s script that works for your game. It only takes one person to figure out your script can be deleted before just any old exploiter can do it.
I will be quoting @PhantomVisual from his PVEye module (which is a decent client side Anti HBE and a very good spectate tool) for a possible server side solution:
DEVELOPERS:
I DO NOT RECCOMMEND USING THESE [client side] METHODS TO STOP EXPLOITING
I want to tell you the correct way to actually do it:
Store positions of players on the server with a time stamp
Once someone lands a shot, send the time stamp to the server
The server will compare the shooter’s position and the hitPerson’s position to see if the shot was possible
The server will register the damage based off this information
This wouldn’t help against lagswitches but it’s a good start.
Oh the creator of PVEye…yes his tool actually is very good. It logs both false positives and true HBE cases. If the target hits non-existing target according to his module, then that’s a false positive reading, but if it comes back with telling you what the client-side sizes are, then it’s almost gauranteed to be a HBE.
That method PhantomVisual suggested…would solve HBE but possibly aimbot too. I see he made a good amount of progress in trying to take down aimbot and esp, but gave up because Roblox and the server to client latency was too unreliable to avoid false positives on something that requires a lot of careful precision. + And…no one’s ever implemented what he stated because it’s way too difficult, if there’s at least a simple example out there about a simple gun utilizing his method then aimbot and HBE might be put to rest.
You’re still not getting it. You can’t use the client.
This is a super redundant argument you have going, and have not provided a reason why client would be a good permanent solution. Simply put: there is no reason.
It’s actually very easy to use the server for damage and hitreg without having be super precise. I do this myself in all of my FPS games, and after working out smaller issues, have gotten it to work well. Games like Arsenal and Games Unite also do server-sided hitreg.
It’s blatantly obvious you have no idea what you’re talking about, and the topic has so much misinformation that can harm a game. Many users here including BanTech, rogchamp, and myself have years of experience and we know from that experience that the client can’t be trusted.
As such, it strongly recommend you take down this post.
Footnote: I’m actually the guy you linked in the original post, which is why I’m here in the first place. If you would have read that topic and the replies in detail, I seriously doubt you would have made this post.
Tbh, I know where he’s coming from, though I ain’t sure why there’s this all-or-nothing attitude when it comes to anticheats for some people around these forums. I mean, yes, my solutions aren’t as good but, even as a beginner…I’m able to curb a lot of cheaters, if I stuck with an all-or-nothing type of thinking I mean, the game would be much worse off. Like, it should be about mitigating it first, then developing the complex server-sided hit register checker, you can give yourself time and reduce the number of cheaters and then work on the complex solution.
I think instead of him coming off as superior and advocating for the removal of this post because I can’t give the absolute best way to patch this issue (which there have been 0 posts like this which discuss what hitbox expanding is overall), a better way would be to come to an understanding as to how to get a handle on it for now and then slowly start replacing client-side anticheats with server-side ones to stop it almost completely.
So let me explain what he’s angry about. You, a fairly new scripter from what i can tell from this post, made a post about an important topic, anticheat. Now this topic may mislead some people.
Never promote clientsided anticheat. No matter how safe it is, it can be bypassed.
I pretty much solved this HBE issue (cut down its occurrences by about 90% haven’t heard or seen reports if it anymore, very rare).
I totally liked learning about the hit register thing on the server, though currently gotta get more experience to eventually implement that. In the meantime, I seek to offer an understanding about what this even is since this is a topic that’s barely been talked about in detail - but my less-than-desirable ways of handling it aren’t meant to insult the better initiated here.
In the end, I hope to have given everyone a better idea as to what this is as a whole and clear up common misconceptions.
@ScripterWaffle Whoops, my bad. I’ll keep my mouth shut for that
@Matrice I should clear up that I’m not angry here; text, even with formatting, makes it hard to deliver a proper tone. Hope you can understand
I’ll make a post in the near future about HBE prevention, anti-fly, anti-humanoid-changes, verification and more. The post will also include a free anti-exploit script to stop some of these, using a method called “network rubberbanding.”
Ah? Then good! Please fell free to link to here if you want! Hey, I did do a good job visually showing what this is and explaining it at the least. This is a topic that people been asking about that the dev site doesn’t talk about, no one out there talks about proper or the best HBE prevention.
Yeah network rubberbanding…so I guess 1 idea I had for that was getting the pings of the client, then use that to exclude pings above 450 where false positives would happen at.
yeah, anything client sided regardless of the effort you put into making it secure can be exploited. there is a solution to every problem and even through the use of remote events, plugins, or whatever, data has to be sent from the client to the server and that can be modified through script injectors (synapse or other stupid exploits). hence, you can limit the mindless script kiddies (people who copy other scripts and paste them hoping they work on the game) and slow down the people who are actively trying to harm your game (by hbe or whatever else they can find). (also, try not to use so many while true loops with a wait, they’re not that efficient and they should be used sparingly because they can eat up the memory of the client and we never know what the client’s computer can handle, try using a chain of quick remote events of a server-sided function call. also, try to randomize your kicks or bans to a minute or five seconds you detect them cheating so it would be more difficult to figure out the fine line to not getting caught).
But exploiters can’t change other player’s body parts’ size on the server side, right? Or am I missing something. I thought they could only change things client side and it wouldn’t replicate to the server.
so nevermind
I mean, yes, my solutions aren’t as good but, even as a beginner…I’m able to curb a lot of cheaters, if I stuck with an all-or-nothing type of thinking I mean, the game would be much worse off. Like, it should be about mitigating it first, then developing the complex server-sided hit register checker, you can give yourself time and reduce the number of cheaters and then work on the complex solution.