Sentinel Universal Anti-Cheat Release

This detection doesn’t work anymore, you can’t listen to the descendants or childern added to coregui.

This looks so good! I’m definitely using this for my next game!

Thanks a lot for this great resource :slight_smile:

you should probably delete that last part of what you said because no matter what the reason is you’ll get banned anyway :grimacing:

seriously though just get some kind of ingame gui that executes things through the client and bam, it’s just like an exploit without actually breaking the tos. stop exploiting.

I hate when people say “use a in game gui = exploit” as it shows how ignorant they are of the subject

In a nutshell, exploits run at a higher security level than any script that a developer can create, hence testing popular exploits for your game that most likely use things that only high security level things can access (+custom functions that an exploit can provide) won’t work

This method is no longer working, and you shouldn’t be checking the core GUI or any other services set to RBXScriptSecurity in this way. They are going to break and also break your anti-exploit.

Plus, there’s no GitHub repo so we can’t even check the source…

Side note

Please don’t advertise your anti cheat solutions here @AsynchronousMatrix

Hate it all you want, but it’s true. Sure some features will be missing like dOwNlOaDiNg gAmEs, but it gets the job done. It executes code in the client.

What else do you recommend? Buying an exploit and break the TOS risking to get banned? Just stick to the safer method that gets. the. job. done. no matter if it has less or more features than the real thing.

From what I can tell regular scripts run at a security level between 1-2. What security level do exploits run at?

Hooking functions, accessing protected services, accessing protected methods, etc. A local script can’t do any of this, hence why an exploit would be required

Again, as I mentioned, sure, some things are missing from LocalScripts. Still if you’re just looking to test out the functions of specific things like exploit GUIs for example, just run the code but make it parent the GUI to the PlayerGui instead of the CoreGui, or example.

Now stop talking about how exploits are superior to localscripts because we get it, but we’re not going to buy some random program that breaks the TOS just to test some features, and risk getting banned.

I believe they run at the maximum level which is RobloxScriptSecurity. This level is what protects the CoreGui and other functions such as Player:SetAccountAge()

1 Like

I see a lot of the checks are on the client, what stops an exploiter from removing the client scripts entirely to bypass the checks

Yeah this anti-cheat is pretty basic, name changes are simple and all of its big selling features to people are legit client based.

I would wait for my new anti-cheat to release here soon.

I kinda doubt they have RobloxScriptSecurity because I think Roblox has some protections on the engine against getting RobloxScriptSecurity as CoreScripts are the only kind of scripts that can execute this of kind code. Also it was mentioned by a staff member in Script RunContext post that the property RunContext can only be changed from studio or plugins as a extra security measure so this is proof that exploiters can’t have that high of a Security Level.

IIRC, it might be LocalUserSecurity then.

1 Like

The reply you quoted referenced changing how a script runs (server script v localscript) through a property with Roblox Luau script code, which has nothing to do with a script’s security level. Exploits can very easily change a script’s security level because they have direct access to the client’s memory, and can also very easily call a CoreScript function by getting it’s memory address (or by overwriting a CoreScript, or just by registering their own).

Exploits have more power than CoreScripts themselves, they have direct access to the engine and it’s memory values, so could theoretically do stuff like create custom shaders or manually set how often the physics engine runs if they really wanted to.

1 Like

This doesn’t work. An idea I have would be

local Services = {
	game:GetService("Players"),
	game:GetService("ReplicatedStorage"),
	game:GetService("ServerScriptService"),
	game:GetService("Workspace"),
	game:GetService("StarterGui"),
	game:GetService("Lighting"),
	game:GetService("UserInputService"),
	game:GetService("BadgeService"),
	game:GetService("TweenService"),
	game:GetService("ServerStorage"),
	game:GetService("ReplicatedFirst"),
	game:GetService("TeleportService"),
	--Here you keep adding all of Roblox's services that are accessible with game:GetService()


}

game.DescendantAdded:Connect(function(descendant)
	if (not table.find(Services, descendant.Parent)) then
		-- ban player
	end
end)

I’m not very good with scripting so the script might not work, but I think it could be modified to work a bit better

also anticheat model is offsale

Listening to game.DescendantAdded isn’t a good solution in general. It’s going to fire a lot and just be more of a hindrance to performance than anything else. Player’s character is added? That’s instantly tens if not hundreds of instances alone and thus tens to hundreds of function calls in a single frame. CoreGui descendants aren’t indexable anyway by LocalScripts as per version 527 so I doubt this solution would work anyway:

https://developer.roblox.com/en-us/resources/release-note/Release-Notes-for-527

If it does still work, I am certain that at some point Roblox will patch it. CoreGui isn’t intended to be accessed at all by the developer.

Your script also has a false positive, more often than not an instance is not a direct first-level child of a service, so you’d have to iterate through all of the services and check if descendant:IsDescendantOf/descendant:FindFirstAncestorOfClass whichever service. Since there apparently 45 services and this number is increasing, that’s 4500 descendant checks if an instance with 99 children is added to the game. It isn’t foolproof either, what about nil instances?

I’m all for honeypotting and catching dumb exploiters who think a remote called “GiveMoney” won’t ban them, but it does become problematic when these client-sided checks start causing performance issues.

2 Likes

this is just going to ban anyone that joins lol