Summary:
Basically, a lot of exploit engines can use the FireTouchInterest() event to spoof the server to think that a player is touching it. However, that player is nowhere near the object. Even if the script is on the server. It’s one thing if this was just firing on the client - this has a server-sided effect too.
Now, I immediately went into a search for alternative options and I tried everything, from Raycasts, Shapecasts, Spherecasts and Regions. Although it fixes the issue, players are not satisfied - the combat tools have a different vibe and just don’t act the same like the tool that has a .Touched event.
Sometimes taking a risk of modifying your tools’ systems can be for the better, but there’s a catch to this - nobody likes it and the community will just move over to somewhere else. To note - this is not a new community, it’s from 2016. If it was a new community in question, I would immediately resort to modern tech.
I’ve tried making anticheats, but they just cannot detect something of this sort. Even if Raycasts are used as a back check, some hits just don’t get registered and it’s just not worth the pain.
.Touched event has had plenty of issues in the past few years and that is why I wanted to submit this bug report - something needs to be done about it. As much as I understand that .Touched is mostly not used in big titles, it shouldn’t just be left unfixed for years without any progress.
Replication:
Use any exploiting software that allows the user access to the engine. Fire a TouchInterest() event - it will result in with the part/player registering that it did touch something even if a user is not near it.
System information:
Universal - this happens to any device that can support exploit injectors.
Expected behavior
.Touched event should only fire if the part/player is touching something, but needs to respect the bounds of the client side of the server and the server itself. If a .Touched event script is server-sided, the client should not have the ability to fire the FireTouchInterest() locally and have it register on the server - giving them the ability to spoof the system.
What if the exploiter just teleports themself to the part that needs to be touched? I would be a little more worried about the fact that there seems to be no other checks in place to make sure the player can actually trigger this Touched event and be awarded something.
I’m uncertain of your specific use-case but racing games, for example, have checkpoints and frequent velocity sanity checks to ensure (to the best of their ability) that the player is not cheating.
Roblox is obviously aware of this issue and if the patch was easy, trust me, it would be out by now I’m presuming this report will not receive any significant attention from engineers
As for teleportation, we have detections in place. However, this post is mainly regarding combat tools. If this was a new community in mind, I would make the tools using the new tech. But changing to Raycasts, etc. just makes them not want to interact with it. Not cause of the cheating then being obsolete, but for the sole fact that the tool feels different.
I mean yeah, I know, but then this should be something that’s constantly in the back of the line rather than being completely ignored. What’s the point of .Touched even existing then if a security vulnerability can’t be looked into?
In that case, just remove it - simple as that. Then, players won’t have a choice and would just be forced to adapt. Even easier for all of us in that case.
Hi, thanks for bringing this up! As the other developer mentioned, this is something on our radar, and we’ll definitely be working on a more secure way to trigger touch events.
In the meantime, would you mind trying LocalSimulationTouched and StoppedTouching? These are the equivalents of Touched and TouchEnded, with the main difference being that the engine doesn’t replicate the events. If you set this up on the server, it should validate the local touch event that occurs on the server. Please let me know if you encounter any issues with this. Thanks!