I was talking about tools called (not referring to) remote spies. You can’t check the game’s memory; that’s why I made the “put assembly code in your executor” joke. If you generate your token (password) in the local script, you then need to fire it to the server, and then the server lists it and remembers it. The ways on the server are whatever you feel like it, even if you wish to make a folder in a non-replicated service and put string values with names. The question here is whether those tools can actually see what information is being sent through a remote. You can check the received information; that’s why we make the password on the client and make the server remember it, but if those tools can also see the information sent from the client, well, then that’s not possible, but still, I don’t see a good point to making this a thing. This should be a discussion and not really help, because this is a concept of theory and is meant to prove something possible. These methods are not reliable and shouldn’t be used in real practice. All of that stuff aside, if anyone knows about this question, please share. I actually want to know more about it. Again, if I’m wrong, please correct me; this is only my point of view, and I don’t want to influence anyone’s opinion.
I will now try to hack the system, if it works out, I will definitely write how its I did it, and maybe I will fix it
game:GetService("LogService").MessageOut:Connect(function(msg)
msg = msg:split(" ")
if msg[1] == "Gen:" then
print(msg[2])
end
end)
Please note exploiters can read what you are firing & sending across both networks.
exploiters can see the password in the “AttributeChanged” function
they can, but after 0.0005s it will become 0, that is, it is impossible to start the event with this password, I tried
this might work
game.TextChatService.BubbleChatConfiguration.ImageLabel.AttributeChanged:Connect(function(a)
game.ReplicatedStorage.RemoteEvent:FireServer(a)
end)
Hello!
Before I get to the topic, I have to say, I’m glad to see you taking initiative in diving into game security.
To sum up the code, it may be broken down into a few steps:
- Server script detects a mouse click.
- Server script generates a random code and stores it into the module.
- Server script replicates the code in an attribute to the client for a brief amount of time.
- Client detects the momentary attribute change, takes the password, and fires a remote event with the acquired key.
- Server compares the keys.
- Server changes the password again (to 0).
Interesting concept.
However, I’m curious about why use remote events in the first place. The code seems to be passing the ball back and forth instead of catching it right away. Server script can register the button press and act on it.
Vulnerabilities
→ afk farming with an autoclicker is unavoidably possible either way.
In theory, if we used remote events like in your case, exploiters indeed shouldn’t be able to afk farm without an auto clicker. They’ll have to click the button, local script will read the code, and fire.
Vulnerabilities and important notes
→ afk farming using an auto clicker
→ server then changes the password to zero. If clients were able to realize this, they could avoid the checks by sending 0 as the key
→ some more network traffic is used
→ exploiters can view the code in the the chat service as well as what the client fired; that won’t help them because it’s a one-time password; the only thing they can do is freeze the remote event and fire when they please (once!)
→ task.wait() cannot really go below RunService.Heartbeat:Wait(), which is 1/60 seconds.
However, this approach introduces some more complexities that can be avoided by simply using one server script.
Because UI, effects and animations should always be handled locally, it’s widely considered a good practice to have local scripts handle the button and signals transitioned via remote events.
- Local script handles the visuals and fires.
- Server accepts the remote events.
Vulnerabitilies
→ allows afk farming, which is possible either way, except one requires an auto clicker, and the other allows firing of the remote events; like @Artzified said, a cooldown can do a lot here.
I actually did it for fun, it was just interesting to implement it
Awesome.
And please don’t take any criticism to heart. AFK farming is rather impossible to avoid completely, because people can use auto clickers clicking on random positions and have their character move by simulating key presses, which makes it significantly harder to detect, depending on the complexity of an exploit.
I sometimes play with remote events too, and I wanted to give some insight comparing the methods. Your method is nice and actually has a potential to prevent exploiters from firing remotes, though I wouldn’t use this in production code.
Personally, I try to find a trade-off/compromise between trying to introduce complicated patches and efficiency as well as simplicity. I ask myself how much does an exploit affect the game and what the cost of fighting it would be. Sometimes a patch would fix about half of the occurances, but it would also burden the server so much more it wouldn’t be worth it.
Eventually, I often try to follow Occam’s razor philosophy when coding - the simplest answer is usually the correct one (or the most effective and performant one).
Good luck!
Not really because I’m pretty sure exploiters can see any password generated on the client.
Remote event passwords wont even work due to exploiters can just hook remotes with __namecall and can just return true etc or just block the remote using modules are not good either if its not on server due to exploiters can just view them with ease
Keys are great to break old scripts and/or improperly maintained scripts.
that might be true but a experienced exploiter can easily bypass a remote event fire due to being able to read function that it executes (its possible because i used one) a anti cheats purpose is to stop more exploiters in a time so only experienced exploiters remain
Yes I know but frequently updating the keys may tire them, having to launch dex > remote spy > get arguments > update scripts > publish.
vs open studio > edit script > publish
i am pretty sure __index can get arguments with a one sweep due to exploiters having access to raw metatable of game itself but your argument is right