Im wondering if the script(In Serverscriptservice) is safe from hackers firing the event and changing the values.
game.ReplicatedStorage.ChangeVal.OnServerEvent:Connect(function(plr, V, TruthVal)
if TruthVal == "giqohgioqhgiqhgv;bqa" then
plr.leaderstats.Equipped.Value = V
print(V)
end
end)I’m not a hacker nor am I professional anti-cheat dev but I’m pretty sure that they can see the scripts where you’re firing the RemoteEvent and they’ll probably find out that “that” is the passkey.
And I’m also sure RemoteSpy gives them this info so they don’t even have to guess
No. Remote “keys” are not secure and will never be secure, as there must be a way for a script to contact the remote (whether through a static key or a module), and that module has no way of verifying that its being called from an executed script.
The best way to prevent exploiters from rapidly changing your “Equipped” leaderstat would be to verify the conditions in which it would be changed on the client. Such as, checking the Character model if the tool exists. Of course, a client can delay these requests, so if this is really important you can simply perform the changes on a server script, disregarding any potential performance gains.
If the value isn’t important in any way, then just do away with the key. It’ll be fine. Maybe you’ll have someone with Equipped=true without actually having it equipped, but so do people with high ping.
How much security for your remotes you need depends vastly on the actual use case. Of course, you should always shoot for maximum security, but in smaller cases you can shoot for the hip for a non-commercial product.
If you want more obfuscation in what exactly your remotes are doing, you could use a performance network library that’ll be at least somewhat resistant against script kiddies. Performance network libraries usually group all RemoteEvents into one and send it all at once in a huge packet instead of many small ones. It is different to program with, but it does help with the never-ending War Against Exploiters.
It is possible for someone to use “RemoteSpy” to find all the arguments you are attempting to pass from the client to the server. Therefore, I do not recommend using something like this.
Looks pretty good. They would have to go far to break that. If that happen you must have a good game going and then you can change this to random TruthVal’s to throw them off even more. By that time you would be making money anyways. Hackers love to post their hacks like a badge or something. Let that go for a bit then change it. This ends up leading to hacks that don’t work and the net is flooded with it.
If it is safe feel free to test it out im not sure but it seems safe to me
Like others have said, you should definitely verify parameters. Exploiters can force the script to error in their favor by passing the wrong data type of a parameter along the event (e.g. passing a number when a string is expected). You can use typeof() to check the parameter type and stop the script from erroring. This also prevents errors from nil parameters.
RemoteEvent.OnServerEvent:Connect(function(player:Player, expectedNumber:number, expectedString:string)
--not checking the 'player' parameter because that is passed automatically
--so exploiters can't mess with that
if typeof(expectedNumber) ~= "number" then return end
if typeof(expectedString) ~= "string" then return end
print("No exploits :D")
end)
unless V is only important to the client such as with visual effects you should never trust clients with values to begin with. always have the server decide how leaderstats should look.
Everybody posting comments such as
Really should not post this as developers will start relying on such method. This is unsafe as a simple RemoteSpy I can make in 5 minutes will probably be able to grab the key. If you want to “secure your remotes”, use encryption, although that will also be useless without obfuscating your game scripts (as they could just see the key in a constant via debug.getconstant)
I’m not getting into the hackers fight today. Always someone crying when you talk about stopping hackers. I’m sure you have every hacker tool known and they can split the red sea at will. I think anything is better than nothing and hackers are the weakest link with the weakest tools. If the time comes when this is actually a problem, I’ll be glad I have a popular game. For me the fun would just begin with dealing with hackers.
They can see the pass key itself if the code belongs to a module within a folder that replicates to the client(like ReplicatedStorage, Player instance, etc), however if this code belongs to a server script that the client can see(not a module script), they can’t access the script source because it wont replicate to them. When it comes to client scripts(local scripts) they can decompile them normally and view their source code. So to break it down to specific cases:
Now if you’re certain they can’t figure out the passkey by simply peeking at the code, another issue is if the exploiters try to bruteforce the answer. You can mitigate this by rate limiting the event on the server side, here’s an example:
local debounces = {}
local requestsPerSecond = 1 --allow them to make 1 request per second
ChangeVal.OnServerEvent:Connect(function(plr, V, passkey)
if table.find(debounces, plr) then return end
table.insert(debounces, plr)
task.delay(1/requestsPerSecond, function()
table.remove(debounces, table.find(debounces, plr))
end)
if passkey ~= "secret code" then return end
plr.leaderstats.Equipped.Value = V
print(V)
end)
Keep in mind another issue the above code has is that the value of V can be spoofed by the exploiter, meaning that they can modify it and potentially equip something else.
Also they can view the passkey if they have access to the place file for whatever reason, for example if the game is uncopylocked or if an account with access to it gets compromised.
I was going to say this … put all this in ServerScriptService
Exploiters can fire remote events, if that’s what you are asking. A password is kind of useless when you can just have a list of whitelisted userids that can use the remote! If that’s what you wanted.
This its not safe, a exploiter can visualize local scripts, then they can see these “keys” just by seeing the local script.
if it’s something important like cash giver or something, then it’s should be doublechecked, not by custom id, but userid or check value, if it’s not important like tool equip, you should simply secure it by unequiping other tools if they are equiped
Who is being toxic here, I’m not the one calling people clowns. If you have so much experience with security working on countless projects then lets see some code. Educate us rather than condemning someone looking to encourage. He is asking for help, so help.
You can look at my featured post, or just look at my resume website.
So are you selling something or coming to script help to help with scripts?
How am I… selling something? If so what is it?
I don’t know … just don’t seem like you’re looking to help anyone here with any scripts. What is the point of coming here if that isn’t your intent. Myself I just add many layers of stuff like this. I actually have commercial games and a master degree in computer science. If one fails to pick up the hacker the next one will not. Only need to catch them once and they are gone forever.