I just realized that exploits can run
game.Players.LocalPlayer.name = "shedletsky"
game.Players.LocalPlayer.Userid = 1
And they can do this to give themself admin in games by changing their info to the creator’s information
How can I prevent this?
They don’t have the ability to do this. Roblox blocks this from working, to my knowledge, because of something called “script context”. It’s like a special permission level that’s required, and they wouldn’t have it.
The above is incorrect - I misunderstood how this works.
This only happens locally. The change does not replicate and therefore they’re only changing that information on that end. You don’t need to stop this kind of thing, it doesn’t matter. They can’t give themselves admin either if you structure your system properly.
Wouldn’t it throw an error and not work for the client?
No, it wouldn’t. Even then, an exploiter can override the read only lock for these properties. It has nothing to do with script context or anything, those don’t matter to an exploited client.
Check .UserId on the server instead of the client.
I did it does not work somehow they still gain admin.
They had admin commands when changing their information but only they can see this but they
can still run stuff like ;btools using my admin
Oh. I must have been confusing this with something else. Thank you for the clarification!
This would be an extremely serious vulnerability. Are you sure it’s not running in a LocalScript? Perhaps only test .UserId instead of .Name just in case.
yep i did try both ids and names and im sure its not a backdoor or anything i checked with backdoor finders
Like the people above mentioned check for the UserId’s on the server, not the client. If that’s not the case use RemoteFunctions to get the UserId in your LocalScripts, while you’re doing this pass the UserId they have on their client and compare it between the server and you may kick/ban them if you wish. If you want to detect it simply run this code locally:
game.Players.LocalPlayer.Changed:Connect(function(v)
if v == "userId" or v == "UserId" then
plr:Kick()
-- or fire a RemoteEvent to log it through a Webhook or whatever
end
end
--[[ You may also use:
game.Players.LocalPlayer:GetPropertyChangedSignal("UserId")
--]]
this is a dumb question but how do I use
that? I never seen it before
I’m pretty sure they can disable the Changed function on the localplayer easily?
they can also disable/delete the local script there is no stopping them
This is just something that shouldn’t affect anything, you probably have some vulnerability somewhere in your game. If i were you i would update the post stating that it is only happening in your game rather than saying “Give themself admin in games” as it is just false.
If they are doing things which affect the server such as deleting stuff with the btools you mentioned then i would look into the Backdoor finding plugins in the resources section of the forum or by checking to make sure you don’t have an poorly coded remote events/functions which could give them access you don’t want.
It’s a callback which you can connect upon:
local player = game:GetService("Players").LocalPlayer
player:GetPropertyChangedSignal("UserId"):Connect(function()
--code
end)
Keep in mind this is pratically the same as:
local player = game:GetService("Players").LocalPlayer
player.Changed:Connect(function(v)
if v == "UserId" then
--code
end
end)
Keep in mind this LocalScript can be deleted, there’s nothing stopping them from doing that!
As to how they’re changing it on the server, they must have access possibly by a plugin or free model if you’ve used any.
I’m not sure where you’ve heard this; that’s not possible.
which is why you should be putting it in a LocalScript that’s essential and mandatory for full gameplay or parenting LocalScripts like that to nil with:
script.Parent = nil
If im not mistaken, parenting stuff to nil just makes it harder. Some exploits can still access the running code and disable whatever they want about it even if it’s parent is nil. I’m not saying it won’t work, in the OPs case it probably would work fine. However anything and everything running on the client can be altered. That is to include Changed events and code parented to nil.
LocalScripts will only run in a correct environment, nil is not.
As well as putting it in nil, exploiters have ways to access Instances inside nil - they can just :Destroy() the LocalScript.
Exploits these days allow exploiters to adjust localscripts to their desire. meaning they can change functions and even disable them if they want to (client side only). Aside from that everything that’s replicated from the server to the client the exploiter can steal, this includes a script’s source. parenting the script to nil has no use to preventing it from being stolen. it replicated and is accessible by the Exploiter.
The only good thing you can to is not trust the client. That’s it.