How to know on the client if the environment of an exploit required a module script

Help and Feedback Scripting Support
#61

@ExitusActaProbat you’re being really ignorant here.
TL;DR → a complicated anticheat system of some sort on the client is just not feasible. Everything on the client can be changed, granted that the exploiter knows enough about what they’re doing.

My games use a system where the server fires a client using a RemoteFunction to return any data, and then the server checks over said data to see if it has been tampered with or not. Surprisingly effective, I have thousands of bans from it.

People using really badly made scripts (that cause errors) are also detectable by combing through their console output and looking for keywords such as “synapse” etc.

1 Like
#62

I think you misunderstand how script injector exploits work.

Take the command bar or devconsole, both of these dont have an active “script” global, because they’re running outside of a script container

The same is applied to injectors. They run outside of a script container, so there is no script global.

#63

I think you’re not understanding something

as an exploiter, script is nil in your environment
as a developer, you’re able to get the script instance of the exploiter if you’re using getfenv

#64

Would it not be possible to mount something to the script global however by creating a spoof script?

#65

Then why are you checking script.Parent? That makes your proof of concept with getfenv rather lame.

#66

because getfenv(2).script returns exploiter’s localscript, .Parent will be nil because they run in nil

#67

So there is an accessible script global that the exploiter can change the parent of.

#68

Sorry, I am not arguing if anti-cheats on the client are good (obviously they are bad). So, am I right if I understood you correctly you should change the names of all the common services that are usually used with game.Workspace instead of game:GetService(“Workspace”) and you should rely on that to catch exploiters also searching trough the scriptcontext.Error to get errors from the client?

#69

there are n ways to spoof anything, so yes it is very possible

#70

Any good scripter would use GetService anyways. And checking for errors with the console isn’t fool-proof, either. They can either disable your check or the exploit can make it so that the console doesn’t provide errors for their scripts.

#71

Yes but I can give you n amount of scripts that will use game.Workspace

#72

My games use a system where the server fires a client using a RemoteFunction to return any data, and then the server checks over said data to see if it has been tampered with or not. Surprisingly effective, I have thousands of bans from it.

so you’re relying on client which is really bad.
exploiter would do this

remote.OnClientInvoke = function(...)
print(...) -- see what you fired stuff with and then play with it
return 'what they want'
end;

and your “check” was bypassed

#73

First script I got on pastebin for speed hacks
game.Players doesn’t exist. Like this you can go on.

Close.MouseButton1Down:connect(function()
	SpeedGUI_2.Visible = false
end)
 
SetSpeed.MouseButton1Down:connect(function()
	game.Players.LocalPlayer.Character.Humanoid.WalkSpeed = SpeedValue.Text --gotem game.Players doesn't exist
	game.StarterGui:SetCore("SendNotification", {
    Title = "WalkSpeedGui";
    Text = "Speed has been set to".. SpeedValue.Text;
    Icon = "";
    Duration = "2";
})
end)
 
ResetSpeed.MouseButton1Down:connect(function()
	game.Players.LocalPlayer.Character.Humanoid.WalkSpeed = 16 --gotem again
	game.StarterGui:SetCore("SendNotification", {
    Title = "WalkSpeedGui";
    Text = "Your speed has been reset.";
    Icon = "";
    Duration = "2";
})
 
end)
#74

I think renaming the services in the game explorer is a waste of time, anybody with any understanding of Roblox programming should be using GetService anyway, but they could just open the explorer using Dark Dex which is built into most exploits and view it themselves and see the names.

Simply putting small sanity checks on both client and server code, and securing your remote events, should be more than sufficient to catch out the majority of exploiters.

#75

This only works against the lamest of exploiters. But still, that’s a good majority of them. And anything you find on pastebin is probably years old.

#76

old scripts or bad exploit developers do stuff like game.Players or game.CoreGui
renaming some services as “CoreGui” will make it error and you can detect that

#77

Nope, not how it works at all. I’m not going to thoroughly explain how an anticheat I use for my games works, for obvious reason. But it’s not as easy as that.

#78

No cap but every script I have seen up to now would fall for that (I checked the first 20 for fast walkspeed).

--another example
-- This script can be used in script builder
-- Put you name were it says YOURNAMEHERE

game.Workspace.YOURNAMEHERE.Humanoid.WalkSpeed = 100 -- Change the number to the speed you want

But catching errors is essential isn’t it? Since most people as I said will get errors when they experiment with scripts.

#79

Catching errors isn’t fool-proof. Any good exploit will hide these errors from the console and from the game itself.

#80

this is exactly how your “anti cheat” works:

server:

local data = remote:InvokeClient(player)
if data ~= 'what i want' then
player:Kick('spoofed return')
end

client:

remote.OnClientInvoke = function()
return 'what i want'
end;

^