Anti-Btools Script | Help?

Help and Feedback Scripting Support
#22

I did give myself btools and it didn’t work, my entire script has been changed now I have no idea what the hell I’m doing

#23

This is my new bad script which doesn’t work
https://gyazo.com/18c112700f3f4b57315be054fbfe8a38.png

#24

So basically, the way I’d go about this is as follows:

--server script
--detect player entry
--detect new items in player's backpack
--is the new item titled "Hammer"?
--kick the player.

You’ll want to read through the following resources to create a solution:

  • use PlayerAdded to detect player entry.
  • access the player’s Backpack.
  • use the ChildAdded event to detect new items in the backpack.
  • compare the item’s Name to whatever you want to remove (in this case, Hammer).
  • use Player:Kick() to remove the player from the game.

Side note: in the future, please try to reduce the number of replies you post. If you want to add more information, you can edit your original post/existing replies. The devforum shouldn’t be used like an instant messager.

1 Like
#25

It’s in the ReplicatedStorage, put in the StarterPack.

#26

It worked, it kicked me when I tried to get btools! Nice!

#27

Mind marking it as a solution?

#28

I just did, both of your messages.

#29

Hello,

For somebody new to scripting it’s good that you’re already trying to practice some security! Your idea is already pretty good, however I’ll give you a few pointers on how to make your game a little bit harder to exploit. In your specific case it’s using btools.

First off, instead of kicking the player, you should instead immediately delete the tool from the player’s backpack. This saves you the trouble of having to fire a remote from the client just to kick them, and it will make it a lot less obvious that there is an anti-exploit. This is good because, if the exploiter doesn’t know there is one, it will take a lot longer for them to figure out how to get past it.

So instead of doing LocalPlayer:Kick(), just do Obj:Destroy()

Another trick you should know is having the script change it’s own name. This makes it MUCH harder for exploiters to get past it, because it gives them trouble with deleting the script. You can do this like so:

local player = game:GetService("Players").LocalPlayer
local backpack = player:WaitForChild("Backpack")
local http = game:GetService("HttpService")
local runservice = game:GetService("RunService")
backpack.ChildAdded:Connect(function(object)
	if object:IsA("HopperBin") then
		runservice.RenderStepped:Wait() -- Waits for the frame to finish. This prevents the "Unexpected parent change" error
		object:Destroy()
	end
end)
while true do
	wait(0.25)
	script.Name = http:GenerateGUID(false) -- Constantly change the name to make it much harder for exploiters to delete the script
end
7 Likes
#30

I believe that you can check for child added or descendants added on the backpack objects and check if the new item is called “Hammer”. Then, you can kick the local player from there:

game.Players.LocalPlayer:Kick()

This is bypass able by deleting the local script that checks so you should do this on the server upon CharacterAdded.

#31

I’d say that’s not very resource friendly, you should avoid loops and use events if possible, the easiest way to do this is just add a server script and check there.

#32

You can’t check for things added on the client on the server. How do people not know this?

Also, this is stupid having all of these measures, because a majority of exploiters won’t realize that this anticheat is on the client. Yeah, there’s some, but most will see they got kicked and give up. You’ve already taken care of a majority of exploiters.

Another thing you could do is hardcode this into existing scripts, because you’d be breaking existing client scripts and there would be no way around it without breaking the client side of the game.

1 Like
#33

I doubt a loop that changes the name of something uses hardly any CPU. Unless you’re polling instead of using events, using a loop in the case that a loop is appropriate like changing something every (time) seconds is fine.

#34

Oops I forgot my bad. I was mentally thinking that the tool was being added on the server. Didn’t think about that.

#35

I can disagree on that through experience. When I was younger, I used a while loop for every int value that I needed to update and I believe at 10 infinite loops the game crashed (not knowing there is a .Changed listener).

EDIT: Let’s not argue upon this anymore on this post, the question is answered. You can talk to me via messages if you wish.

#36

What if they renamed the hammer

#37

If they renamed the hammer to something else it would be able to slip through. An ideal system would simply prevent tools of any kind from being added unless they were expected, but I figured it would be a good idea to keep the example simple and to stick to the goal of the thread as closely as possible.

#38

A counter would be to create a list of Whitelisted tools and then any tool that isn’t whitelisted would be removed. Then again, if a tool is renamed to be whitelisted that could be an issue which then you can do some secret stuff to tag tools that are formatted in some way.

#39

Or you could use something that removes EVERYTHING from there inventory

#40

A class being deprecated doesn’t mean that it’ll fail a ClassName check. It would only fail if HopperBin was removed from the engine altogether, invalidating the existence of the class.

Not stupid. Assume the exploiter is capable of anything and everything. You should never allow yourself to become complacent when it comes to adding client-side anti-exploit measures (provided you did so on the server first; if you didn’t, attend to that first).

1 Like
#41

It is very simple to disable/disable this script, just iterate over the children of PlayerScripts.
2. I think that nowadays all executors have functions to disconnect connections created using Event:Connect(...).
3. The LocalPlayer:Kick(...) can easily be manipulated so that no local script can kick the player out.

Please update, you need to play both teams, I do not recommend using exploits, but look at all the new functions and updates