Is This a Good Trap against Exploiters?

Hello Scripters!

Disclaimer: I’m not trying to solve, I’m trying to learn, and maybe help future readers out, too.

A few days ago, I learned more about anti-cheat: Other Post. They told me that the exploiter can see anything on the client.

Well, what if I added a Remote Event called something like "GiveCoins", and the server gave them free coins. The exploiter can share it to his buddies and they all get free coins or earn something else. What they don’t know is that their Player ID is being stored in a list using Memory Store Service. The developer, whenever they want, can take that list and ban everyone in it. Trapped!

Edit: When the remote event is fired, I don’t mean that they are instantly banned. I mean that they are added to a list, and after there is hundreds of players on the list, the developer bans them manually.

Is this already used? Is there a problem behind this, or is it a good trap?

Thanks for reading and have a blessed day. :slight_smile:

7 Likes

One person will fall for this → they tell other exploiters that it is a fake remote → everyone now knows

Most explotiers find scripts off google, and those scripts are built off the people that spread around the fake remote

if you want to trap 1 person, go for it

7 Likes

It will definitely work if your game isn’t popular, but as @F0xBirdmansBFF said, because exploiters get scripts from outside sources (not their own scripts) only one person will need to fall for it in order to be completely useless. Maybe you could keep it as a remote event, and make it function, but they will be shadowbanned from trading.

4 Likes

What is said above is true - “fool me once, shame on you, fool me twice, shame on me”.

Another issue with this is that exploiters can just look at when a RemoteEvent is fired. If they notice something wrong with the RemoteEvent, such as the RemoteEvent not being fired when it usually should, they’ll be extra careful. Script kiddies should fall for it, though.

4 Likes

When the remote event is fired, I don’t mean that they are instantly banned. I mean that they are added to a list, and after there is hundreds of players on the list, the developer bans them manually.

1 Like

The issue then is that there would be no perfect amount of time you can wait before banning them manually - either you wait very long and get tons of exploiters but in the meantime they are able ruin the game’s economy/leaderboards etc, or you don’t wait too long, get only a handful of exploiters and they start realising what you’re doing.

The issue I mentioned still persists - if anything suspicious with the RemoteEvent is noticed by an experienced exploiter, let that be anything that is possible, then less and less will fall for it.

3 Likes

It doesn’t have to be something that ruins the game. The “give coins” was just an example. The server can give anything, it doesn’t have to be just coins.

2 Likes

I’m very sorry, I’m lagging quite a bit. I finished my previous post and I’ll answer this one once I solved the issue.

2 Likes

How could an exploiter think it’s suspicious? If it’s a talented scripter, then I can see why. How could you make it not suspicious?

1 Like

Alright, I’m back.

Good point, but then this begs the question: Why would an exploiter, who, keep in mind, wants to beat your game, want to change stats that are unimportant for progress? Again, a script kiddie would probably fire a random RemoteEvent named “Give…”, even if it doesn’t do anything too important, but a patient, careful and experienced exploiter - and these are the most powerful of them all - would most likely not fall for it.

As said before, you’ll for sure be able to detect exploiters who just copy and pasted some code from somewhere online or who don’t know what they’re doing.

3 Likes

Most exploiters who don’t know what they are doing just copy code from exploiters who do know. So it’s not going to trap anyone really

2 Likes

How could I make the experienced exploiter think it’s real?

1 Like

One thing that I can think of instantly is for example when the RemoteEvent isn’t called frequently.
Assume it’s something like “GiveMoney”. An exploiter notices that a player earns money without the “GiveMoney” RemoteEvent being called. Suspicion arises and the exploiter would rather avoid it.
GiveMoney was an example, it would be the same for all similar cases.

Another thing I can think of if it’s just too obvious, like something like “GiveAdmin”.

2 Likes

You can’t

2 Likes

That’s tough, really tough, since experienced exploiters (who know what they are doing) are very smart and capable people. Even if you try really, really hard, and manage to even find a way, if there are enough cheaters on your game, one will be able to bypass the whole system you made, forcing you to make a new one.

You might be beginning to notice a pattern throughout this thread: everything you try to trick exploiters may work short-term, but not long-term. This is why you still see exploiters on popular games: it’s not that the developers are incompetent, it’s just that there are really talented exploiters.

If you ask me how you should fight against cheating then, then honestly, I can’t tell you, because anything I could imagine can be bypassed when enough work is put into it (and this is where being able to make infinite alts sucks, since even if it works three times or so, it won’t work forever - they’ll begin to notice).

simplest way to fight cheating is to make your game a single player game tbh lol

4 Likes

You can do something like this every so often to obliterate script kiddies but the people who exploit like it’s their job probably wont fall for it. If it were me I would never fire any remote that I didn’t observe firing naturally by using a remote event viewer.

3 Likes

Maybe if ur able to see where the event was fired from so whenever a player gets money it has two sources 1. The actual source 2. What the Exploiter fires

This way any events that were fired other than the actual source are banned or added to a list etc… nice idea tho!

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.