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?
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.
What about, when I set player as owner of the script.
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.
yes, but idk if it is part only.
Network ownership is only for objects affected by physics, for knowing who will calculate those physics.
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.
Yes, but I am more scared from trolling than generating money.
If your worried about trolling then you would have to set up some moderation or vote to kick system.
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.
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.
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 .
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.
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.
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.
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
Ok, so how to secure movement, infinity jump, auto aimer,âŚ
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).
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