Thanks! I think if enough people put pull requests this software could be great.
3 Likes
The reason why you want to avoid client sided anti-exploits is because they are unreliable. The exploiter can literally just delete your anti-exploit and it’s bypassed.
How do you secure a remote event?
Use sanity checks on the server. Make sure the information on the Server is reasonable.
However in your current use of the remote event there is no way to verify that information. therefore it’s unreliable.
Remote event “passwords” are also easily bypass-able. An exploiter can decompile your local scripts and see what your password is or how it’s generated. Then they can use it to fake a normal client.
8 Likes
What would be a proposed sanity check that would work in this case
And yes, it’s probably not going to be bulletproof, because I don’t know how I would make it so. They can always decompile.
3 Likes
Jailbreak has an anti cheat, and has been improved in the last months. You’ll get constantly teleported to the cheater cage if you have been “banned”.
Welcome to Bloxburg kicks speed exploiters, but bans people who use scripts to generate in-game revenue.
I don’t know about Adopt Me.
But, be aware, anti-cheat means you want to reduce the abilities to cheat, it doesn’t mean banning every exploiter.
2 Likes
I mean yes, but preventing injection isn’t feasible, I don’t have that kind of access because of roblox sandboxing (which is logical because I or someone else could hijack computers that way)
this is more about damage control than prevention, because I don’t think trying to prevent injection will work ever.
2 Likes
Preventing injection is up to Roblox. Roblox already does good work on that (“unexpected client behavior”), although exploit developers constantly find new ways to circumvent Roblox’ detection.
We as game developers should care about preventing damage in-game, where securing your remotes does already a lot!
2 Likes
Synapse has a built in function for code decompiling, which if an exploiter with Synapse for example loads up Dex and finds your anti-cheat script, they can easily copy and paste the code, grab your authenticator code, and be let in. It’s easy to bypass. You’re depending on the client to send this string of letters which can be easily grabbed, bypassing your entire system and allowing them to speed all they want. Synapse also has another functionality to bypass this AFAIK.
4 Likes
The first issue that comes to mind with the client-sided aspect of your anti-cheat, which others seem to have talked about, is that an exploiter can simply hook namecall and prevent it from ever being sent to the server.
3 Likes
Anything that an exploiter injects is useless if the server blocks what they try to do, so there’s no point in trying to prevent exploiters from injecting them.
2 Likes
normally i prefer to give constructive criticism to devs so they can better themselvs
but this is just bad
client-sided anti-cheat thats unobfuscated
HOPING they don’t notice your blatant anti-walkspeed
opening connections to .Changed
firing remotes with static args
FIRING REMOTES TO BAN
that’s only a few reasons because this anticheat is virtually nothing, an exploiter could literally just delete the ClientSide.lua and bypass everything
4 Likes
SECRETCODEGENERATEAGUIDANDPUTITHERE
If I were an exploiter and saw that there were references within that particular version of the code infrastructure to SquirrelPlus (which I probably wouldn’t if the developer were clever enough), I’d know exactly how to circumvent the RemoteEvent checks.
4 Likes
Just compare travel_distance/timespan to a sanity value on the server…
3 Likes
Preventing injection isn’t impossible, you can firstly track their memory and their physicsstepms to determine whether they have injected.
3 Likes
Guis and tools are just proxies for actions. If an admin gui has a teleport command, patch the teleport (on the server), not the gui. If a tool toggles noclip, patch noclip (on the server).
Dex just visualizes the instances replicated to your client. Exploiters can serialize them to a rbxl file regardless of your patches.
To secure RemoteEvents “properly”, you apply sanity checks on the server. Exploiters can figure out what obfuscated code does, so something like your 4 liner localscript is a piece of cake for them, and is by no means “advanced” like your title claims.
8 Likes
I would not call this advanced… from looking at the code you are checking if a player’s humanoid has changed on the client and firing a remote to the server…
4 Likes
Oh, I haven’t played theme in a few months 
I think even a year, but thats good.
2 Likes
I’m sure you had good intentions when posting this but, this system is really insecure in my opinion; it has unnecessary waits
the wait at the beginning of one of your scripts doesn’t really do much except yield for approximately 0.25 seconds, this is also the case in another script.
Furthermore, you’re sending information to the server using remotes which can be easily exploited and, shouldn’t be trusted.
Using a secret code won’t really help either since an exploiter could intercept the arguments “fired” to the server using function hooks or, even metamethod hooks to prevent other types of client sided anti cheats.
Example:
local FireServer
FireServer = hookfunction(Instance.new("RemoteEvent").FireServer, newcclosure(function(Event, ...)
if not checkcaller()
if Event == EVENT_NAME then -- "event_121134" in this case, there are other methods of finding out which event it is
local Arguments = {...}
Argumets[2] = 16 -- Or, some other value, we could say this is a "spoofed" argument
return FireServer(Event, table.unpack(Arguments)) -- we could return nil if we don't want this to fire
end
end
return FireServer(Event, ...)
end))
4 Likes
Doesn’t that require you to use client sided code though?
2 Likes
“Advanced” anti cheat? What is advanced about this? All it does it tell the server what their walkspeed is and kicks them.
3 Likes
There are some ways to detect when a exploit has been injected in certain exploits.
2 Likes