Are making bait remote events for exploiters worth the trouble?

I plan on doing various things to prevent exploits within my game, but one of them was to use some bait remote events. The idea is to create a remoteevent called something like damage and whoever tries firing the remote event gets instantly banned. Plus to make it less obvious for them of what event banned them. Have it so it doesn’t ban them right away and instead bans them after a random time interval or if they leave before the interval is done. Also after some time I can manually switch the bait event to do functions of a real event and set one of the real events as the bait events if I really wanted to. Of course exploiters can use alts and this doesn’t fully prevent exploiting, but I thought this would make their task much more annoying.

14 Likes

This is a really interesting idea… I think you should go along with it! This should confuse exploiters a lot!

7 Likes

Unfortunately, this doesn’t really help anymore, exploiters always learn and they can just make a brand new account after they get banned after triggering the event and spread the word to other exploiters

4 Likes

Focus on serverside checks. Exploiters can do basically nothing about them. Remember that everything sent to the client, visually displayed or not is visible to exploiters. They can always read your client scripts and see which remote is legitimate as well as view all traffic the scripts are sending/receiving. Serverside checks that make sure the player has the right permissions, interacts with something while actually near the said thing, and/or isn’t performing an action too fast will protect you majorly in the long run instead of simple client-side protections that can easily be bypassed.

4 Likes

no, this doesn’t helps at all, tools like RemoteSpy just make everything easier for exploiters.

3 Likes

The best way to prevent exploiters from maliciously using RemoteEvents is to just make use of sanity checks whenever a RemoteEvent is fired.

In reference to all things CS, this is termed honeypotting.

You should absolutely be doing it, because why would you not. Your game’s server codebase should be entirely secure first, to a point where honeypotting isn’t the defense that you depend on against exploits. You should also be typechecking passed arguments on Remotes that are not honeypots.

6 Likes

YESSS thats what im sayin. Take any precaution that doesnt hinder the gameplay and isnt going to take away too much time. Based opinion bro

The problem is that you shouldn’t instantly ban anyone who fires honeypot remotes. Instead, you should make it so that you log whatever actions they make take next so that you can find new vulnerabilities.

5 Likes

Only do this when you have the rest of your game secure. Don’t focus on honeypot remote events if you haven’t started with sanity/logic checks.

Now if you have a very tight and secure system already, go ahead and make a bait remote event and punish them if they fire it. Just don’t rely on it to catch all exploiters.

(Also for a fun tip, you can create a reference to the remote event to use later for connections and then re-name the remote event differently for every server. This way returning exploiters won’t know if it’s a honeypot or not. Have fun!)

2 Likes

It does help. Only a bit though. It really depends on how you want to hide your remote events.

If done correctly you could waste a couple of minutes maybe an hour of the exploiters time or so depending on how much time you spend doing it. You could even go for a “random naming convention” if you’d like.

If it is worth the trouble. Well…personally for my I would say it depends on the game. If it is for a simple game then yes. For anything else probably no.

The remotes will be found and if the exploiter gets banned then they will just make a new account and do it again knowing that the remote is fake. Also the exploiter can see the remote traffic and it can see whats being sent and received to the client and the exploiter will know that remote is not being used.

I guess the only use is to check if someone is messing with your game and attempting to find a way to exploit it.

worthless if not combined with account age requirement

I do it but meh idk how many it catches it would be fun to see how many people I got, it’ll only really catch new exploiters. I’d say it’s worth the effort of a few minutes though

Exploit applications like Synapse have in-built scripts such as Remote Spy that prints the remote (and the path) being used and the arguments being passed in console whenever a remote function/event is fired, making this method too much of a hassle to add in my opinion.

1 Like

It definitely is a great idea and is being used by tons of games. But instead of instantly banning them, it would be better to shadow-ban exploiters without letting them notice to prevent them from realizing the ban and simply making a new account as @WaviestBalloon and @AC_Starmarine said.

Good exploiters monitor the fired events and don’t just fire random remotes. Or they decompile localscripts and see what arguments and remotes are actually used.

Heres how to make a low-effort script. They can bypass it rlly easily if theyre an expert:
Local Script

remote:FireServer("BLAHBLAH", script.Name) -- Get script name. You dont need 2 args

Server Script

remote.OnServerEvent:Connect(function(plr, scriptname)
if scriptname == "ClickerScript" then -- Change clicker script to your script name
-- code
end
end)

It only takes at most 5 minutes to make a honeypot, I know for a fact that it will catch at least one person, so yeah, 100%.

Just make sure to add a random 5-20 wait time before banning so people don’t know it was the remote that caused it.