Is this good anti exploit system idea

Hi,
I want to ask if following idea is useable, because i dont want to create script, that is useless.
Ok so i have idea to make Trojan horse script.
How it will work? There will be easy anti exploit script on client, and server will check it. And when potential exploiter remove it, ik, that he is exploiter, and I can kick him, or ban him like when mod catch him.
Will this work?

3 Likes

I only did limited testing on this, but I believe while the server can see instances in PlayerGui, any changes the client makes to them won’t be replicated to the server.

However, your general idea of detecting an action only an exploiter can do is a pretty common practice called establishing a honeypot. For example, you could create an unused remote event in ReplicatedStorage called OpenAdminGui or something. Any exploiter who sees it is definitely going to try firing it to see what it does, and when they do, you can detect the action on the server and log their username/kick them.

9 Likes

What about, when I set player as owner of the script.

2 Likes

I don’t understand what you mean by this. Are you talking about network ownership, or something else? Client changes (for the most part) don’t replicate to the server, so even if you have a script inside of a player and they delete it, you can’t detect that on the server.

2 Likes

yes, but idk if it is part only.

2 Likes

Network ownership is only for objects affected by physics, for knowing who will calculate those physics.

5 Likes

No this will not be a good method of designing an exploiting system, as all the replies in this topic said that client changes do not replicate to the server. I also wanted to aid you in understanding how Setting network ownership works, basically this can only work on objects that are affected by physics, this is done to allow servers to do less work by basically allow clients to handle the physics and replicate it to the server, hence it will not work on scripts. As it always been said, ‘good exploit prevention should never be done on your client’. The main aspects of exploit prevention you need to focus on is securing your remote events, for example lets say you have a remote event to allow the client to buy an item, when this remote event is connected on the server you do a check on the server to see if the player has enough money before giving them the item, in other words, the keen principle is to never trust the client.

1 Like

Yes, but I am more scared from trolling than generating money.

2 Likes

If your worried about trolling then you would have to set up some moderation or vote to kick system.

1 Like

Exploiters have ALT accounts. If they try exploiting and see that that certain remote kicks you they will just keep trying on different accounts until they find a usable remote they can exploit.

Instead he should be checking on the server for odd behaviour and have sanity checks on remotes.

2 Likes

Don’t waste your time developing anti-exploit systems like this. Assume that the client (any potential exploiter) can and will execute any scripts they could possible want. Any solution that sounds hacky is probably useless in the long-term, and at best, a mainly useless band-aid in the short-term.

Set up your network model so that this ultimately isn’t harmful, and if necessary, perform checks to reduce the likelihood of character physics exploits, e.g. noclipping.

2 Likes

Yes, none of these are as effective as just having solid remotes and sanity checks in the first place, but that doesn’t make honeypots and whatnot worthless. It’s just another part of a well-balanced breakfast :tm:.

2 Likes

That is how exploiter got tricked and got banned. This method is best because you have no false positive, since only exploiter could fire it, normal player has no access to that stuff.

1 Like

I mean, it’s no the worst thing in the world, but these kinds of solutions are overall pretty pointless. It’s not like it’s a paid game–anybody can make a new account, at most your efforts are a mild frustration.

2 Likes

Stuff like this sort of exists. There is a concept called honey potting. You’d create a fake remote that flags/kicks/bans etc the exploiter which is never fired by any of your scripts.

I wrote this article about anti exploits. You might be interested in it.

1 Like

Your article is good. But I think focusing on very minor “solutions” like ‘honey potting’ are framing the problem with the wrong mindset to people that are still new to creating a secure network model. It definitely wouldn’t hurt to implement something like that, and it might do you a small amount of good, but it takes the focus away from making your game secure to begin with.

As in – treat the cause, not the symptom

4 Likes

Ok, so how to secure movement, infinity jump, auto aimer,…

1 Like

That’s true… I’ve gotten into the habit of making quick replies when I’m working on other things and it’s not a good one for sure.

You should think of Roblox’s client as if it were a text file. Or more specifically, if its memory was a text file. The memory of a program contains a lot of stuff. It contains code that the program can run, data that the program uses, and data that the program needs to transfer or process from the network.

If you could edit that text file, you can do just about anything with it if you know how it works. And similarly, all of the code that Roblox runs can be accessed, ran, modified, etc with proper knowledge and tools. That is the basis of exploiting. Anything sent to the player’s client such as local scripts, instances, tables, etc can be modified like a text file can. In fact, I believe in Windows you can even view a program’s memory as a file using Task Manager by selecting “Create dump file” without any third party tools or modifications.

When you think about game security you should think about what they can’t modify. Aka the stuff on the server. This stuff is protected by a network layer. Data is transferred back and forth but unlike the client, the server’s memory is on a completely separate machine and in a separate location. So effectively stopping exploits should involve the server.

Similarly, movement exploits should be detected and prevented on the server. The server can set the player’s CFrame, Velocity, RotVelocity, etc. This requires a little knowledge of Vectors and Roblox physics. Roblox has two main physics events. The Stepped (not RenderStepped) event fires before physics calculations happen. Heartbeat fires after. So for detecting and stopping exploits you should probably use Stepped. This prevents any physics from getting throuhg and prevents any unwanted side effects caused by lag.

Vectors also have some useful math properties. Magnitude gives the “distance” of a vector. Velocity is a directional vector with a Magnitude which is its speed. Subtracting two vectors gives you a directional vector where its Magnitude is the distance. Velocity represents the x, y, z distance the player is traveling per second.

Finally, the Stepped event (and Heartbeat) give you a variable representing the “frame time” aka time since the last frame. This lets you get the total distance the player should have traveled (their velocity’s Magnitude).

3 Likes

I tried the same thing, but unfortunately, this did not work. I made a script in like a half minute and it was already gone, the anti-exploit was useless at that point