Basically, players are able to modify their character’s CanTouch properties on their client’s side. By doing that, they also reflect those properties immediately to the server as well. That way, they can negate all incoming damage or disrupt specific players from interacting with world-based objects.
Now, obviously, the first thing that comes into everyone’s head is: “Create a PropertyChangedSignal detection when a player changes their avatar’s CanTouch properties as an anticheat”. Very simple, and it works. And that’s exactly what I did.
The problem now is: this easily fires in Studio and detects the change. It’s not a script issue either - everyone can easily code a detection of this type with a few simple lines. The main problem is when this is Live-Tested by others - the parts that get their CanTouch property altered on the client side do not send a PropertyChangedSignal (and yes, they didn’t delete the anticheat scripts).
Expected behavior
What should be happening:
Player changes their body part’s CanTouch property through an injector in a Live-Server
As the CanTouch property is changed, it should respond to the GetPropertyChangedSignal on the client side of the anticheat
The anticheat should then do its part
What is happening:
Player changes their body part’s CanTouch property through an injector in a Live-Server
As the CanTouch property is changed, it does not respond to the GetPropertyChangedSignal on the client side
The anticheat cannot detect a signal change and can’t do the follow-up steps
The client fully controls their .Touched events on all parts they have network ownership over.
CanTouch does not replicate to the server, but .Touched events are replicated by the client so turning it off clientside will prevent .Touched from firing to the server.
This seems to be 100% intentional behavior and if you rely on it this heavily you might need to look into alternatives that don’t replicate like this.
This isn’t about what the client can control and that’s not the point of the thread - it’s about the fact that the change itself isn’t firing a PropertyChangedSignal event. An event that’s meant to register a change, whether it be done on client or server.
Plus, PropertyChangedSignal is a part of many other things. Just cause this thread is about the CanTouch property doesn’t make it any less important. It’s a flaw that needs to be corrected.
I don’t want to hear these common excuses for the 1.000th time about “looking into alternatives”. With all due respect, please read the thread entirely before replying.
With all due respect, you completely missed the mark.
The anticheat focuses on Client’s detection changes. It WORKS in Studio, but not on Live-Server when an exploiter injects it. Not a local script that’s already pre-set into the game. And that is the main point of this thread - so it can be fixed. Not the CanTouch itself, but the property’s signal change.
No matter if this thread was titled any different (example: Value’s property changing instead of CanTouch), it still focuses on something you completely missed - PropertyChangedSignal.
CanTouch has its flaws, and I understand, but this isn’t about CanTouch needing to be “exploit-proof” - this is about its property changing and not firing a signal. Something that it should do.
Maybe you could go to that DevForum category and help some people out, aye?
Now, allow the engineering team to rather look into this post and decide on what to do themselves instead of bumping it up without even reading the thread properly. Thanks!
Please let me understand, is your point that executors aren’t firing property change events? I don’t think Roblox can do much about what executors are doing (lol) and executors probably don’t want you to detect them anyway.
(If you somehow are referring to some bizarre exploit functions that modify memory directly then those will never, and can never fire .Changed or :GetPropertyChangedSignal())
(If the scripts in question are hooking onto metamethods then you will just have to fight against the exploiters like everyone else does :p)
How do you know that this isn’t an intentional anti-patch by exploit developers? This behaviour is also present intentionally in other parts of the engine, such as CFrame not firing any signals when the Physics engine changes it, or BulkMoveTo’s entire purpose being to improve the speed of moving many Parts by not doing so as well, so maybe the executors are leveraging the same signal optimization to prevent developers from detecting property changes.
Exploits can simply set the underlying memory values and bypass the entire reflection system if they wanted to. Roblox’s event system is not based on constantly checking if underlying memory changed as far as I am aware, otherwise the intentional behaviours I mentioned wouldn’t make sense
Maybe the REAL bug here is that the Server is incorrectly allowing the Client to replicate Touched events for Parts that are not CanTouch on the Server
I contacted Bitdancer today about this issue before this bug report was made as I noticed touch transmitters are completely compromised from both the client and the server side by exploits so hopefully he sees my message and fixes it properly because trying to detect injection is not the right way to patch exploiting and I explained that thoroughly in my message
Well sort of good news I guess lol. I discovered a new way to prevent exploiters from negating all incoming damage. All you have to do is loop trigger the touched event from a separate character by loop cloning a separate character and teleporting it to the damage part
(I tested it thoroughly it must be a real character such as a Noob NPC for it to work but you can simply make the Noob completely invisible by setting all of its descendants to transparency 1 as well as the can collide setting to false and only keeping CanTouch enabled to make it look 100% realistic).
It causes the exploiter to die even when they delete the part as well as the touch interest. I hope this helps
That’s possibly one of the most inefficient ways to do it.
Have the attacker be the network owner of the hitbox or just use spatial queries. If you really want to use Touched events tied to the network owner of the character, attach a server only part (parented to CurrentCamera on server) to them or something.
Nonetheless, players being able to control Touched events on parts they own is not a bug.
Can confirm though, :GetPropertyChangedSignal() for CanTouch does not work, but the general .Changed signal does fire for it. OP should make the post clearer to state that.
Yeah, my next plan was to make a damage rig on the server rather than the client. I’m going to try that as an alternative.
As for SpatialQueries, I did try various methods. However, the combat tool just feels vastly different than the original and the community doesn’t want to adapt to the changes. That’s the main issue.
In the past, I did try to see if the .Touched event could be looked into by the engineers to have some sort of a security patch in terms of its vulnerabilities, but most of the people said it was intentional behaviour (since .Touched has been on the platform for quite some time). That’s why I made the post about CanTouch now, since it mainly focuses on its signal not firing rather than it as a whole, but is relatively a new feature on the platform still.
I’m going to try that as well, not sure how much it’ll affect performance however. Fingers crossed it doesn’t cause lag.
I’ll look into this as well, but how would this affect performance? It sounds as it would be very performance-costy.
Roblox Studio just recently made a change to the minimum device requirements to be able to use it. I would imagine Roblox over time is going to do the same. Your Roblox should function just fine regardless of what the performance cost is as long as you have a good device. The character can be extremely tiny to the point that you can hardly even see it on the screen and you are making it invisible. You are also able to set all of its properties to massless because it’s just being used to trigger it. If you follow those steps I would imagine the performance cost being quite small. Roblox is meant to be able to handle loops with a cheap performance cost. The person I have muted who keeps replying to me doesn’t understand basics of server sided performance cost. It is not expensive to clone characters in fact every tower defense game you’ve ever played allows you to clone towers into the workspace. Repeatedly putting down a tower in a tower defense game has never been a costly thing to do. So neither is this. Especially not when you follow the steps to minimize it.
Read network ownership carefully. Cheaters can replicate (or not replicate) touches however they please for parts they own. They don’t have to use the CanTouch property to change this behavior, and cheaters can also change properties on their clients without firing any signals and do so almost always without replication.
Make sure you are setting CanTouch appropriately from the server on at least one of the parts to prevent cheaters from abusing touches. This property cannot be changed on the server side with cheats. If you are listening to Touched on the client side, keep in mind that this is untrustworthy since cheaters can fire (or not fire) any events they choose for their own clients.
We are working on a server authoritative model which will address concerns like these, so stay tuned for that.
