Parallel Luau
– For each player the main detection script is cloned for that specific player.
All the detection scripts are tamper proof
– Meaning, if a exploiter deletes or disables the script then a server script will kick them.
Some other detections
– Mouse snapping: Identify sudden mouse movements to exact limb positions.
– Xray targeting: When the player is aiming at the target but it’s obscured by other objects.
Key Information:
This current version doesn’t detect aimbot prediction techniques just yet.
– Further testing is required with this.
while task.wait(0.5) do
for Identifier, RegisteredScript in pairs(RegisteredScripts) do
if RegisteredScript[2]-os.clock() < 0 then
if RegisteredScript[1] == false then
RegisteredScript[1] = true;
RemoteEvent:FireClient(Player, Identifier);
elseif RegisteredScript[2]-os.clock() < -2 then -- This makes sure the registered script isn't disabled. This could possibly be fired if the player is very laggy.
coroutine.wrap(POTENTIAL_TAMPERING)(Player);
end;
end;
end;
end;
How many times does this have to be said. Remote. Checkpoints. WILL. Fail.
It has been tested countless times. All it takes is one network anomaly, from the client’s pc to their modem to the server to your callback, and a perfectly behaving client gets kicked.
Even then, all an exploiter has to do is hook coroutine.wrap or the Mouse object to spoof it. You’d might as well just bind an anonymous function to RenderStep and destroy the script.
You can use this function in hooks to “whitelist” certain scripts. In your case, it’s possible to only affect your anticheat script and return non spoofed mouse information to every other one.
I don’t see how this would compromise my tamper script. It’s a server-side script with a timer. To even think about tampering with the in-game scripts, you would need the random token seeds, which are sent only once and are changed with each call. That alone would be difficult and unlikely.
local function Token(Seed, Layout, Library)
local Token = "";
local _Random = Random.new(Seed);
local Library = string.split(Library or "1234567890abcdefgh1234567890", "");
for _, Character in ipairs(string.split(Layout == "" and table.concat(table.create(math.random(4, 48), "#")) or Layout, "")) do
if Character == "#" then
Character = Library[_Random.Range(1, #Library)];
end;
Token ..= Character;
end;
return Token;
end;
You can find this function in memory using getgc(), function names are also exposed to debug library, making it really easy for exploiter to detect your token generating function. An exploiter can hook your function and wait for a single call in order to recieve your arguments and then block the function for your script and call it themselves. It’s a huge problem due to your script being open source and every math operation exposed.
What if I rename the local function to a random string using HttpService:GenerateGUID(false)?
Or, I never make a function and make it “Hard coded” in each new token.
– Hopefully you know what I mean with the second idea.
Is there any way to really get around this you think?
Well, you don’t have to really worry about it right now due to most of modern exploits not having enough power (there still might be some). Assiging a random name isn’t possible in runtime, but it’s still a better practice to use a less suspicious name.
By the way, your crash function can also get hooked.
After examinating the script a bit further, I just realized that you can simply modify configs, table.freeze is also easily bypassable.
You can check almost any executor’s environment to see what kind of functions exploiters can access. Synapse X documentation has most of the functions that executors provide. I would recommend checking every function it provides and have an idea on how Hooking functions and Debug library works.
You could probably create a new userdata and mess with __index, __newindex. That would stop most of the lazy exploiters, especially when most executors just doesn’t provide needed functional to bypass that right now.
I’m not sure if that would work but, debug.info(func, 'f') might help you with detecting hooks if function address changes same with debug.info(func, 'l'). You can see adonis anti cheat code for examples, but they mostly check for hooked roblox functions.
Function line, name, address, argument count will never change on runtime, if it does, you can be sure that user is exploiting.
