Exploiters are able to trigger .touched events on other players

Bug Reports Engine Bugs
#13

its already 2 month and this have not been fixed, exploiters can still fire touch interest.
Also from searching I found out that exploits have a special function firetouchinterest which if you specify the root part and the part to touch, it will fire a fake .Touched event which the thing you specified

#14

Exploiters can teleport unanchored parts (Because you can gain Network Ownership of them, when you gain Network Ownership, your client can move that part that you have Network Ownership of), Here are 2 solutions I thought of:

You constantly set the Network Ownership of those parts to nil, or you just anchor the parts.

#15

This is starting to occur once again. Please, guys, get it together! Many community-based groups that rely on these types of things are unable to function properly (competitive games) as not all things can replace .Touched.

I’ve personally tried looking into various alternatives on how .Touched could be replaced with a coded alternative, but it just doesn’t work the same way.

Exploiters have access to manipulating this event in the best way possible and there really is no way to prevent it in most cases.

1 Like
#16

Make a check on the server-side of the part.Touched detection tha checks the distance between the player and part.

#17

Did you not read the replies???

1 Like
#18

Not entirely, I was just trying to help. Next time I will be more thorough.

#19

One way you can go about solve the vulernability of Touched events by simply performing a simple geometry check on the server by Workspace:GetPartsInParts and check if the “hitbox” is touching the valid target, once the event fires.

My reply to this thread I replied to demonstrates how to use this new method. Please do note the following problems with the approach I’ve quoted down below:

2 Likes
#20

This is great! Is it recommended to be used in purpose of auto-kicking a player if no parts have been registered by GetPartsInPart() or can it also affect people with lesser/laggier performance that aren’t perhaps using the cheat?

#21

There is no point in kicking the player if you already effectively mitigate the exploit.

#22

*not kicking, I meant giving me some sort of detection input

For smaller ranges, it effectively mitigates the exploit, but for higher ranges, I also want to send out a notification to myself out of the game to keep an eye on them in the future (as it’s not meant to be a public playable game, but is a group-related competitive community)

Is it recommended to send out notifications if the player has a lesser/laggier performance?

#23

I would recommend to implement a system to notify your self, only if the player has been registered multiple times (5 is a good amount). It is definitely not wise to notify your self as soon as one does not pass the GetPartsInParts check, in order to avoid false positives in a rare case with this check.

2 Likes
#24

It would not necessarily be rare per-se. It’s highly possible for a player in America to be playing on an Asian server or something, and then have 300 ping.

Doing a precise geometric check on the server will not register any of this players hits if the opponent in question is actively moving. As the server’s idea of where the opponent is and where the player’s sword is will be way off depending on the ping.

Also keep in mind that this check really doesn’t prevent very much; while it is a good practice, exploiters are still able to just teleport themselves behind you and hit you that way. And even if you had an anti-teleport, they could simply tween themselves to you.

This is a really bad game of cat and mouse, but it’d be also best if you didn’t cripple genuine players that have bad replication lag in pursuit of trying to mitigate this.

1 Like
#25

Back at this;

This is such a great solution, but I came across the fact that it still gives false positives when the person swings the tool at someone while moving/rotating fast.

I just wish Roblox would do something about this; I’ve tried your idea and I even recoded the tool with Raycasts, but none of them did their thing.

I’m frustrated; I own a competitive-based group and came across the realization that some people are using this exploit to get ahead of others.

#26

Yup - this check does indeed have problems. In the light of Gojinhan’s response, I’ve edited my original reply to point out most of the problems with my approach in detail.

#27

@Khanovich Could you please forward this up to engineers again? I rarely get a response in the Engine Bugs category, so I tend to mention any staff members who noticed this issue.

It’s not about the fact that “developers should focus toward better solutions such as Region3, Raycasting and Magnitude”; this issue has made me recode my tools with all 3 solutions mentioned as they’re considered “the best”, yet are unsuccessful/underperforming due to the server’s responsiveness time.

I have tried EVERYTHING (not just me, plenty of other developers have tried EVERYTHING), yet it has proven to be unsuccessful. .Touched is the way to go and is the standard for all basic tools and their basic needs. It shouldn’t just be pushed to the side cause there are other alternatives - it should be prioritized.

I own a competitive community group which has recently had a spike in number of cheaters who are using this form of exploit which technically can’t be detected cause any alternatives/solutions are not 100% precise and can result in with fake detections.

Please, give this thread more attention. It is critical and requires a fix.

1 Like
#28

This is a solved problem in multiplayer networking: predict actions on the client but validate them on the server. It looks like you only implemented the validation part and haven’t yet done the prediction part.

An example is this:

  • User picks up a coin.
  • On their client, immediately render the coin being picked up (effects and such, increase coin counter) and hide it, send a message to the server that you want to pick up the coin.
  • Server validates and removes the coin from registry and adds it to player inventory.
  • If valid, all is good, user got immediate feedback and the action was performed.
  • If not valid, tell the client it was wrong and the correct state for the client and/or have the client revert the action and put the coin back where it was.

You can apply the idea above to any other networked game concept such as firing projectiles, damage/hit/kill indicators, etc.

You are fundamentally never going to solve this problem with just using Touched because physics ownership is distributed. It’s fine to ask for a fix, but that won’t solve issues related to validation because you’re still using physics. You will always need to protect against issues like this with server-side validation.

2 Likes
#29

The thing is, I even tried using Raycasts, Region3 and Magnitude, but none of them seem to work except Raycasts (which are delayed and sometimes don’t detect hits on touch).

#30

Is this patched or is it still exploitable?

#31

Unfortunately, yes, Touched events are still client-controlled even if the BasePart is completely anchored. I’ve just completely abandoned using Touched events in favor of custom implementations and accepted the overhead of polling the SpatialQuery API because it’s clear this behavior isn’t going to change anytime soon.

1 Like
#33

Any update in regards to when a patch for this behaviour will be delivered?