What you can also do is check for a remote spy by using the LogService and string.find
Do you have any examples of how I could go about doing this? Exploit protection is where I’m most inexperienced, I only run checks at the moment.
Every exploit prevention requires a different solution. In your case your best protection would probably be making a cap of the maximum registered click rate. Go for like 10 - 15 clicks per second - anyone clicking faster than that wouldn’t even notice this cap much.
local click_budget = 15
local function CanClick()
if click_budget > 0 then
click_budget = click_budget - 1
spawn(function()
wait(1)
click_budget = click_budget + 1
end)
return true
else
return false
end
endThis kind of code should be run server-side, individual budget values for each player.
Yeah I considered doing this but I feel like there’d be issues with the client and server boundaries being slightly delayed. I’ll probably go ahead and implement it anyway as there’s no such thing as too much security.
local LogService = game:GetService("LogService")
LogService.MessageOut:connect(function(String,Type)
if Type == Enum.MessageType.MessageOutput and string.find(string.lower(String),"remotespy") ~= nil then
--kick crash or whatever floats your boat when remote spy is found
end
end)
This would be a local script it’d be best to hide it in nil
1 Like
Does that really work? Would some exploiters really have the audacity to include “remotespy” in any of their scripts? Sorry if I’m wrong here I have no clue when it comes to this, a lot of this is new to me and I plan on using it to better myself.
Well the most common remote spy script prints “remotespy” when it finds a remote being called you can always change the check to find like remote names being printed like if BuyItem is printed out in the dev console you can kick them or whatever
Wouldn’t hiding a script in nil still be visible for exploiters?
I personally prefer the method of checking if the script still exists with the use of remote functions, pcalls, and delays to keep things running smoothly.
1 Like
I’ll try it - thanks for the help!
Depends on the exploit some exploits have their own functions like FindInstancesInNil
Do you have an example structure of the best way to do this? I’d love to learn how to.
I knew as much already as exploiters could access nil, hence why I’m interested in your proposal here.
Don’t waste time on hacky solutions to detect exploits. An exploiter can just change the output not to include whatever keyword you’re looking for, and they can go about as they please.
These are wastes of your time:
- Scanning output for keywords related to exploits
- Scanning for certain objects to be present in certain locations to detect exploits
- Encrypting remote traffic
- Using random numbers as keys for remotes
- Hiding your scripts/remotes in weird locations at run-time
- Renaming remotes/objects to random strings
All of the above are security through obscurity and can be easily overturned because the exploiter has full control of their own client.
Server-sided checks stop all kinds of exploiters and are the only thing that give you real security, because these checks run on the server which the exploiter cannot touch.
There’s no free lunch. Implement proper server-sided checks, it’s the only way to truly prevent exploiting.
15 Likes
Sure thing, lemme grab an example from one of the games I’m working on…
Local script named “Player Set Up”:
Naming things as plainly as possible to confuse any snoopers
Code
--scripted by GreekForge
local access = game.ReplicatedStorage.Remotes.ClientAccess --most important this is a RemoteFunction
local coms = game.ReplicatedStorage.Remotes.ClientEvent
local plr = game.Players.LocalPlayer
local char = workspace:WaitForChild(plr.Name)
local hum = char:WaitForChild("Humanoid")
local noUse = { --for the rest of my script
Enum.HumanoidStateType.Flying,
Enum.HumanoidStateType.None,
Enum.HumanoidStateType.PlatformStanding,
Enum.HumanoidStateType.Swimming,
}
local function oof()
return true --this can be anything, just return something
end
access.OnClientInvoke = oof
--insert the rest of what you need
Server Script (Can be named anything):
The exploiter cannot do anything to change the server, it only has full access to client
Code
local function playerClientScan(v)--v is player
--check if the client script still exist
wait(0.1) --dunno why
local succ, x;
spawn(function()--make sure the thread doesn't stop
succ, x = pcall(function() return access:InvokeClient(v) end)
end)
delay(9, function() --once again, no stopping the thread
if not succ or x == nil then
spawn(function() succ, x = pcall(function() return access:InvokeClient(v) end) end) --yeah...
delay(3, function()
if not succ or x == nil then --just in case of slow loading
succ, x = pcall(function() return access:InvokeClient(v) end)
end
end)
end
end)
end
spawn(function() --main scan
wait(scanDelay)
while wait(scanDelay) do --added a wait at beginning because this runs once before actually waiting
for _, v in ipairs(game.Players:GetChildren()) do
local char = workspace:WaitForChild(v.Name, 5)
if v then
playerClientScan(v)
slowPositionCheck(v)
end
end
end
end)
Whenever creating an anti-exploit with multiple checks, always make sure that the player hasn’t been kicked or removed before doing the check.
Of course, if you really want to obfuscation on client scripts can severely impair any exploiter.
3 Likes
I see how it works, good to know.
Thanks for the example!
Why do you invoke the client 3 times? I could just destroy the script and overwrite the callback of the RemoteFunction from an exploit.
1 Like
Well that would work but if the script doesnt have “RemoteSpy” but “RemoteLogger”, that check wouldn’t work.
I have a method of crashing most RemoteSpy scripts the moment you run them. However it is a very easy fix for them, soo yeah.
1 Like
This won’t work for obvious reasons. Never have I seen a single remotespy print "remotespy" in the output lol
Some remotespys have custom guis where they display the remote info and the arguments.
Won’t help you. An exploiter can print the list of all running localscripts ans modules to their output along with their locations, then filter out the common ones like LocalSound. Alternatively they can use an explorer called Dex to look for localscripts, or even save all localscripts at once and browse them in studio.
An exploiter can check what your callback returns and replace it with their own callback.
It will greatly impair the performance and FPS aswell.
You shouldn’t primarily focus on a clientsided anti exploit. Instead add some server checks. A remote debounce, a “verification” that the player isn’t afk auto farming, like telling them to stop clicking for a second if they click too fast, etc.
3 Likes
My main goal here is to remove any script kiddy who thinks they’re pretty cool. And I do have a server anti-exploit.
I’ve never heard this, can you provide me some evidence?
Due to how VM obfuscators work, if you’re for instance calling an obfuscated function rapidly, your fps can drop from 60 to 3 (personal experience). Knowing that you can guess that it can drop the performance even if you don’t do what I just said.
Like this idea of telling them to stop clicking, will probably put that into practice. Thanks!