Backdoor on F3X Tool

Help and Feedback Scripting Support
#1
  • What are you attempting to achieve?: To remove the backdoor from the F3X Tool.
  • What is the issue?: There is a remote/script on the F3X Tool that allows the client to execute code.
  • What solutions have you tried so far?: I have tried adding a password and when the script fires the event it includes the type of F3X action but those do not work at all.

I’m thinking of changing the remote name every time it executes but that seems like a bad idea.

Oh and good lord when I was trying to fix it there was so many scripts that called the event that it got me confused a lot.

I would contact the creator of the F3X tool but they haven’t updated the tool in 2 years

(Also the backdoor wasn’t added by me or someone else the creator of the tool while making it added it and was possibly unintentional)

1 Like
#2

What do you mean? What evidence do you have that F3X has a backdoor? Are you sure you got the official one because as far as I know nobody has ever brought this up. Or im just living under a rock. Also post the code of the “Backdoor”.

#3

Let me go check real quick but I am sure that it is the real one.

#4

Yes, I just checked and the real one does have this issue.
The issue is somewhere in the SyncAPI script and ServerEndpoint script
The following code below can be run on any game with F3X that hasn’t patched this

local A_1 = "Remove"
local A_2 = 
{
    [1] = game.Players.MySQL_Syntax
}
local Event = game:GetService("Workspace").MySQL_Syntax["Building Tools"].SyncAPI.ServerEndpoint
Event:InvokeServer(A_1, A_2)
#5

Let me do some testing and Ill get back to you. Are you using the one by “GigsD4x” Thats the first one I see.

#6

Yes, I inserted that model in studio and checked the script in SyncAPI - ServerEndpoint - ServerEndpointScript.

#7

Hi there!

This is the RemoteFunction through which the client requests changes to parts from the server! The request types are specifically limited to modifying parts & do not run arbitrary code however! If you want to limit who can use the building tools, make sure to not give the building tools to players :hushed:

2 Likes
#8

I’m not too sure if other players can execute it even if they don’t have it like if for example you had the F3X tool and I didn’t I might be able to execute a script on an exploit like this:

local A_1 = "Remove"
local A_2 = 
{
    [1] = game.Players.MySQL_Syntax
}
local Event = game:GetService("Workspace").GigsD4X["Building Tools"].SyncAPI.ServerEndpoint
Event:InvokeServer(A_1, A_2)

I also made a list of every action a player can execute if they had an exploit and knew which players had the F3X tool

'RecolorHandle',
'SetMouseLockEnabled',
'Clone',
'Remove',
'UndoRemove',
'SyncMove',
'SyncResize',
'SyncRotate',
'SyncColor',
'SyncMaterial',
'SyncSurface', 
'SyncAnchor',
'CreateWelds',
'RemoveWelds',
'UndoRemovedWelds',
'CreateTextures',
'SyncTexture',
'CreateMeshes',
'SyncMesh',
'CreatePart',
'SyncCollision',
'CreateLights',
'SyncLighting', 
'SyncDecorate',
'CreateDecorations',
'IsHttpServiceEnabled',
'Export',
'IsHttpServiceEnabled',
'ExtractMeshFromAsset',
'ExtractImageFromDecal',
'SetMouseLockEnabled'

I gave it some thought and it’s not really a backdoor but it still can be abused as I’ve seen in my own game

#9

If the tool is equipped by a player, they can send requests to it (otherwise they are rejected) o-:

#10

Ah, yes I see it right here.

	-- Ensure client is current player in tool mode
	if ToolMode == 'Tool' then
		assert(Player and (Client == Player), 'Permission denied for client');
	end;

Although I don’t know what to do as my game uses F3X tool for building and I’m not too sure if your game (Buildworld?) has the same issue, if it doesn’t would you be kind enough to tell me how to fix it myself because I’d really like to resolve the issue although if you can’t that is fine.

#11

Are you looking to restrict which specific parts players can modify? I think you should be able to override the appropriate functions in the SecurityModule script to add your own game-specific conditions

#13

No, I meant the remote issue one of my players told me in discord that with an exploit they can run a script to delete any part of the game. (And possibly more)

#14

That is what the tool lets you do :hushed:

#15

So, it’s supposed to let me delete players from game.Players?

#16

I’ve had this issue as well. It looks like the only dangerous thing exploiters can do with it is delete arbitrary instances (including anyone’s Player) if they can equip the tool. I believe you can patch the tool by wrapping this code block in a descendant of workspace check.

This doesn’t completely solve the problem, but you could probably expand upon it to prevent deletion of things in the workspace that players shouldn’t be able to (ie. map, characters).

SyncAPI.SyncModule

image

Becomes:

		-- After confirming permissions, perform each removal
		for _, Object in pairs(Objects) do
			if Object:IsDescendantOf(workspace) then
				-- Store the part's current parent
				LastParents[Object] = Object.Parent;
	
				-- Register the object
				CreatedInstances[Object] = Object;
	
				-- Set the object's current parent to `nil`
				Object.Parent = nil;
			end
		end;
5 Likes
#17

I’ll try it right now and If it works I’ll mark it solved.

#18

Bear in mind you may need to expand upon the conditional check for things like parts of the map, players’ characters, etc.

#19

Ah, that will be easy.

Thank you for helping me solve the issue!

1 Like