My anti-exploit concept... “The inquiry method”

Help and Feedback Scripting Support
#1

Most exploits involve the client adjusting their character and their hipheight etc.
Client stuff. Character modifications.

Right.

To solve this. We could have a server send a localscript to the player’s character and that localscript will instantly send all the information from the client to the server and then delete itself.

The server will look at the reply from what the localscript is and will compare what it’s seeing. If it detects any illegal things sent from the client to the server that aren’t found in the server like bodymovers in the rootparts of the character then that’s a kick.

If the player deletes the script then the server won’t receive an answer and it’ll kick that player.

A Guide to Making Proper Anti-Exploits
#2

If you use a remote event and use :FireServer(), exploiters can have their own script that fires desirable results.
Also lag may produce undesirable results

5 Likes
#3

Just prevent players from firing their results without the server asking them.

Like,

Client: HEY I’M NOT USING ANY EXPLOITS!

Server: Did I ask you? Get outta here.

2 Likes
#4

An exploiter can still manipulate that.

2 Likes
#5

I mean.
What are you exactly making?
As it’s obviously, it’s not really complicated to stop exploiting.

#6

He can’t if the script is sent in less than 0.25 seconds

#7

An exploiter can hook and modify a remote request that is sent or received no matter how long it takes.

2 Likes
#8

If you’re gonna send information intermittently, a better option would be using a changing password.
Both scripts would use the same formula for the password that is dependant on the time. Example: password = (((time()5)(time()*4))+((time()*2)*102))/(time()+152)+((time()+7)*time())

For every Remote Event, this password would have to be sent. It would be extremely difficult for an exploiter to calculate a difficult formula like this

3 Likes
#9

It would not be difficult at all for exploiters to figure out the formula because of decompilers. Also, they can still just edit the requests sent by the LocalScript and keep the key. Using time as a password key can also lead to mismatches if there is lag between the time the request is sent and the server receives the request.

#10

An exploiter can also quite easily replace the game’s metatable, similar to __index in a metatable, and make those properties return normal results when in actuality they are different.

5 Likes
#11

The formula can be changed intermittently using another formula which adds another layer of security and there wouldn’t be a mismatch if you round some of the numbers using math.floor(), math.ceil() etc.

#12

Still useless because an exploiter could just decompile your script and recreate the password.

2 Likes
#13

You could simply when hooking the remote make it send the correct key (which you figure out from what the client is sending), then change the other values, and send that to the server.

#14

If a script can be decompiled so easily what’s the point of anti-exploit?

#15

An anti exploit can make life harder for exploiters, not stop them entirely.

#16

To make them hard to bypass even with decompilers, obfuscated, or use an anti decompile.

#17

treat clients like a black box that can lie to the server whenever it wants to. that’s just how it works.

1 Like
#18

Everything that gets on the client can get manipulated, all the stuff that that script will return they can fake it. They can ruin and will still make the life of a game developer or any developer very difficult. Dumb checks because they send fake stuff. THERE IS ALWAYS A CHEATER.

EDIT: Remember they can also edit the metatable of each object, that said, if your script goes in the client side it might return fake values or results. Idk if they can delete an Instance and still apply those physics to their characters, tho.

#19

Game security is a lot like physical security: they are deterrents and YOU choose what’s possible. For example: If you don’t want someone to trample on your lawn, you can put a fence up. Now someone has to get by the fence in order to trample your lawn and it isn’t possible to just walk on your lawn any more. Similarly, if you don’t want someone to change a value, then make it impossible for them to change that value.

Exploiters can only change what’s inside local scripts NOT server scripts. The only way they can change values in server scripts is if you allow it. You are literally handing the code to the client (they need it to run the game), there’s nothing more you can do once your local scripts are handed to them.

If you’re looking to just waste an exploiter’s time, then include honeypots that can only ever be accessed/changed by an exploiter. It’s a nice way to knock out some exploiters. The whole goal is to get the exploiter to say “…I’m not gonna waste my time” and move on.

6 Likes
#20

I use a large amount of information on my vehicle module project - whenever a change is requested by the client, the information table related to their vehicle is sent to the server and that data is compared with the server’s copy for abnormalities. The server table is then edited to effect the change, the effector in the vehicle (turn signal, headlight, engine) is actuated, and the updated server table is sent back to the client, essentially refreshing any changes made. Any abnormal changes on the client (extra gears, for example) are quickly detected and handled by the anti-exploit. The idea is that whenever the slightest change to the vehicle occurs, it’s original table is replaced over the exploited table. So far, this has been working for me.