Crash attacks on RedM: what a RedM anticheat has to do before the crash, not after

A Tuesday evening in Blackwater, 55 players online. In just over two seconds, eight of them drop from the server, each with the same message: Game crashed. Nobody fired a shot, and every one of them stood within about forty metres of the same spot. This is a crash attack, the cheat that does not try to win a fight but to end everyone else's session. It is also the clearest test of what a RedM anticheat is for: a crash cannot be punished after the fact, because by then the damage is done.

#What a crash attack actually is

RedM, like FiveM, lets each client create objects in the shared world: crates, props, scenery, the furniture of every roleplay script. The server mostly relays them to everyone nearby. A crash attack abuses that relay. The cheater spawns objects the game engine cannot handle safely, and places them close to the people he wants gone. Every client that loads them crashes.

The pattern we see on RedM is very regular. A small batch of identical objects appears in a tight ring around a victim, a few metres up, all in the same instant. Within seconds, everyone in range crashes, almost all with the same signature in the game executable. The cheater can stand far away: what matters is where the objects are, not where he is.

#Why most RedM anticheat setups only see it afterwards

A classic RedM anticheat watches players: their position, their health, their shots, the resources they start. A crash attack shows none of that. The cheater does not teleport, does not take damage, does not aim at anyone. On the server side, what happens is an object creation, the most ordinary event there is: a busy roleplay server sees hundreds per minute.

So the typical response is forensic. Players report the crash, staff look at the txAdmin console, see a column of "Game crashed" lines, and start guessing who was nearby. It is slow, it accuses whoever happens to be standing there, and it does nothing for the next wave, which comes ten minutes later.

A RedM anticheat that only reports a crash attack is useless against it. The only defence that counts is one that removes the objects before the clients render them, and that window is a couple of seconds wide.

#How the server stops it first

The server sees every networked object at the moment it is created, before nearby clients have finished loading it. That is the window. Our RedM anticheat uses it in three layers.

1. Known crash models are refused outright

Some models are simply dangerous. Every crash wave the server records is analysed, and the models involved are added to a shared list. A model the game cannot even resolve is learned automatically. A valid model that keeps showing up seconds before crashes is added after correlation: the one used on 13 October was created just before 22 of the 79 crash waves that server went through in two weeks. Once a model is on the list, the server cancels its creation and deletes any copy already in the world. The list is shared: a model learned on one server protects every server running the same RedM anticheat.

2. The ring is recognised by its shape

What the attack cannot hide is its geometry: a burst of objects, from one creator, closing around one player. The server watches for that shape on every object it sees created.

A ring alone is not proof, as the next section shows. What the server does with it depends on what the objects are and where their creator stands. A ring carrying a known crash model is deleted in full, for every client, wherever its creator is. On the same evening, after the wave above, the same attacker placed nine more rings between 20:57 and 21:24. All nine were deleted in full. Not a single crash followed any of them within ten seconds.

3. The creator is sanctioned, carefully

Deleting the objects protects the players. Removing the attacker protects the next evening. A server owner can have a creator caught placing a known crash model kicked automatically, then banned if he does it again. When staff ban him as a cheater, his linked accounts and the addresses he connected from are flagged too, so the second account he creates does not get a free run.

#The hard part: not accusing the wrong player

Crash defence is where a RedM anticheat can do the most damage to honest players, for two reasons we learned the hard way.

Legitimate scripts build rings too. Roleplay servers spawn scenery in bursts: a camp, a market stall, a set of crates appearing around whoever walks in. On the same server, a script in Blackwater made the client of a player standing about 45 m away create ten objects around whoever was nearby, again and again, with a different innocent "creator" every time. By count and by distance, it looked exactly like an attack. Over two days, the server recorded 24 rings. Only 9 carried a model linked to crashes, and those 9 were the attacks. The other 15, as far as we could trace them, were scenery. Distance does not separate the two; the model does. A ring with no known crash model is only acted on when its creator stands right on top of the victim. Otherwise it is logged for analysis and left alone: no deletion, no alert, nobody accused.

The "creator" is not always the author. On RedM, the server attributes an object to the client that currently owns it on the network, and ownership moves: when a player leaves or walks away, his objects can migrate to someone nearby. We saw an attacker's crash objects reappear under an innocent player five seconds later, carrying the same network ids. Our RedM anticheat now keeps the original creator when an object comes back under another owner with the same identity, and never counts it against the new one.

#What this defence cannot do

The very first wave of a new model can get through. If the model is unknown and nothing else about the ring is conclusive, the server logs it rather than risk deleting a legitimate script's scenery. That wave is recorded with who was where and what was created, which is exactly what puts the model on the list for every wave after it. The first one is expensive; the second one should not happen.

A client that crashes before the server reacts is lost. Deletion happens as soon as the server sees the ring, and on the nine rings above it came in time. A cheat that crashed clients the instant the object loads would beat it. We have not seen one on RedM yet.

Crashes have other causes. Memory exhaustion, a broken script, a bad game build, the in-game browser. A wave of disconnections is not always an attack, and a RedM anticheat that treated every crash as one would accuse half your server. The signal is the combination: same place, same seconds, same signature, and a fresh object in the middle.

#Anticheat RedM checklist: three questions about crashes

If you are comparing products, ask any RedM anticheat vendor these three questions:

1. 1

   Does it act before the crash? Removing the objects inside the first seconds, not reporting the crash afterwards.

2. 2

   How does it tell scenery from an attack? If the answer is distance or object count alone, expect your own scripts to be flagged.

3. 3

   Who does it accuse? The current network owner of an object is not always the player who made it.

The detection list is on the features page, the demo panel shows real case files without an account, and the pricing is public. Our RedM anticheat puts the whole stack on one page. For the principles underneath, start with how a RedM anticheat works, and for why the server has to make this decision rather than the client, read server-side vs client-side.