[DISCONTINUED] Custom Character || A further measure to prevent character-based exploits

Resources Community Resources
, , , ,
#1

We all know we can’t trust Roblox entirely with client-sided changes.

Exploiters run rampant among all games, mindlessly copy+pasting common scripts that can be detrimental to the gameplay experience of others.

This is where Custom Character comes into play!

How it works

Normally, on Roblox, you have player.Character to access the player’s character and therefore change properties. This opens up a door with no lock for exploiters, which only makes the life of many devs harder.

Custom Character does the following things:

  • Uses a blank StarterCharacter with no Humanoid, Script, and only one RootPart. This is not the character that can be manipulated.
  • Uses a custom character model, found in ServerStorage, as the player’s character.
  • Names the custom character model to Player.UserId.
  • Uses custom movement and camera controls and server-sided checks to make sure no Humanoid changes are present.
  • Gives network ownership only to the HumanoidRootPart.

The combination of all of these things will prevent existing esp, hitbox expansion, aimbot, walkspeed/jump changes, display name changes, and more!

However, this does not prevent game-specific exploits for your game using this system. Make sure you keep up with V3rmillion to ensure your game does not have scripts bypassing this system.

Installation

You can find the system in this place file:
CustomCharacter.rbxl (121.3 KB, V2)

Previous Version:
CustomCharacter.rbxl (110.5 KB, V1)

It’s up to you to integrate it into your current games and future ones as well.

Characters can be found using this line of code:
local Character = workspace:FindFirstChild(player.UserId)

Updates

Most recent updates:

  • Fixed a bug where you couldn’t respawn
  • Added animation, and integrated the entire system into the PlayerScriptsLoader script in StarterPlayerScripts.
  • Fixed some replication issues
  • Added health syncing for StarterCharacter and BaseCharacter.
  • Slightly improved security measures (although it’s on the client, so unreliable)

Planned updates:

  • Removal of Humanoid and/or HumanoidRootPart. How this will be achieved without disturbing the development process and framework of other games is under planning process.
  • Avatar appearance loading
  • Custom manipulation of characters your wouldn’t normally be able to achieve with the standard character system.

This system is currently in PRE-ALPHA. This system is untested in larger projects and is subject to glitches. However, with the way it is set up, this is unlikely.

Updates will be delivered based on the number of users that report using it. The more users that have this system, the more it will be updated.

Attribution/Credit/Terms

This system is currently free, but that is subject to change in the future. I will make changes I deem fit.

While not under an official liscense, I request some sort of credit is noted in the game description, devforum, or in-game. Doing this will help me out a lot.

You may change the system to fit your needs, but please do not distribute it without crediting me for the original. Re-distributing it without credit will result in a report flag and personal contact of RBX moderation.

I appreciate you reading this!

Do you think this system will go over well for games? Are you using it yourself? Or maybe the code needs some optimization? Let me know in the replies below!

Replies give me a better idea as to how well the system works and what needs to be improved.

Thanks!

32 Likes
#2

I am curious about this. How does the aimbot prevention work?

2 Likes
#3

I don’t believe it does. He says “prevents common exploits” because he’s using a different type of character so that exploits made for the default humanoid character won’t work. I don’t think this will prevent anyone from using aimbot, esp, etc made specifically for your game or any aimbot that accounts for this type of character.

5 Likes
#4

@rek_kie @fireboltofdeath I’ll explain in more in-depth.

By “common,” I am referring to scripts that use the default player.Character. Because this character system does not use that, all of those exploits would automatically be prevented.

Players will also only have Network Ownership over the HumanoidRootPart to prevent certain physics and network ownership exploits.

In addition, there are server-sided checks on the Humanoid to prevent blatant property changes such as WalkSpeed and DisplayName.

However, exploiters can eventually discover how characters work, but can’t use common hubs and scripts to do what they wish. It will force them to create game-specific exploits; when patched, it will be even harder to create exploits.

This simply prevents script kiddies from existing on your game(s), which helps reduce hackers by the hundreds or even thousands.

More updates will be released that do embedded checks on Camera.CFrame, input, and server/client differences.

#5

When exploiters change the Walk speed it doesn’t replicate to the Server and iirc StreamingEnabled relies on Player.Character for it to stream properly.

#6

In addition, there are server-sided checks on the Humanoid to prevent blatant property changes such as WalkSpeed and DisplayName .

yeah, no.
when they edit those properties it does not replicate from client to server, that is exactly the reason to have a clientside anticheat

This simply prevents script kiddies from existing on your game(s)

no, it really doesn’t

1 Like
#7

