AR-008 — Anti-cheat (LOCKED)

Promoted from Action Required card AR-008. This is the decision of record.

This is one place where I would not take shortcuts. If Astra becomes successful, cheating will start within days, not months. Free Fire, PUBG Mobile, COD Mobile—all have ESP, aimbots, speed hacks, APK modifications, memory editors, fake packets, and emulator abuse. The important thing is this: > You do NOT need the best anti-cheat on Day 1. > > You need an architecture that can evolve without rewriting the game. That's the key. --- # AR-008 — Anti-Cheat Architecture (LOCKED) Status: APPROVED Priority: CRITICAL --- # Anti-Cheat Philosophy Astra follows a Layered Defense Model. No single anti-cheat system is trusted. Security is built into: * Client * Network * Server * Backend * Analytics Every layer validates the previous one. --- # Security Principle > Never trust the client. The mobile device is considered hostile. The client may be: * Rooted * Modified * Hooked * Memory edited * Running cheat software * Running inside an emulator The server always has final authority. --- # Layer 1 — Server Authority (Highest Priority) This is Astra's strongest anti-cheat. The server validates everything that affects gameplay. Never trust the client for: * Position * Damage * Fire rate * Ability activation * Barrier placement * Health * Shield * Prana * Match results * Inventory * Loot Clients send requests. The server approves or rejects them. --- # Layer 2 — Client Integrity Every client is checked before entering matchmaking. Checks include: * APK integrity verification * Application signature verification * Runtime integrity * Root/Jailbreak detection * Debugger detection * Memory hook detection (basic) * Emulator detection (log and classify, not necessarily block) If integrity fails: * Competitive matchmaking denied. * Account flagged. * Security event logged. --- # Layer 3 — Network Validation Every packet received by the server is validated. Reject: * Impossible movement * Impossible timestamps * Invalid sequence numbers * Ability spam * Fire rate violations * Position teleportation Never trust packet contents. --- # Layer 4 — Gameplay Validation Every gameplay event is checked. Examples: Movement Maximum speed exceeded? Reject. --- Weapon Fire faster than allowed? Reject. --- Barrier Placed before cooldown? Reject. --- Ability Enough Prana? Reject. --- Healing Too many heals? Reject. --- Damage Impossible damage? Reject. --- # Layer 5 — Behaviour Analysis Instead of banning immediately, collect statistics. Examples: * Headshot percentage * Accuracy * Average reaction time * Tracking precision * Movement patterns * Kill streaks * Barrier timing * Ability timing Extremely abnormal values generate review flags. --- # Layer 6 — Replay Validation Every completed match stores lightweight event data. Examples: * Player positions * Shots fired * Eliminations * Ability usage Allows developers to investigate suspicious behaviour. No full video recording required. --- # Layer 7 — Reporting System Players may report: * Cheating * Exploits * Toxic behaviour * AFK Reports increase review priority but never trigger automatic bans on their own. --- # Layer 8 — Ban System Violations are categorized. Minor: Warning Temporary restriction --- Moderate: Temporary suspension --- Severe: Permanent account ban Hardware fingerprint review Server blacklist --- # Security Logging Every suspicious action creates a server-side log. Examples: * Invalid movement * Modified client * Excessive packet loss manipulation * Impossible accuracy * Repeated integrity failures Logs are immutable. --- # Device Fingerprinting Store a privacy-conscious device fingerprint to identify repeat offenders. Used for: * Detecting ban evasion. * Monitoring suspicious account creation. Do not rely on it as the sole identifier because it can change. --- # Emulator Policy Do not automatically ban emulators. Instead: Classify devices as: * Native Android * Native iOS * Emulator Future matchmaking policies can decide whether to separate them. --- # APK Protection Release builds should include: * Code obfuscation. * Symbol stripping. * Resource encryption where appropriate. * Integrity verification at startup. No sensitive gameplay logic should depend solely on client-side code. --- # Backend Security All APIs require authentication. Every request is: * Signed * Rate limited * Validated Never expose internal admin endpoints publicly. --- # Live Monitoring ProjectOS should include a Security Dashboard. Metrics: * Cheat reports per day * Integrity failures * Suspicious movement events * Ban rate * Top exploited mechanics * Device distribution * Emulator percentage This becomes part of LiveOps. --- # Launch Strategy ### Phase 1 Basic server authority. Basic integrity. No third-party anti-cheat. --- ### Phase 2 Behaviour analysis. Replay review. Improved detection. --- ### Phase 3 Machine-learning anomaly detection (optional). Community moderation. Advanced security tools. --- # Third-Party Anti-Cheat Do not integrate expensive commercial anti-cheat at launch. Reasons: * High recurring cost. * Complexity. * Limited benefit while player numbers are low. Instead: Build the architecture so a third-party anti-cheat can be added later without changing gameplay code. --- # Security Principles Every future feature must follow: * Never trust the client. * Validate everything on the server. * Assume every packet can be forged. * Log every suspicious action. * Detect before banning. * Ban based on evidence, not assumptions. * Performance is never sacrificed for unnecessary security checks. --- # Success Criteria The anti-cheat system is considered successful if: * Server-authoritative gameplay prevents common client-side cheats. * APK modification cannot change gameplay outcomes. * Cheat reports remain low. * False bans are minimized. * Security architecture scales with player growth. --- # 🔒 Final Anti-Cheat Architecture | Layer | Responsibility | | ------------------- | ------------------------ | | Server Authority | Validate all gameplay | | Client Integrity | APK & runtime validation | | Network Validation | Packet verification | | Gameplay Validation | Rules enforcement | | Behaviour Analysis | Statistical detection | | Replay Review | Investigation | | Reporting | Community input | | Ban System | Enforcement | | Security Dashboard | Monitoring | --- # One recommendation I strongly disagree with most indie projects on I would not try to build an "unbreakable anti-cheat." That is impossible. Instead, I would adopt the philosophy used by many successful online games: > "Make cheating expensive, detectable, and unprofitable." If a cheater has to continuously modify their tools, gets flagged by server validation, loses accounts quickly, and cannot gain a competitive advantage because the server owns the truth, you've already won most of the battle. For Astra, server authority is your anti-cheat, and everything else is a supporting layer. That's where I would invest first.