Still useless because an exploiter could just decompile your script and recreate the password.
2 Likes
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.
If a script can be decompiled so easily what’s the point of anti-exploit?
An anti exploit can make life harder for exploiters, not stop them entirely.
To make them hard to bypass even with decompilers, obfuscated, or use an anti decompile.
treat clients like a black box that can lie to the server whenever it wants to. that’s just how it works.
2 Likes
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.
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
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.
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.
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.
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
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.
Interesting idea 
.
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.
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
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.
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.
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.
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.
How can an Exploit manipulate a server when they are on the client?