Exploiters hijacked my game and are crashing it for others using an FE Enabled script with the character in demand that I TP my players to their game

Help and Feedback Scripting Support
,
#1

A new exploit has been attacking games and has recently attacked my game, all info I have about it is that it shuts down games using tools or the character of the player somehow

This is their game: not done - Roblox
These are their groups: Kiso-shi - Roblox , B&D PROJECTS - Roblox

What it looks like to other players:
Exploiter loses their right arm (the one that holds tools) and glitches beneath the map, the game lags, and EVERYTHING is frozen eternally. so we have to shut down.

people walking in place, dialogue and commands delayed, etc.

Games I know who were affected by this: After the flash

What my temp solution is: Ban the groups that the accounts come from

I am so thanful for an idea on how to fix this, if anyone knows a patch please send it for all of us in the comments, they are holding my game hostage so that I tp my players to their game :confused:

4 Likes
#2

This is due to mass cloning of a object that replicated to the server. The only way to work around it is use a solution like this:

Or just use custom tools that don’t use the default tool object.

Also, if people are threatening you to send players to their game, report then for harassment, ban the harmful players, and don’t teleport them.

1 Like
#3

I tried remaking his code but it gives me an error that I can’t parent parts to the workspace (Must be a partInstance)

This was my code:

local RunService = game:GetService("RunService")
local Character = game.Players.LocalPlayer.Character
local RightGrip = Character["Right Arm"].RightGripAttachment

RunService.RenderStepped:Connect(function()
	local a = RightGrip:Clone()
	a.Parent = Character["Right Arm"]
	spawn(function() a.Parent = workspace end)
end)

Could you elaborate as english is not my first language and I have defecuiltys understandting people, thank you :slight_smile:

They keep harrasing me with new accounts that even if I reported them they would still crash my game

1 Like
#4

Try to create a script which tracks children added to Workspace and if they are named “RightGrip”, get a character from weld’s Part0 (RightGrip.Part0.Parent). Then get a player from character (Players:GetPlayerFromCharacter(Character)) and take an appropriate action (ban / kick. Whatever)

After that run a function in coroutine (to have slight delay) and destroy exploited weld since it isn’t removed automatically.

This is what should prevent that.

About your script - the weld is not called RightGripAttachment. It’s “RightGrip” and it’s only available when you have tool equipped.

5 Likes
#5

A simple solution to end exploiting for at least a year or two would be making the Roblox Client protected so that external processes cannot interact with it.

In a sense, all current methods access the Client in some way to enable exploiting to be possible, so just locking down the Client process would be a fix that would work for quite a while.

1 Like
#6

You should start working at roblox :slight_smile:

1 Like
#7

This is my code, please rate it

workspace.ChildAdded:Connect(function(Child)
	if Child.Name == "RightGrip" then
		game.Players:GetPlayerFromCharacter(Child.Part0.Parent):Kick("Not cool, You tried to duplicate parts to the workspace.")
		Child:Destroy()
	end
end)
1 Like
#8

It would, but that’s impossible to do. Roblox already takes a lot of steps to protect client, but user will always be able to manipulate the process. Its just like a cable in real life. You may cut the wire and do whatever you want with it.

1 Like
#9

Add Child to coroutine or spawn function, place before kick method and it should do the job. :+1:

1 Like
#10

This would definitely help, but just make sure that:

  1. It is compatible for both R5 and R15/Rthro rigs,
  2. There is a decently high threshold but not too high for false detections
  3. Lastly, add a failsafe that requires at least 2 detections before action is taken, just to further prevent false positives.
#11
  1. Yes
  2. There is no possibility for false positives here
  3. Not needed. Roblox never places that weld in workspace
1 Like
#12

I see where you are coming from, however this would just ensure that in the rare case that there is a false positive, it wouldn’t be an issue, and also futureproof for any future workspace related edits/new features.

If it doesn’t happen that often, then it shouldn’t be an issue to add it in just for futureproofing reasons.

#13

it would just kick the player so nothing really bad

1 Like
#14

In that case, adding preventative measures now would save you the time in the future that it does happen, and you have to debug and edit the issue.

#15

Sorry but I see no sense of your words.
There is TOTALLY no possibility that Roblox places weld in workspace itself unless it’s affected and controlled by exploit.

Roblox ALWAYS adds it to Right Arm in both R15 and R6. When exploiter moves its to Workspace, it’s automatically detected. No false positives involved.

There are things that could have false positives due to lacency but this case is not a subject to them.

Tl;dr. Please reconsider that and remove the posts since they introduce chaos and share misinformation.

1 Like
#16

How do i add spawn function before the kick? Could you further explain please

1 Like
#17 
workspace.ChildAdded:Connect(function(Child)
 	if Child.Name == "RightGrip" then
local Player = game.Players:GetPlayerFromCharacter(Child.Part0.Parent)
spawn(function() Child:Destroy() end)
Player:Kick("Not cool, You tried to duplicate parts to the workspace.")
 	end
end)

Sorry for the formatting. On phone rn. Hard to edit things.

You can test it by equiping a tool in studio play solo test and moving RightGrip (parented to Right Arm) to Workspace. Will result in kick.

1 Like
#18

why do we need to spawn the function instead of just destroying the child after the player is kicked?

2 Likes
#19

It’s better to do because:

  1. Kicking client does not clear up the rightgrips in workspace
  2. Not adding spawn won’t destroy the instance, would show warning saying words around “Parent is being set to nil when its meant to be workspace” (Roblox would think it’s fault)
  3. Spawn does not affect the kick function. Kick is a network engine function. I usually like to wrap those into pcall just to prevent errors which would stop the rest code, but pcall has slight delay. In this case I just decided to have it at the end to make sure child is removed before clients manage to replicate it and the kick is not delayed.
3 Likes
#20

Perfect, I learned something new :slight_smile: thanks to everyones help

3 Likes