Well, the question is kind of complicated, but to clear it out, I’m trying to do an “anti-exploit” thing, I know, many people believe that’s impossible however we’re not going to discuss that today.
As some of you know, or not, when an exploiter injects a script to the game, here’s where I will be mistaken or not, the client script they inject is added to the, uh, player but not in-game? So like you are unable to find it in the game but it does exist outside it. My question is what if there was a client script that can possibly detect whether suspicious scripts are added to the client or not. Yeah, kind of complicated to explain but I’m certain you will get it.
No, I don’t think you can do that. And how would it help anyway? The exploiter can just disable your detection local script. I don’t think the exploiter actually needs to even create a local script instance to run code on their computer. You shouldn’t rely on client side anti exploits, because the exploiter has the control over their computer.
1 Like
Any of the scripts that are executed by a script executor are nil. This means in theory they are not even really in the game itself.
There’s no way to detect a script being executed by a script executor since all the exploit does is pass Roblox compatible bytecode to the Roblox deserializer, which executes the code. (very simplified explanation)
Now in the past, there used to be exploits that created a LocalScript instance to run the code, but I think this is old technology now.
You used to be able to detect when an exploit injected by using Roblox’s Stats service and garbage collection to detect specific strings in memory, but this does not work anymore either.
So, if you want to detect anything at all, you’d be best adding sanity checks to your server-side code and making sure the player isn’t doing anything that’s obviously illegitimate.
3 Likes
Since injected local scripts are parented to nil, doesn’t that mean Roblox itself could just prevent local scripts that are deattatched from the game from running?
There’s many legitimate cases where a script can be parented to nil, so that wouldn’t really be a viable solution.
Roblox do add checks to the Luau portions of the Roblox client, such as call checks, stack check, etc. I’m not going to explain in detail how this stuff works, as I want to respect Roblox.
I would like to say that Roblox are doing all they can to prevent this but they really are not - and they can’t.
The lesson you have to learn here is to never trust the client. The client is on my computer which means I can do whatever I want with it. It’s the job of the game server to prevent the client from doing too much damage.
2 Likes
You could use a remote event with a sort of “queueing system” that’ll check if the player’s script exists or not based on whether it receives a server event or whether it receives nothing at all (meaning they deleted the script).
For example:
-- On Server
local checkEvent = game:GetService("ReplicatedStorage"):WaitForChild("checkEvent")
local checkedPlayers = {}
checkEvent.OnServerEvent:Connect(function(Player, scriptStatus)
checkedPlayers[Player.Name] = scriptStatus
end)
while true do
wait(1)
checkedPlayers = {}
for i,v in pairs(game:GetService("Players"):GetPlayers()) do
if v.Backpack:FindFirstChild("Anti") then -- Check if script is loaded in
checkEvent:FireClient(v)
end
end
wait(3)
for i,v in pairs(checkedPlayers)
if not v then
-- Anti code
end
end
end
-- On Client
local checkEvent = game:GetService("ReplicatedStorage"):WaitForChild("checkEvent")
checkEvent.OnClientEvent:Connect(function()
checkEvent:FireServer(true)
end)
To further add to security, you could only connect checkEvent to a function when you are checking each player.
Well, why couldn’t the exploiter just fire that RemoteEvent without running the other code in the local script? The exploiter has more control over their computer than we developers have. Exploiters can do things that local scripts can not do.
You could only connect a server event to checkEvent when you are checking each player. Although one thing I have overlooked is that they could also just connect a function to checkEvent on a separate local script and then delete the other one. I’m trying to think of a way to prevent this.
You can not prevent an exploiter from changing the behavior of their computer.
Yes, but the exploiter can still fire the remoteevent during the time the server has the connection. So how does that help?
I believe I already corrected myself
Although one thing I have overlooked is that they could also just connect a function to checkEvent on a separate local script and then delete the other one. I’m trying to think of a way to prevent this.
Let’s clarify some things here, as this appears to be a controversial topic about client-side security if it’s worth it or not.
Sure, you can prevent quite a few things via a LocalScript such as walkspeed, gravity, etc. However, as mentioned several times over in various places, exploiters can just disable these detections fairly easily. You need to develop ways to ensure that you can check the integrity of the client itself, but how do we do that? We don’t.
A nice little saying I’ve learned recently is the saying “My machine. My rules” which basically means anything on my computer, I can do whatever I want with it. You can’t trust the client to perform actions that are dependant for security, such as trying to kick the player from a LocalScript - the exploiter can replace this function to do absolutely nothing or even do another action.
So, when it comes to securing RemoteEvents (or networking in general) you can’t trust the client to generate secure keys or to securely wrap your RemoteEvents in some special way that the exploiter can’t mess with. Exploiters have access to a lot more than you ever will on regular Roblox, such as the debug library to access constants, upvalues, etc and being able to modify the Roblox Lua environment and Lua registry.
What does this mean? Simple, make sure that you’re only exposing RemoteEvents for a purpose that isn’t going to give anyone in the game any advantage and make sure to always check what you’re actually being given. This means verifying everything possible from the server.
Client-side security checks can be useful for making things more difficult but shouldn’t be relied upon.
7 Likes
This is a good question.
You can use LogServixe to whitelist specific messages, or even better yet; when a script sends data to the output, LogService can get the source script and if it isn’t on the server, it could kick you.
but what if they put it in their main local code, then if they disable it, they disable other functions and they wont be able to play
Exploiters are not limited to disabling whole local scripts. They can disable any spesific part of the code and even run their own code. As [redacted] said the exploiter can do anything they want with their computer.