ROBLOXCRITICAL Take Control of other Characters, even with FE

This issue primarily became a concern due to the injection of a “rape script” in may game. I recognize that some of the content of this post is mature, but we have to face it since it is a real issue. Also, anyone who knows me knows I don’t ever rant. While it is not my intention to do so, this post is wordy and passionate and may come off as a rant, but I think it appropriate because some of my younger players have been traumatized.

Clients have the ability to affect the characters of other clients, and remove their control. They simply set another player’s PlatformStand value and weld that player’s character to their own–and the other character can do nothing about it. It seems whosever HumanoidRootPart is at the higher altitude remains in control of movement and the other player is left helpless. Why is this even possible? Filtering should keep clients from affecting any attributes of other characters!

The aforementioned “rape script” emulates just that: a player can inject it, provide two usernames (supposedly doesn’t even have to be their own–I haven’t confirmed but I know it works when one of the names is their own) and it PlatformStands one character, and welds the two together in an inappropriate position. The result even includes movement (via changing Weld.C1s, no Animation objects involved) and additional [body] parts. The most troubling fact is that it replicates (except the parts, I think), and the other player completely loses control of their character.

Since our game recently went free and took the #1 most popular slot, you can bet all the dorky little exploiters swarmed in to mess with our players. I received a copy of the script itself from one of them. It’s so old, it still sets the “formFactor” of the parts it creates. It’s sad that we haven’t improved security over time.

Not to mention that script security in and of itself is a joke. LoadstringEnabled may stop the simpletons that create malicious free models, but there are more sophisticated exploits out there. Those who know what they are doing can write a program that combs memory until it finds the LuaState, at which point they can run whatever arbitrary code they want. They can even insert new global functions written in C that do things like save the replicated portion of the place to disk. They can also access all the opcode sources for your LocalScripts and replicated ModuleScripts and decompile the source. Even variable names are preserved.

I have worked around the client Lua vulnerabilities to the best of my ability, so I’m not exactly asking for a security overhaul here. It would be nice. I would be incredibly grateful for it. I would be able to sleep at night knowing that every update I make, there’s not somebody picking it apart to maintain the viability of their exploit. But honestly, at the very least, we need to prevent Humanoid and Joint changes in other characters from replicating while Filtering is enabled. Thanks in advance to the client team.

Edit: Here’s a link to a gif, discretion advised. The arms are welded the wrong way, which indicates it was probably designed before packages were a thing.

Edit: I refocused the goal of the post and adjusted the title accordingly, as suggested.

3 Likes

That’s a hell of a title. It’ll grab attention, I’m sure, but it’s not really the point of the thread, so you may consider generalizing it. This is an on-going issue, and if you can replicate it properly (which you seem to have, mostly) it’ll help them immensely.

As far as the script goes, I recognize it from script builders from like 2011/2012, so it’s most certainly not new, and from the looks of things it’s not been updated really at all. We’re just gonna have to accept that it exists and ban users as they use it.

I find the hackers’ sense of humor and priorities more concerning than the hack itself.

1 Like

Do you have any more information about how this exploit works? PlatformStand is filtered when FilteringEnabled is true so the value will not replicate from client to server.

You need to recheck this specifically - it is something I had to prevent on my new FE game.

Turning off these states entirelly is the best solution if you don’t need them.

There should be a fix in place at the moment. Let me know if you have any more issues with this.

Also, let me know if there are any issues involving welds in FE games.

1 Like

Or at least a fix might be in place. There was a player drop that should be unrelated.

ah, so this game was the cause of the player drop. The fix has been re-enabled.

Was going to permban this guy from my game, turned out he was already permbanned by the system for trying to hax himself some highranking weapons XD

2 Likes