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

Help and Feedback Scripting Support
#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.

#21

If it’s also a multiplayer, the exploiter could probably edit the other player’s anti-exploit scripts and think their client or either server would assume it’s a exploit and a threat so they’ll false kick the player, correct me if i’m wrong cause i haven’t took full examination of “the inquiry method” topic.

#22

Right… send in a different localscript each time with a different key. The localscript is put into the character and sends all the information to the server in less than 1 millisecond.
Then after the information has been sent, it deletes itself.

The key will be different each time it’s sent and this will make it harder for the exploiter to decompile the script and remodify it in time. Also rearrange the orders too of the arguments.

I’m confident this will work.

#23

The concept you are thinking of won’t really work in practice. Just like what @BIackShibe and @focasds said the client can always manipulate stuff. There isn’t really a good reason to develop this when you could spend your time developing secure game mechanics. You can find plenty of articles on how to do so and I will link a few below.

2 Likes
#24

Exploiters will find a way around it. LUA isn’t meant to be secure but this helps slow them down. Not the best method though but works.

#25

Interesting idea :slight_smile:.
Even if the exploiters will manage to get through this one day (probably), the problem I see here is that local scripts don’t work inside the workspace (unless in StarterCharacterScripts or tools), and you also can’t create a local script (with code inside) from a script AFAIK unless you clone it from somewhere, and if you clone it, my guess is that exploiters will find it’s location.

#26

This will not work, the server time is different from the local time, and will also have the lovely added benefit of a delay between the server and client boundary. 1/1000000000000 of a second off and you have a different password. You’d be better off using a key exchange.

You can intercept calls to steal a password, you can also access memory and get the password straight from your scripts.

This is alot of data being transferred and is not optimal.

Replication in Roblox is an interesting thing, you’ll actually be a few hundred milliseconds behind before it finishes replicating. You also have to account for ping along with other things, and thats also a ton of data that has to be sent… you’re sending the entire length of a script… talk about inefficient.

Don’t try and make it so you can trust the client. You will fail. Anything you can think of valve, riot games, every major gaming company, etc has already thought of. This will not work, you just have to not trust the client whatsoever, it’s that simple. Well… keep thinking, and if you do find something that perfectly works, then you just put every single person in cyber security out of the job.

2 Likes
#27

Honestly.

Just send a localscript for that instantly deletes itself as soon as it sends back the information. Give it a special different key each time and hide it like 500 lines below so the client doesn’t even have time to decompile it.

#28

This will not work. Any information you send to the server goes through a remote event or remote function, which they can intercept and edit.

#29

They won’t be able to edit if it’s a really really huge code with lots of keys and random numbers and about 400 lines separated in less than 0.25 seconds. and if they make any typo and the response is different then they get banned.

#30

To send the data back to Server from Client, you will probably use a RemoteEvent right? What if the client removes the remote event from his client side? The localscript will probably break in that case.

#31

How can an Exploit manipulate a server when they are on the client?

#32

Create a Remote Event called “CashGiver”; when fired, it kicks the client.

#33

Honeypots only work on 1 exploiter, once they realize it’s bait they will tell other exploiters and then they will know to not fire that remote.

It’s a good idea in theory but in practice it isn’t a long-term method to ward off exploiters

#34

I’ll try to explain this in a understandable way.

When you use :FireServer() on any remoteevent, that’s a namecall function inside the game that is a metatable, it uses : because it refferences the game metatable index.

Basically, the entire game is a metatable, and the functions inside the game object are basically __namecall() which can simply be changed on the go by setting either return true or just changing the variable on the FireServer namecall.

In the end they don’t need to decompile your script, they only need to either know the positions of the values or the type of values being sent, after that it’s just treated as a normal function and they can just return the values they want to the server.

1 Like
#35

How about a remote event that changes its name? For example it runs on a loop:

while true do RemoteEvent.Name = tostring(math.random()); wait(); end

(Where “RemoteEvent” is a previously stored local variable.)

#36

He’ll get kicked if there’s no reply after 5 seconds. The player has 5 seconds to send back his information and if he deletes the localscript then the proper reply isn’t sent and he gets kicked.

#37

How do you plan on accessing it now? (from other script)

Security through obscurity never works and is not proper security.

1 Like