Client Anti Cheats: Aren't as bad as you think!

Resources Community Tutorials
, ,
#324

They are parented to nil, and do not have any associated bytecode

#325

What are you even talking about…

#326

I thought parenting to nil had a different message for some reason, but trying to mess with something that was destroyed gives an error.
The Parent property of LocalScript is locked, current parent: NULL, new parent Workspace

This doesn’t happen if you parent a script to nil, also calling enabled won’t do anything.

Now I did some test, and remote functions are fully working now, maybe It was an error in my code because I remember it giving me an error with something like:

The local script that made this callback has been destroyed.

And it was on the server, apparently It’s fixed now, I guess

1 Like
#327

The hierarchy is handled in C++, hence why NULL instead of nil

That’s when you initialize the callback BEFORE destroying the script

#328

Also just realized that a simple return game_______ (you get the idea) can detect if they are already injected and joined the game, so you can just crash them, UWP exploits are terrible, anyway, if anyone here wants a bypass for decedants added.

You can do the following, you can place a script in localization service, using a script with run context to client, or the service chat, this will bypass decedants added.

Make sure to make the script delete “itself” immediately for this to work, after you are done, even if a exploiter disables the script by directly getting the service, the script will still run, same goes with :Destroy().

You can then check if any of the anti cheats were disabled or tempered with, and crash the exploiter.

#329

I have to agree completely here, Bypasses are not uncommon but provided that you break as many bypasses as you can per update then you can effectively use the client as a second line of defense against script kiddies who just steal some random exploit off of v3rm with a free exploiter that is most likely logging EVERYTHING on their (parent’s) computer, It works quite well in that regard.

1 Like
#330

Like nearly every bypass screenshot is fake.

#331

Do you have any evidence to back this up?

1 Like
#332

I don’t really, mostly because I’m pretty sure no one actually released these working and undetectable versions afaik (tbf I don’t know too far)

#333

They’re not released but they’re most definitely working, the reason they’re not released yet is because they need to rewrite their functions, I’m fairly sure Hyperion has been bypsssed by alot of people now.

1 Like
#334

Could somebody summarize this thread? It is long and as I just found it, I don’t know where there have been some developments on better or worse ways to use this, or not to use it at all

#335

also i’m pretty sure these are detected, they just don’t do a funny crash. roblox mods just see the funny little injections and “monitor”

#336

Imagine an anti cheat, where It used AI, and basically it would take screenshots, of the taskbar, and the game itself, if the AI saw a “Cheat menu”, It would report it to a server and close the game without a crash, It would be kernel aswell

#337

These types of stuff already exist, well, not with AI, I don’t think.

You can get the running processes, then check if the name is similar to of an cheating tool.

#338

Hyperion can’t do this because it’s in usermode and it’s an invasion of privacy

#339

Another fun fact: You can put some parts, or even the entire part of the client-side anti cheat into the Animate script, put it inside StarterCharacterScripts, because of that even if they disabled every local scripts in PlayerGui and PlayerScripts, the AC will continue to run anyway since it’s inside their character. Also noting the fact that if they disable the Animate script, they will not have an animation at all. Which means, disabling the anticheat means disabling a part of important feature such as animations.

And since they will not animate while the script is disabled, you can even put a check if their avatar parts can’t move (or should i say, animate) for a long time, on the server. First to prevent false positives, check their internet or Roblox servers can deliver the animations by using PreloadAsync and AssetFetchStatus, and send the reports to the server.

The problem is that animations will be stuck at the default settings, so you have to iterate each animation types and sync them into the local player’s HumanoidDescription before the animation and AC starts. But anyway, it works and no need to hide somewhere anymore.

EDIT: Yes, smarter exploiters can still remove the animations script and execute another copy of Roblox Animate script using their executors. But most of exploiters will just give up at this point already.
Client-side ACs are a thing because: server-side movement ACs isn’t effective without also working together with client-side checks, and also we can deter less-skilled exploiters / skids rather than 100% relying on server side checks or even Hyperion. Thus by making them less likely to be disabled is still a good thing rather than making client-side checks too aggressive.

#340

The reason people say you are not supposed to trust clients and the reason people say you are not supposed to be relying on client side anti-cheats is because they are fundamentally impossible to “secure.” Any behaviour or functionality or data that is present on the client can freely be modified or changed in any way by exploits, and none of the things that you’ve achieved in this post are reliable at stopping exploits because they’re just flaws in the exploits.

No client code that you write is impossible to circumvent and it’s often not even hard on most exploits. Anything that isn’t possible for an exploit to handle is not a limitation of exploits as a whole it is a limitation of the specific exploit. You are forgetting that not all exploits even execute Luau code, many of them are far more simplistic and involve direct memory reading and writing and stuff like that. Nothing in memory is safe from an exploit regardless of how complicated it might be for exploits to provide users of the exploit with access to that stuff.

After all, that’s all script executors even are doing, they are reading and writing into Roblox memory in a way that allows them to execute Luau code that has higher privileges and accesses memory for instances in nil and things like that. They each provide a bunch of semi-standardized features to make writing exploit scripts more accessible to their target audience, because they all want to be able to run eachother’s code, otherwise that makes them less valuable to users. But the way they each achieve these behaviours can be entirely different, and something that works in one exploit will not work in all others and might only work in the specific exploit you have access to.

Further:

  1. The getfenv() call in the first code snippet is not necessary, you do nothing with the global environment except read the script global, so there’s no reason to even call getfenv().
  2. The instance does show up in Dex and in getnilinstances on pretty much any modern exploit that knows what it’s doing. The behaviour depends entirely on the exploit. The fact that some do not is a bug on their part that they will want to fix, it’s not some fundamental thing that exploits can’t account for or anything like that.
  3. Handshakes are easily circumvented by simply spoofing values changed by the exploit which can be done in a few lines of code on most exploits. On top of this, exploits can easily spoof these handshakes too because they have access to the bytecode of your anti-cheat, regardless of how much you try to obscure them, and regardless of how much you try to hide the script.
  4. On top of this, the amount of shenanigans you had to pull for something that can still be fairly easily circumvented in most exploits isn’t worth the effort. You are putting in a lot of effort and a lot of work (comparatively, I know these snippets are very easy to write but compared to just writing secure server code they are magnitudes more work for magnitudes less effect) Exploiters and exploits themselves very quickly adapt to any sort of attempts at prevention or hiding, e.g. your trick to destroy the script so that it will not show up in getnilinstances in some exploits is a flaw with some exploits. Dex uses getnilinstances under the hood.
#341

This is not true at all. Exploits can easily either re-introduce this behaviour or simply just disable or remove the code that you added. There is not anything preventing them from doing that.

Secondly, animations are not exactly an essential feature anyways.

#342

This is something that your exploit just doesn’t spoof. It’s not reliable, like literally every client-sided check, because it would be trivial for an exploit to simply change that behaviour.

#343

Just use handshakes, they are much better and there’s no really point for using this method.

1 Like