No, that is the reason that you use different methods to flag abnormal physics behaviours in characters rather than rely on the properties. Client-side anticheat isn’t trustworthy and can be bypassed. The server should be the single point of truth for characters, not clients.

That being said, I’m dubious about the usefulness of this resource even then. It seems like a lot of work to make a custom character just to prevent existing exploits, only for exploits to be tailored to this character system. It doesn’t resolve anything, just stalls things for a bit.

It’s better to create a custom character because you actually have functional value for doing so, such as getting rid of the expense of Humanoids and having a higher degree of control over characters. I do not recommend using custom characters just to void exploits because the same vulnerabilities still exist just with different steps to breach.

3 Likes
#8

WalkSpeed does replicate to the server, and I’m not too sure if DisplayName replicates

#10

Display name doesnt replicate.

#11

I’m a bit curious of how this prevents ESP? If the player only has network ownership of their own character and is still able to use ESP how does that work? I’m not familiar with how those scripts work currently.

Also, I’d like to use something like this in my project but because of the scale and the number of players we want, I feel like this would create more performance issues than the default character system or one like Vesteria which is completely custom with no humanoid.

1 Like
#12

@ItsJustFahed @JC_D3nt0n @0x6e7367 @Fledgeon

Correct. I don’t do a direct check.

Yes and no. The point of this is to be a further measure in preventing already-existing scripts that can harm your game. Of course exploiters can create game-specific exploits for this, but they should be farily easy to patch up.

Current ESP scripts use player.Character as a way of finding characters. Special ESPs can be created for games like this, but can be easily patched.

This was made with large-scale performance in mind. It should work, but I will need to update it first to add a few more security measures and features.

That being said everybody, I want to note that this is receiving updates to push security measures further and to include more features. I recommend you take a look at the place file and leave direct feedback on it, rather than replying without proper context.

1 Like
#13

There exists ESPs that just search the workspace for everything with a Humanoid or HumanoidRootPart in it. They created these for games that rely on enemy NPCs. It would appear this thread operates under the assumption that every ESP relies on player.Character, when there are popular ESPs that don’t.

I agree with what some others have said in this post. This would require a bunch of time and work for something that would take a fraction of the time to bypass. The much more effective alternative would be to focus on mitigating Camera CFrame manipulation - similar to that of Phantom Forces (PF). I would argue the preventative measures in PF have been much more effective than implementing a custom character.

#14

orrrr you can just put instead of their character go get their userid and tostring it and boom ez character

#15

Good point. I’ll make some edits for that.

#16

@rek_kie @fireboltofdeath @ItsJustFahed @JC_D3nt0n @colbert2677 @0x6e7367 @Fledgeon @LowPolys @A1_exe @SeemSuusy2 (Pinging those who replied)

I’ve updated the Character System and this page to match appropriate description. A warning is now included that it does not stop future exploits, but does prevent current ones.

I would love your feedback on improving security with this system! :slight_smile:

#17

I don’t see the point in using this resource if you’re purely trying to fight against exploits and not looking for general character extensibility or performance upgrades then. Rewriting the character exclusively to combat exploits is pointless because it’s not hard at all to rewrite exploits for this character.

Custom characters are only ever useful if you are extending behaviours on top of the default Humanoid to provide better or more functionality: because you can do something the regular Humanoid can’t. Not for defending against exploits and jumping through more hoops for marginal gains that can quickly go obsolete. It will especially be a target if it’s widely used.

This just increases my doubt about this being useful, at least for my use cases. The bugs that had to be fixed is more proof that characters should not be changed if it’s purely for exploits and not because you get any functional gains out of it.

You keep repeating this phrase without explaining. How? Character exploits are client-sided. You can’t make this kind of assumption.

1 Like
#18

I see your point. I can attempt to further push optimization updates as well?
I’m also expecting to push updates allowing for more features beyond Roblox’s default.

The system is in pre-alpha and should not be used or modified for larger works until it’s more stable, as noted in the OP.

#19

This does do pretty well at protecting against some things, however it isn’t perfect.
You need to add animations to the server character otherwise some things like tools may not be in sync, also while I was testing it I found out this bug
RobloxStudioBeta_axAymCZdWK
this replicates to the server and can cause unintended use by exploiters obviously
to reproduce it, run this script:

game.Players.LocalPlayer.Character = game.Workspace[game.Players.LocalPlayer.UserId]
2 Likes
#20

Thanks for the heads-up! I had no idea you could set the character.

#21

I recall it was a very old feature way back when setting the character would give you control over anything, including other player’s characters.

Though when two players were controlling the same character, it’d have very stiff movement. Pretty neat stuff.

1 Like