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?
Create a Remote Event called “CashGiver”; when fired, it kicks the client.
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
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
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.)
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.
How do you plan on accessing it now? (from other script)
Security through obscurity never works and is not proper security.
1 Like
Add a range to compensate for lag.
Basically the key shouldn’t be greater than + 0.5 or - 0.5 the original value. That compensates for the lag due to time()
What prevents a player from doing hookfunction on the :FireServer method of the remote tho?
What about players for even lower-end specs which could possibly result in even higher lag?
Don’t take this the wrong way, but do you have much experience with scripting?
They can just clone the localscript, preview the code, and find the password formula, not to mention they can EDIT metadata, meaning the localscript would also see it normal, so your whole method would be pointless. Another thing, what if the server is slow and it takes more than 5 seconds to send back?