Hey DevForum users,
So recently I was playing Da Hood and had multiple servers lose connection and I quickly realized that cash was being duped by having one person drop money to another player then having the other player leave so their data updates but keep the person who dropped the money in game so theirs doesn’t update. The person who dropped their cash doesn’t leave but they instead crash the server so their data doesn’t update. The person who drops it gets their money back and the person who left keeps the money. These exploits are universal so they can crash any game with a tool. For obvious reasons I won’t be leaving a script to crash games but I will explain how it works. Exploiters equip a tool around the amount of 2000/s which lags the server and players. This causes frame drops, major increase in ping, and data store loss. To prevent this without using an Anti Crash [which I don’t recommend not using one] make sure to update the data store after doing important things such as trading, giving money, or stealing from another player. Below is the script that will stop this exploit.
game:GetService('Players').PlayerAdded:Connect(function(player)
player.CharacterAdded:Connect(function(character)
local toolCount = 0
character.ChildAdded:Connect(function(instance)
if instance:IsA('Tool') then
toolCount = toolCount + 1
end
end)
while wait(1) and character:IsDescendantOf(workspace) do
if toolCount >= 250 then
player:Kick('Tool Crash')
end
toolCount = 0
end
end)
end)
Feel free to change the amount lower or higher than 250 depending on what works but the typical person can’t equip a tool more than 10 times per second so personally I wouldn’t change it. I don’t recommend making it ban a player unless you change the amount to 500 or above because players can use a macro to equip tools very fast and it will not crash unless they are using an exploit because it is not fast enough from my tests on it.
There is a testing game you can feel free to try out or edit it because it is uncopylocked.
That’s crazy, I didn’t know this was possible. Thanks for posting about this and informing us!
Honestly, if you’re going to use the code, I would set it to ~15 tool swaps a second, there’s no need for someone to try to equip more than 8 tools a second, let alone 15->=250
Thanks for the reply,
I do think 15 would be good for a kick but if you are to ban I would go for 350-500 because players can use a macro to equip tools fast which doesn’t affect your game. This is simply just for an anti crash but feel free to use any amount higher than 10 and you should be fine.
This is a good method, but your code has a leak. Every time a character spawns you create a new while loop, and this loop never stops even after their character despawns. Not only does this create a minor performance impact after thousands of spawns, but the while loop keeps parent scope alive as well. The parent scope has a reference to the character, which will prevent the character from ever being garbage collected. I recommend adding a second condition in the while loop checking if the character is still a descendant of workspace.
while wait(1) and character:IsDescendantOf(workspace) do
if toolCount >= 250 then
player:Kick('Tool Crash')
end
toolCount = 0
end
There are bigger issues in the Roblox engine relating to tools that this issue stems from.
Currently Roblox has a bad replication behavior that allows equipping multiple tools. (This can sometimes be usefull but 99% of the time is problematic).
An alternative approach to solve this issue is simply making a script that only allows equipping one tool at a time.
There are also a lot of other bad Roblox replication behaviors. I’m sorry to advertise this again but I feel like I need post my resource here which fixes a lot of problematic Roblox replication behavior (Including this tool crash thing) [FE++] Best server sided non physics anti-exploit for your Roblox game!
You should also beware of SoundService.RespectFilteringEnabled. If this property is set to false any player can play any Sound in the game, which can be used to crash the server too.
There are a lot of other vulnerabilities in Roblox replication like these
you can easily fix both by one
force the grip to the position you want (eg. grip.changed and force it to that grip)
2. just check in the server for .DescendantRemoved
you dont need roblox for this, but roblox can surely fix this
What I’d rather do is completely prevent the abbility of equipping multiple tools. This would be simply done by adding a script when a tool gets added to the character, count the tools and parent the extra tools back to the backpack.
What this effectively would do is lock the max amount of tools that can be equipped a second to 60. (Always lower because of latency at lag), because you can only equip one tool per tick and the Roblox task scheduler runs at 60hz.
Preventing this would also fix a load of other tool related exploits, or at the very least mitigate them.
What this means is that the maximum possible amount of times a player can equip a tool in a second is 60 (from the servers point of view, which is what matters anyway).
This on it’s own is not able to crash the server, it may apply some slight task scheduler slowdown but
Let’s prove this with an example, here is a script that equips and unequips a tool as fast as it can, this doesn’t result in much server lag.
local Players = game:GetService("Players")
local RunService = game:GetService("RunService")
local flag = false
local function WaitForChildOfClass(parent, class)
local child = parent:FindFirstChildOfClass(class)
while not child or child.ClassName ~= class do
child = parent.ChildAdded:Wait()
end
return child
end
local function onCharacterAdded(character)
local backpack = Players.LocalPlayer:FindFirstChildOfClass("Backpack") or Players.LocalPlayer:WaitForChild("Backpack")
local humanoid = character:FindFirstChildOfClass("Humanoid") or character:WaitForChild("Humanoid")
local tool = backpack:FindFirstChildOfClass("Tool") or WaitForChildOfClass(backpack, "Tool")
-- // Connects to the Heartbeat event which fires before Replication Send Jobs
local connection = RunService.Heartbeat:Connect(function()
flag = not flag
tool.Parent = flag and character or backpack
end)
end
if Players.LocalPlayer.Character then
task.spawn(onCharacterAdded, Players.LocalPlayer.Character)
end
Players.LocalPlayer.CharacterAdded:Connect(onCharacterAdded)
The only way one could crash the server with tools is if they equip multiple tools at the same time, which is possible.
Edit: Nvm multiple tool equip and unequip request can arrive at the same tick
Multiple equip and unequip requests can arrive within a single frame. The code you posted also does not equip/unequip anywhere near as fast as possible.
local Player = game.Players.LocalPlayer
local Tool = Player.Character:FindFirstChildOfClass("Tool")
game:GetService("RunService").RenderStepped:Connect(function()
for i = 1,100 do
Tool.Parent = Player.Backpack
Tool.Parent = Player.Character
end
end)
I believe this means it runs at 240hz but correct me if I’m wrong as I definitely could be.
Did you run a test of checking if the player has more than one tool equipped while crashing before doing this? If not why don’t we take a look shall we. DISCLAIMER
Tools are being equipped too fast for it to show up on the client.
Anti Crash is disabled for the test so I dont get kicked.
I did a quick search and discovered something called a super wait.
If you use the super wait and put the tool into the character then the backpack multiple times per super wait it would still manage to crash the server without it being more than one tool in the backpack as shown in the video. I’m sure more than one tool would help but in this situation it is not needed.
No thats the internal physics step which Runs faster than everything else. Only the physics calculations run at 240hz, everything else at 60hz
But yeah I was wrong, it’s actually possible to crash with one tool because apparently the same tool can be un-equipoed and re-quipped multiple times per tick (from the servers point of view.)
But it’s still good to prevent the equipping of multiple tools at the same time.