Sirhurt exploit detector

Well sirhurt is probably the most undetected executor because whenever it gets injected it prints out a specific message “INIT SCRIPT DEVELOPER”

which you can detects by doing this:

game:GetService("LogService").MessageOut:Connect(function(Message, Type)
    if string.find(Message, "INIT SCRIPT") then
 --  put whatever you want here when detected     
     game.Players.LocalPlayer:Kick("loser")

    end
end)

It’s quite simple but only problem is that can the exploiter just delete the script?

Well if you implement an anti delete script like this:

local scriptname = script.Name -- put the name here or rewrite the code
local kickmessage = "loser"

while wait() do
	if script.Enabled then
		script.Disabled = true
	
	elseif script.Parent:FindFirstChild(scriptname) == nil 
then LocalPlayer:Kick(kickmessage) end

	
end

if you have any script improvements because I’m just showcasing possible ways to detect an exploit.

19 Likes

Don’t you think it’s a bit odd to check for printed messages? It’s on the same level as kicking players for floating while they just have poor internet connection or for pressing insert button on your keyboard

6 Likes

average client anti exploit developers be like

32 Likes

exploits can simply hook the kick function to make this useless.

8 Likes

A much better way of stopping exploiters from deleting your script is

script.Parent = nil

at line 1

Im still trying to figure out if this is satire or not

5 Likes

Normal anticheats are still shocked with this insane method! :exploding_head:

13 Likes

Step 1:

for idx, con in next, getconnections(game:GetService("LogService").MessageOut) do
     con:Disable()
end

Step 2: ???

Step 3: Profit.

8 Likes

me when me when no getnilinstances() me when

9 Likes

Printed messages don’t change often, and even if they do it won’t be something stupid like “INIT SCRIPT”, it’s just a stupid thing IcePools left in his exploit’s init script itself and forgot about it later.

6 Likes

What you gonna do call :Destroy() on a nil instance?

2 Likes

“Oh yeah a client anti-cheat this is gonna be so useful and unbypassable because exploiters have no control over the client and this will definetely not backfire!”

2 Likes

The sir hurt developers after removing 1 line of code
image

29 Likes

You can still disable and mess (change upvalues, etc.) with scripts parented to nil, and even if you do put the script in coroutine you can do:

7 Likes

Just do regular print statements and see if the connection works, i made a horrible script to test connections once also :GetLogHistory()

2 Likes

there is this function named getnilinstances() and they can put this

local nilinstances = getnilinstances()

for _, v in nilinstances do
   v:Destroy()
end
3 Likes

Let’s not forget autoexec at the corner.

3 Likes

GetLogHistory can be tampered, print checks can be avoided, relying on MessageOut for security is weak by design and will be bypassed no matter how many checks you’ve implemented, I don’t mean to harass you - relying on security systems that have been made out of obscurity and using features that haven’t been designed for exploit detection will always fail you and hence I post bypasses for everyone to see how easy it’s to get around them.

6 Likes

Scripts can still keep running even when Destroy is called on them (using coroutines or loops), but yeah, nil parenting provides the same security as parenting the script to somewhere else: none.

2 Likes

What is destroying an already nil instance going to do?

2 Likes

For SirHurt if it prints upon injecting then that gets detected then it’s already game over

5 Likes