Raycasts and OverlapParams still don't block out Synapse's FireTouchInterest()

I have a competitive group on the website which uses a meele tool system for damaging their opponents. The tool uses .Touched, but I decided to look into alternatives of Raycasts and OverlapParams to prevent it. Although they eliminate un-connected hits for players that aren’t exploiting, that seems to not be the case for exploiters. Basically, it’s like a Uno reverse card. :rofl:

Although Raycasts eliminate .Touched, Synapse is still capable of using FireTouchInterest(), a function that only fires if the part’s script has a .Touched event inside of it, on an object that is using Raycasts.

However, with OverlapParams, they PARTIALLY eliminate Synapse’s ability to damage from afar (example: if Synapse was able to damage from a 40-stud distance before, it can’t now). However, when in closer range, Synapse will somehow manage to damage the player (example: unlike the 40-stud distance, it will start firing from a 3.5 stud distance although the script uses Region3 to check for parts overlapping the tool’s handle).

Tool that detects Region3:
DevForum - Clean tool.rbxm (6.5 KB)

Tool that uses Raycasts:
Tool (Raycasts).rbxm (20.5 KB)

Exploit script example:
reach_damage_visualizer.lua (9.7 KB)

Code is located in tools’ SwordScript.

At this point, especially with Roblox somewhat blocking the ability to detect CoreGui changes that use unofficial Roblox GUIs, I am helpless and out of ideas as people are still able to cheat despite me using various alternatives that are considered “the best” out there.

Any help is appreciated, I really need it.

1 Like

The way you worded your problem was a bit strange, but I am assuming you fixed the long-range synapse exploiting by checking the distance between the player and the hitter on the server? otherwise the exploiter can just extend there hitbox range to accomplish the same effect. The only thing you can really do is add more sanity server checks like that, so checking when a player is allowed to damage another player like comparing there swingrate to the possible swingrate of the weapon, (since if a exploiter is firing a remote per frame to register a hit then you know there exploiting)

1 Like

Although the hitbox thing could be a reason why in real-time plays, I do have detections for hitbox changes. With reliable people who are testing this with us before putting it out live, they were not used.

By the way even if coregui was accessible exploits would just develop a spoofed version of the coregui, remember everything is on the client. Also this would open up vulnerabilities like modifying purchase prompts

1 Like

I’m not sure how you detect for hitbox size changes, but if your doing it locally then exploiters can easily remove that detection, any local detection is unreliable, and you should rely on server sanity checks as your main method of detecting exploits

You can keep the local detection still, I just wouldn’t rely on it since it will only detect dumb exploiters

1 Like

Yeah; that’s why we have sanity checks for that, as you’ve mentioned.

However, it still makes absolutely no sense. Could I send a code here so you could see what’s it about? It should give you a in-depth perspective.

Sure, Although I would update your original posting to include the code since others might be able to help

1 Like

On it!

Here’s file:
DevForum - Clean tool.rbxm (6.5 KB)

Code is in the top of the thread.

Wait; I’ll actually include both tools incase I perhaps did something wrong with Raycasts (which I highly doubt as it works for people without exploits, but is ineffective against exploiters).

Because you’re doing the hit detection on the server there shouldn’t be any way to exploit it at least not with the tool. Are there other scripts that exploiters can use to damage other players?

Or any scripts/remotes that can change the tool?

1 Like

Top of thread updated with proper tools (important code is in SwordScript which is located in the tool).

Probably; however, our partner’s anti-exploit handles those things which is irrelevant for this topic as it doesn’t do any detections for the problem mentioned.

The tool’s damage exploit issue is the only unsolved problem that we currently have hence why the code’s mainly wired in the SwordScript.

I do have the .lua file of the exploit tho, IF that makes a difference.

Well I can tell you that the sword is fine security wise, because you’re doing the detection on the server and not locally. Exploiters cannot manipulate anything on the server so the vulnerbility is most likely a different script/problem

You can send the exploit file if you want and I can take a look at it

1 Like

reach_damage_visualizer.lua (9.7 KB)

This is the script used for changing reach.

Edit: Forgot to add; the damage part of the exploit is detectable and that issue is solved; the reach is what’s the main problem of it.

The fix for detection doesn’t need to be in the tool itself; it can also be on the client/server and I’ll just use Sanity checks. If that gives you more ideas to choose from incase you thought limiting the detector in the tool was the only way to go.

Alright I read it, so all there doing is firing the touch interest when a player is close enough; as I said before as long as you don’t have any local connections or local detection then your sword should have no security issues. I would check with your team if there anything thats local that can be leaked

As far as the sword itself, there no security issue that I found so the leak is most likely outside of the tool

1 Like

Do you mean local as in, for an example:


local object = this

and instead use:

object = that

No, local refers to local script or anything created on the client and not the server, exploiters can change local scripts but they cannot change server scripts

1 Like

As mentioned before, no other scripts are connected to the tool, whether they be local or global. There isn’t a detector script for that as I can’t manage to figure out the best solution for it.

So, it shouldn’t be affected by anything else.

Can’t really help you then its impossible for exploiters to do anything on the server so… either you have a leak that you’re not aware of or its a roblox bug, first option being far more likely since if it was a roblox bug every roblox game would be in chaos right now

1 Like