Server-side vs client-side anticheat: where the decision has to be made
Client-side checks share memory with the cheat trying to defeat them. What the client still sees that the server never will, and how to use it anyway.
Every anticheat argument ends up in the same place: who gets to decide that something happened? If the answer is the player's own machine, you do not have an anticheat, you have a suggestion. That is not a criticism of one product in particular. It is a property of where the code runs.
Two machines, and one of them belongs to the cheater
A RedM resource has a client part and a server part. The client part runs inside the game process, on hardware the player owns, alongside whatever else that player chose to load. A mod menu is not attacking your resource from the outside: once injected, it shares the same address space as the game and as your Lua state. It is in the room. Anything your client script can read, the menu can read first; anything your client script can send, the menu can rewrite on the way out.
That gives an attacker four moves against a client-side check, in increasing order of laziness:
Read it. Your detection logic is Lua shipped to the player. Its thresholds, its event names and its exemptions are readable, which means a cheat can be tuned to sit just under every number you chose.
Patch it. Replace the function that reports, or the native it calls, with one that returns whatever keeps you quiet. The check still runs. It runs in favour of the cheater.
Prevent it from starting. The most common one in the wild, and the least sophisticated. Nothing needs to be defeated if the file never executes: some loaders write into the resource's global table before your code has a chance to initialise.
Answer for it. If the server asks the client "are you still watching?", the cheat answers yes. A liar is perfectly capable of confirming that it is honest.
Integrity channels are still worth having, they are just not a proof of anything. Ours requires the resource to answer the server on a schedule, and the server treats consecutive silences as an event to escalate rather than an immediate action, precisely because a rural connection produces the same signature as tampering. Silence tells you to go and look. It never tells you what happened.
Withheld/Detection thresholds are never published: a value that is known is a value a cheat is tuned just underneath.
What the client sees that the server will never see
Aim kinematics. The server receives positions and shots. It does not receive the camera. The angular path a crosshair takes between two targets - the instant step, the dead stop, the shot fired immediately after - only exists on the client, and it is the most reliable trace an external aimbot leaves behind. See silent aim detection on RedM for what that looks like in practice.
Native calls. Spawning a ped, a wagon or an object goes through game functions. From inside the process you can see that a call came from no known resource. From the server you only ever see the result, in the middle of everything your own scripts legitimately create.
Local artefacts. Globals a loader plants, files it drops next to the game, a menu's own state. These never cross the network. If nobody looks from inside, nobody looks at all.
The client is a sensor. It is never a judge.
- claimed by the client
- reported, timestamped, never sufficient
- established by the server
- position deltas, hit counts, health at the server
- confirmed by another client
- the victim describes the same event
- action taken
- server only, on established or confirmed facts
The rule we hold to is short: a client report can open a case, and it can never close one. A client that says "this player is invisible" is a reason to start counting things the server owns. The strongest evidence is not the sensor at all - it is two independent clients describing the same event, because a cheater would have to corrupt both machines to stay coherent, and one of them is the victim, who has no reason to help.
Doing the work server-side has a real cost, and RedM makes you pay it. A horse at full gallop lands exactly where a naive speed threshold sits. A player standing in a moving stagecoach or on a train travels without moving. Fast travel relocates people by design, and your framework's revive sets the very same invincibility flag as a god mode script. A server-side check that ignores those four facts does not produce fewer false positives than a client-side one. It produces more, louder, and with the authority to kick.
So the speed check is not a threshold, it is a comparison: distance covered against what the engine says the player is doing, tolerated over a window of and dropped entirely when a relocation was scripted. The exact window and the exempt contexts stay with us, because a published number is a number a cheat can be tuned under.
Withheld/Detection thresholds are never published: a value that is known is a value a cheat is tuned just underneath.
No agent, no disk scan
Some anticheats on other platforms ask players to install a driver, enumerate running processes, or hash files outside the game folder. We do none of that, and it is worth saying plainly: BaobabAC installs nothing on the player's machine. It is a resource your server ships, like every other resource. It does not read the disk, it does not list processes, it does not touch memory outside the game. On a roleplay server where a large part of your population is already suspicious of what your staff can see, that is not a technical detail - it is the difference between a community that accepts the tool and one that campaigns against it.
If you are comparing products, the question to ask a vendor is not how many detections they have. It is: where is this decision made, and what does the server know on its own? You can see how ours reads on real data in the demo panel, the pricing is public, and our RedM anticheat answers that question in its first paragraph. How a RedM anticheat works covers the detection families this article assumes.