Help with Hopperbin Anti cheat

Hopperbins

Hello. My game is currently being exploited and people have mentioned ‘hopperbins’. I have made another post about the issue, but this one is focused on hopperbins.

I’ve searched around the internet to look for any info, but most forums about hopperbins are just exploiters trying to bypass existing anti cheats for it.

This is what I already know about hopperbins:
-They are deprecated, and they were an alternative to tools
-That’s pretty much it

Can anybody please help me out on making a good script that can remove hopperbins right after they’re spawned? I know I could do this with simple code in a localscript, but people who know what they’re doing could just delete the localscript in seconds.

1 Like

No, a HopperBin anti cheat won’t do much.

As you said, a HopperBin is just the old implementation of Tools.

They have no handle and could be one of many types:

  • Scripted - Similar to tools
  • GameTool not sure what this is
  • Grab - Move parts
  • Clone - Duplicates parts
  • Hammer - Deletes parts

See here: BinType | Roblox Creator Documentation

Not sure what HopperBins have at all to do with exploits other than exploiters using them as an interface for other exploits but it really is no different to a DEX explorer or panel of sorts.

1 Like

Thank you for your response. The exploiters using hopperbins were somehow able to delete terrain and lag the server.

Okay… that should not normally be possible.

Check youe game for any free models you have previously inserted and make sure that all your RemoteEvents/Functions are secure.

There is no way for a HopperBin to delete terrain AFAIK and no way for terrain to be deleted in the first place from the client without server (script) intervention either.

Interesting. The information given to me before could have been false to make me scared. I am right now working on securing all of my remotes. (you know, making them do more security processing and stuff)

Do you know anything I can do about immediately removing the hopperbins when they’re inserted into the game without the localscript doing it getting deleted by the injector? Of course I know there always is a way for the exploiter to get around any type of anti-hopperbin localscript, but it’s good to start somewhere.

Its not worth making a Anti hopperbin anti cheat as they can easily bypass it and
use their mouse to script detection just as hopperbins do just while equiped

if you dont really care about it you can use remote events and a local script to detect when a hopperbin was added in the local players instances (Backpack , character ect…)

using the remoteevent (which can easily be blocked) and sending a request to kick the player
as local scripts kicking the player are just not useful and even more easy to bypass

Okay, thank you. My current plan is to place random localscripts in spots around the client. Those little scripts immediately clone 10 versions of a hopperbin detector script and randomly places them in places where localscripts can be hidden inside random instances. Those cloned scripts are named something completely random. All of that happens right when the client loads in and the scripts that originally do the cloning immediately destroy themselves.

I understand this can be bypassed, but do you think this is a good start? I don’t plan on spending too much time on a hopperbin bypass, but I need to implement something.

if you really want to hide your anti cheat
the best way would be doing this

script:Destroy()
-- Your anti cheat script

you might think this will stop the script but it wont since its local and for some reason it doesn’t stop itself and its well hidden.

sadly this is still bypassable but it would be way harder and have a better performance than the idea you have.

Thank you for this. I’m sorry if I’m starting to ask too much but do you know how a deleted script could be bypassable? I think I’m going to leave this part of the anti cheat where it is cause it’s on the client but I’m just curious.

exploits have a custom function to check for nil instances and they can pretty much delete it or disable it from there or hook it to be still running but edited
i dont know how it does it but most people dont check for nil instances.

1 Like
local __PLAYER = game:GetService("Players").LocalPlayer
local __BACKPACK = __PLAYER:WaitForChild("Backpack")
local __HTTP = game:GetService("HttpService")
__BACKPACK.ChildAdded:Connect(function(__CHILD)
	if __CHILD:IsA("HopperBin") then
		__CHILD:Destroy()
		task.delay(1,function()
			if __BACKPACK:FindFirstChildOfClass("HopperBin") then
				__BACKPACK:FindFirstChildOfClass("HopperBin"):Destroy()
			end
		end)
	end
end)

coroutine.wrap(function()
	while true do
		task.wait(0.5)
		script.Name = __HTTP:GenerateGUID(false)
	end
end)()
--script.Parent = nil, maybe?

like this?
hopperbins are also called Hammer, so you might look for that too.

Updated the script to make it a bit better

lol? name changing = bad? lol? you just made it more vulnerable to getnilinstances()
the purpose of name changing is to hide it more, a lot of games use this method to hide their remote events and such lol…

What’s the purpose of making everything a metatable? I am pretty new to those and I don’t know much about them. I do understand how they work and function, just wondering why they’re used here.

They’re not metatables, it’s just my way to name variables, you can rename them.

Does it make it harder to identify the variables?

there is no diffrence as they can see it as like you can in explorer
leaving it normal will make them believe its natural atleast as natural as it can be

and im not trying to say its bad or anything but its not helping in this situation

not rly, all syn decomplied scripts start with
I__Service__Num

name changing makes it harder to find lil bro, all games use this method and its a known prevention beacuse without name changing they can just
and dont say they can also use IsA() beacuse it wouldnt work if you have multiple localscripts in nil.

 for _,v in getnilinstances() do
       if v.Name == "antiexploit" then
           v.Parent = game:GetService("Players").LocalPlayer
      end
end

as said you dont call you antiexploit script a “antiexploit” rather than localscript itself or the default name.