Cheating, anti-cheat, and the role of the network
Cheating, anti-cheat, and the role of the network
Cheating in multiplayer games has existed since multiplayer games existed. The cat-and-mouse between cheaters and developers has produced an entire industry of anti-cheat technology, much of which has networking implications.
This article focuses on the network-layer aspects: how cheating happens, how networks help (or fail) to prevent it, and what role hosting infrastructure plays.
Categories of cheating
The cheats people deploy in modern games fall into roughly:
Client modifications. Modifying the game's executable or memory to give yourself advantages: aimbots, wallhacks, infinite ammo, etc.
Network manipulation. Modifying packets between client and server: speed hacks, teleport, replaying actions.
Input automation. Macros, autoclickers, bots that play instead of humans.
Account-level abuses. Account sharing, smurf accounts, win trading.
Each has different solutions. The network layer is involved in some directly, others indirectly.
How cheats become possible
Two angles:
Client trust. If the client can decide things (where it is, what it's hitting), modifying the client lets cheats happen. Server-side authority limits but doesn't eliminate this.
Information given to clients. Clients need to know about the world to render it. Cheats exploit this information (wallhacks show enemies through walls; ESP shows enemy positions). Servers can limit what they tell each client.
Network manipulation. Modifying packets in flight gives cheats. Encryption makes this harder.
Server-side authority (recap)
For authoritative-server games, the server doesn't trust the client about anything important:
- Position is server-validated. The server won't let you teleport across the map.
- Damage is server-calculated. The server decides if you hit.
- Items and inventory are server-managed.
This catches many obvious cheats. Speed hacks (faster movement than physics allows): caught. Teleport: caught. Inventory manipulation: not possible.
What it doesn't catch:
- Aimbots that improve your client-side aim. The server sees you aiming "better." Indistinguishable from a skilled player.
- Wallhacks that show information the client legitimately has. The server sent the enemy position; the wallhack just displays it through walls.
- Bot accounts. The server can't easily distinguish a human from a fast-decision bot.
Information limitation: the "what should the server tell the client" question
To stop wallhacks, the server can limit what it tells the client about enemies the client shouldn't be able to see.
Examples:
- Don't send enemy positions when they're behind a wall.
- Send enemy positions only when they're visible.
- Hide footstep sounds until the source enters audible range.
This is called server-side occlusion culling in the netcode literature.
Tradeoffs:
- If you send full info, wallhacks are trivial.
- If you send only "visible" info, you have to predict visibility server-side (expensive) and getting it wrong causes "I should have seen them but didn't" moments.
Modern competitive games (Valorant, CS2) do significant server-side culling. Older games often don't.
Network-layer anti-cheat
Several things happen at the network layer:
Encryption. Modern games encrypt traffic between client and server. Prevents middle-actors from reading or modifying packets. Cheats that involve packet inspection between machines are stopped.
Authentication. Servers verify connecting clients have legitimate accounts (Steam, Microsoft, etc.). Stops some account abuse but not modified clients.
Sequence numbers and timing checks. Servers verify packets arrive in order and within expected timing. Catches replay attacks.
Rate limiting. Servers limit how many actions a player can take per unit time. Catches some automation.
Pattern detection. Servers watch for impossible patterns (perfect accuracy, no missed shots, etc.) and flag.
Network-layer anti-cheat is one layer. Client-layer anti-cheat is another. Together they catch more than either alone.
Client-layer anti-cheat (briefly)
Not strictly network-related but worth covering: client-side anti-cheat software runs on the player's machine to detect modifications.
Major systems:
- BattlEye. Used by PUBG, Rainbow Six Siege, etc.
- Easy Anti-Cheat. Used by Fortnite, Apex Legends, etc.
- VAC (Valve Anti-Cheat). Used by Valve's games.
- Vanguard (Riot). Used by Valorant. Kernel-mode, controversial.
These look for:
- Modified game files.
- Memory patterns matching known cheats.
- Suspicious processes running alongside the game.
- Kernel-level tampering.
Kernel-mode anti-cheat (Vanguard, others) is invasive and controversial. It runs at high privilege; if it has bugs, security is compromised. Some users refuse to run kernel-mode anti-cheat for these reasons.
For hosting: anti-cheat is mostly outside the hosting layer's purview. The hosting infrastructure doesn't typically run anti-cheat. The game developer's services do.
Cheating in Minecraft and similar
For Minecraft Java specifically:
Server-side plugins (NoCheatPlus, Matrix, Vulcan, etc.) provide some anti-cheat. They watch player behavior and flag suspicious patterns:
- Movement faster than possible.
- Reach exceeding plugin's tolerance.
- Killaura patterns.
- Auto-clickers.
Client-side mods on the client. Clients running mods like Liteloader or Forge can install cheating mods. Server-side plugins try to detect these by behavior.
False positives are common. Aggressive anti-cheat catches legitimate players (lag spikes can look like teleporting). Tuning is real work for admins.
For Minecraft servers, anti-cheat is admin's responsibility. Plugins help; nothing's perfect.
The DDoS as cheat mechanism
A specific issue: targeted DDoS attacks against individual players.
In games where home networks matter (P2P with host, peer-to-peer voice), attackers can DDoS a specific opponent to lag them out. Common in some online gaming communities, especially console gaming where IPs are sometimes leaked.
Mitigations:
- Hide IPs (most modern games proxy traffic).
- Use relay services that don't expose player IPs.
- For console: Sony, Microsoft, and Nintendo all have services to hide IPs.
For hosting: this isn't usually a host problem. It's a game-design and platform-design problem.
Server-side replay and detection
Modern competitive games record server-side telemetry of every match. Suspicious players can be reviewed:
- Did their accuracy spike to non-human levels?
- Did their movement always seem to anticipate enemy positions?
- Did their hit registration patterns match a "cheating" profile?
Post-match analysis catches some cheats not caught in real-time. Bans go out periodically (weekly bans in many games).
For the network: this is server-side, downstream of the live game. The hosting infrastructure provides the data; the analysis is the publisher's.
What hosting providers can offer
For game-hosting companies, the network-layer contributions to anti-cheat are limited but real:
Stable connections. Less jitter and packet loss reduce false positives in anti-cheat behavior detection.
DDoS protection. Prevents targeted attacks on individual matches.
Logging. Game logs persist for review. Some hosts provide log archival.
Rate limiting at proxy layer. Some attacks (login flood, signup abuse) can be mitigated upstream.
The deep anti-cheat work happens in the game code and the developer's services. Hosts provide the substrate, not the policy.
The cheating arms race
Cheating and anti-cheat have evolved together for decades:
- Early days: simple aimbots. Detection by behavior.
- 2000s: memory-scanning anti-cheat (VAC). Cheats moved to externalized memory access.
- 2010s: kernel-level anti-cheat. Cheats moved to hardware (peripherals, separate machines).
- 2020s: machine-learning anti-cheat. Cheats use ML to mimic human play.
- 2025+: unclear. The arms race continues.
The arms race is asymmetric: cheaters need only avoid detection for one match; anti-cheat needs to detect across all matches. Defenders are at structural disadvantage.
The honest truth: cheating is partially solvable, not fully solvable. The best games keep cheats at a low percentage of matches through a combination of techniques.
A note on private servers
For games that allow private servers (Minecraft, Valheim, etc.), the anti-cheat reality is different:
Server admin sets the policy. Some admins are strict, some are casual.
Plugins are the main defense. Server-side plugins detect and ban cheaters.
No publisher-driven anti-cheat for the most part. Mojang doesn't ban players for cheating on community servers.
Banning is per-server. A cheater banned on one server is fine on another.
For private game communities, the admin's vigilance is anti-cheat. Tools help, but social norms and community awareness matter at least as much.
What individual admins can do
For private game-server admins worried about cheating:
- Install reputable anti-cheat plugins. Matrix, Vulcan for Minecraft. Equivalents for other games.
- Tune for your community. Aggressive settings produce false positives; lax settings miss cheats.
- Encourage reporting. Community-driven moderation works. Players see things admins don't.
- Review reports promptly. Don't let cheaters operate for weeks.
- Apply consequences consistently. Same offense, same response.
- Document. Keep logs. Cheaters often appeal; logs decide.
Most communities live with some level of cheating. The goal isn't zero; it's "low enough that legitimate players have fun."
Conclusion
Cheating is real. Networks help prevent it but don't solve it.
Authoritative servers catch many cheats. Encryption catches more. Client-side anti-cheat catches more still. None of these together catch everything.
For game hosting providers, the role is providing stable, secure infrastructure. The anti-cheat policy is the game developer's or community's call.
For community admins, the anti-cheat work is real and ongoing. Plugins help. Vigilance helps. Perfect prevention doesn't exist.
The honest message: in any multiplayer game with stakes, some level of cheating exists. The good games and good communities keep it low. Cheaters are visible but rare. That's the realistic goal.
Coming up
Final article in Series E: cross-play architecture. How games run Java and Bedrock together, how console and PC play together, and the engineering required.
Hosting your game server with AndroHost means we handle most of what's in this post for you automatically: tier sizing, SRV records, off-site backups, DDoS protection.
Keep reading
Load balancing, L4 vs L7 and when each matters
Many services run on multiple servers. A load balancer is the thing that decides which incoming request goes to which server. It sounds simple. The implementation choices have meaningful consequences.
GRE tunnels, how scrubbing services route traffic through their network
When a DDoS protection service "absorbs" attacks on your behalf, the actual mechanism usually involves a GRE tunnel: a virtual point-to-point link between your real server and the protection service's network. Cleaned traffic comes out t...
BGP hijacks and RPKI, the routing security problem
BGP is the protocol that makes the internet work. It's also one of its weakest links: by default, BGP has no authentication. If a router announces "I can reach this prefix," other routers tend to believe it. This has caused outages, redi...