Sirhurt exploit detector

Resources Community Resources
#1

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
Community Resources Rules are vague and requires changes
#3

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
#4

average client anti exploit developers be like

31 Likes
#5

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

8 Likes
#6

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
#7

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

13 Likes
#8

Step 1:

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

Step 2: ???

Step 3: Profit.

8 Likes
#9

me when me when no getnilinstances() me when

9 Likes
#10

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
#11

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

2 Likes
#12

“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
#13

The sir hurt developers after removing 1 line of code
image

29 Likes
#14

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
#15

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

2 Likes
#16

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

local nilinstances = getnilinstances()

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

Let’s not forget autoexec at the corner.

3 Likes
#18

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
#19

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
#20

What is destroying an already nil instance going to do?

2 Likes
#21

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

5 Likes