Whilst my games haven’t been affected by this yet, there isn’t a topic made for this exploit and I’ve seen it happen to various servers in the game “Galaxy” by @rcouret
There isn’t a way to patch this without replacing the Humanoid object as far as I know as it is controlled by the client and is replicated to all other clients, a patch for it on Roblox’s end would be appreciated.
Basically, exploiters can use :LoadAnimation on their character intending for it to error instantly (Thus it can’t be stopped via whitelisting animations as far as I know), this error then gets replicated in the developer log of All other clients and the server which means that exploiters can lag out a server and/or players.
Not only that but they can include a message via the title of the animation which can be offensive.
Using :GetPlayingAnimationTracks won’t work as the animation never plays.
Replacing the humanoid with an alternative is a idea that would work but it’d be easier if it was simply fixed.
local Message = ""
local anim = Instance.new("Animation", game.Players.LocalPlayer)
anim.AnimationId = string.rep(Message .. " ", 50) -- if you don't do string.rep with a math.random it will also work but every server u join u will be able to execute only once
local loadanim = game.Players.LocalPlayer.Character.Humanoid:LoadAnimation(anim):Play()
wait()
anim:Destroy()
Making the error client side only would probably be the easiest way to fix it, although given that animations played via a clients humanoid play across the server, protections against that would probably need to be put in place also.
Please flag a Lead Top Contributor to have this moved to the Exploit Reports section. In general, there is a specified process for New Members to submit bug reports, feature requests and exploit reports.
As well, this is a public section of the forum, so avoid adding any images that have inappropriate content in them. Even if it is to add to your thread, this is not appropriate for public viewership.
Sorry, I thought the inappropriate images had the blur tag on it but the formatting didn’t work.
And I must have skipped over that section as I couldn’t find a exploit report category and didn’t know where else to post it. Will contact them now.
Adding the blur tag would still not make it acceptable for these images to exist on a thread that is publicly able to be viewed. The blur can be unveiled through a click.
The Exploit Reports category is not public. It would be helpful in the future if you contact Lead Top Contributors in creating posts intended for the Platform Feedback category (which requires their review first before its moved over).
This should stop some of the more noobish exploiters. Just put it in a server script.
local Players = game:GetService("Players")
local bans = {}
local function isBanned(id)
for _,v in next, bans do
if v == id then
return true
end
end
return false
end
Players.PlayerAdded:connect(function(player)
if isBanned(player.UserId) then
player:Kick("Banned from server")
end
player.CharacterAdded:connect(function(character)
character:WaitForChild("Humanoid").AnimationPlayed:connect(function(a)
local id = a.Animation.AnimationId
if id:len() >= 50 then
table.insert(bans, id)
spawn(function()
pcall(function()
player:Kick("Animation overflood")
end)
end)
player.Parent = nil
end
end)
end)
end)
Tested this out, apparently it does detect the played animation even if it errors instantly.
Not sure why your banning players based on the animation Id.
The error would still be able to happen I believe if the player is taking a while to load and the clients animation fails to load which could trigger a false positive? And you can simply randomize the length of the animation Id or input a id that mimics a legitimate one.
But for the moment at least, that should help.
Just seems like a strange thing to let the client play any animation they want and have that replicated to the server and all clients by default in FE games.
I have not seen the script error yet due to a laggy player and give off a false positive with this yet. This exploit is one which has been around a while now and this script was created to directly combat a certain script which some exploiters were using.
Fair enough. While it feels like something roblox should patch as basically All developers are going to have to implement it at some point, if it solves the problem at hand then it solves the problem at hand.
This issue is nothing new, I’ve known about this for quite some time.
From the testing I’ve done I haven’t discovered anything that could lag a server or even players with this method, I’ll most likely do some further testing at some point to try and confirm this.
This exploit works (or worked) as of a couple weeks ago which is after the debut of the new dev console. The trick is to put it on a very large loop and because it replicates it will begin to cause massive lag within 10 seconds. I can provide the script used by the exploiters which prompted the creation of this script above if necessary though I see that this is not the area to do it. If you are interested for testing purposes only here is my tag th3l00neym00n#6682
Since this game breaking issue is still not addressed (tested it 5m ago, still effective against my repro game), I have provided a solution that will work for most of the exploit code.
It’s made to be more efficient than checking every animation for errors. If exploiters decide to add in countermeasures, a less efficient but more effective version can probably be produced.
local Players = game:GetService("Players")
local _NO_OF_STRIKES = 3 -- Number of strikes to give them before kick.
local ThreeStrikePolicy = {}
function IsARealAnimation(Id)
if not typeof(Id) == "string" or (not Id:match("rbxassetid://") and not Id:match("roblox.com")) then
return false
end
return true
end
Players.PlayerAdded:connect(function(Player)
Player.CharacterAdded:connect(function(Character)
Character:WaitForChild("Humanoid").AnimationPlayed:connect(function(Track)
local Id = Track.Animation.AnimationId
if not IsARealAnimation(tostring(Id)) then
if not ThreeStrikePolicy[Player.userId] then
ThreeStrikePolicy[Player.userId] = 0
end
ThreeStrikePolicy[Player.userId] = ThreeStrikePolicy[Player.userId] + 1
if ThreeStrikePolicy[Player.userId] >= _NO_OF_STRIKES then
Player:Kick("AntiExploit Detection")
end
end
end)
end)
end)
@ConvexHero Do you know if this is being investigated? Cheers!
Progress is being made towards a fix, slowly but surely, t’was reported a good while ago.
That patch will work for some cases but it can quite easily be bypassed still.
