Sorry to necropost, but I wanted to correct something:
This can be patched using this simple workaround
It’s not a ‘patch’ - it’s a band-aid solution that’s still exploitable at the end of the day. Exploiters can simply delete TouchInrerest objects the moment they appear, or even yet introduce special methods to not send that information to the server,m - as such I didn’t mention that ‘fix’.
Assuming you are either calling GetTouchingParts on something from the server, or from the client that wants to make hits, I don’t see how an exploiter removing TouchInterest or withholding items from being returned in GetTouchingParts called from their own client would make sense for them. They’d just be denying themselves hits, presuming each client calculates its own hits and the server does some validation on that.
My understanding is GetTouchingParts doesn’t require a TouchInterest in the other part, only in the part you are calling GetTouchingParts on, and if you call it instantly after connecting a Touched handler there is simply no networking involved, it’s purely detecting touches in that single frame on that network node.
I’m no expert on the matter so I can’t really go into detail on what actually goes on, but I believe you’d agree with me on the fact that it still is a band-aid fix.
It’s simply not related to security/exploiting – all that adding a TouchInterest does is making it so non-cancollide parts are picked up by the GetTouchingParts computation. The previous post of yours implied it was related to security, which is what I was responding to.
The band-aid is that you need to add a TouchInterest to get the function to act differently, not that it somehow compromises security more (or less) than if you did not do that. The security model is the same. (don’t trust physics asserted by clients)
In the context of security, I agree, yes. But with how Roblox has been recently, I’d rather not mention solutions that are less steadfast - for instance, with deferred behavior; even though its arguable on whether relying on instant event feedback was weird or not, I still did not rely on such behavior nevertheless because I had a hunch the behavior would change one day or another (which, I was correct on). I remember arguing with people on this matter, though that’s on a now-deleted account so I can’t provide much proof regarding it.
A much better solution to the band-aid Touched fix would be to instead use the newer solution that Roblox is working on, which is meant to supersede Region3 (MaximumADHD’s log showed these being worked on). I’ll likely update this thread once those come out.
I think you’re missing the point or trying to pull of a red herring fallacy here. Let’s go back to the original point you made that I responded to. The “much better” new solution you point out will have the same weakness you pointed out before: just like an exploiter can delete the TouchInterest to manipulate GetTouchingParts results, an exploiter can also manipulate the results of whatever new API Roblox releases for hit detection, by withholding parts returned from such API calls, if done on their client. (they are in full control of their client)
Again, the point here is that you cannot trust physics assertions made by a client. There is no magic API Roblox can release to fix this, and it has nothing to do with the hackiness of adding a TouchInterest to GetTouchingParts.
If you want security, you need to validate assertions made by the client on the server. There is no silver bullet for this problem.
3 Likes