I need to know if a feature like this will help to catch Exploiters

Imagine we had a function like loadstring but instead, this one will just be like this: LoadStringOnClientSide(player, “Code”). This one can only be executed from the server. In my opinion. I know the client can stop request. Let’s say the game has been scripted using that function in many places. Maybe we can use that function to load another client side code and checks for players hacking. I think they won’t be able to bypass it as that easy cuz they will ruin a game that works with that function Idk if you understand me. Will this be a great idea? I want to know if this will work out if Roblox add this. (Sorry for posting this in here, idk where to put it)

1 Like

I see how this could be useful for catching exploiters in games, but it puts too much trust in the client to actually run the code and would do essentially the same thing as a client-side anticheat which are highly discouraged as they can be easily disabled by exploiters.

2 Likes

I think the idea is that if you think a player is hacking, you can dynamically LoadStringOnClientSide some test math that involves sensitive values (such as walkspeed), and check via a return function what the output is. Then you kick the client if the math is not returned or incorrect.

This still isn’t a good solution, but for rudimentary anticheats it would at least be a small roadblock.

I’m fairly sure this function already exists anyways, you just clone a localscript into the Player object and then it’s on their client.

2 Likes

I see how it could be used in that way, but soon after it is implemented it would be easy for exploiters to figure out that you are using it and simply block the function wherever it is used.

I do agree that if you had to implement a system like this, it would be easier to just clone a script rather than implement an entire new function for it.

2 Likes

Blocking the function would still lead to kicks; an easier (relatively) solution would be to clone the original player environment and apply any security math to the cloned player environment, instead of the actual player environment.

The math would be correct, but would be coming from the wrong environment.

3 Likes

I wasn’t exactly trying to go into specifics about how the client could bypass it but rather a point about how the client has control over what happens with the request and if it works or not, I should have reworded it.

I guess I’m trying to say that this could be used to stop exploiters slightly but shouldn’t be used as your main system for exploit prevention.

2 Likes

If we had something like this, and part of the game system needs this function to work. That means if the exploiter disables it. The other parts of the game won’t work for them. Meaning they would have to enable it once again to make sure the game works for them. Then they will just hack and not play the game properly. As I said before The client can delete the cloned Script as fast when it get to the client that’s why is bad using a Local script for this method.

If the client wants to hack they already have bypassed loadstring() at the very least because it used to be disabled on the client, entirely, and doing things like

function goAwayNaughtyHacker()
loadstring("local hacks = true")
if hacks then ply:Kick() else return end

was a very popular and easy method of kicking hackers since they would leave loadstring turned on for their own use

Yeah but what I was trying to say is: Imagine this function exist and that the LoadClientSideCode can only be load from the server… (Make parts of the game with it so if the hackers disable it the game won’t work properly for them)