arXiv:2606.25734v1 [cs.CR] 24 Jun 2026
Shoot the Honey, Cloak the Player: Towards Zero-Runtime-Overhead Proactive Defense and Detection for Visual Game Cheating Jianing Wang
Chuqi Zhang
Yuancheng Jiang
Shandong University Qingdao, China [email protected]
National University of Singapore Singapore, Singapore [email protected]
National University of Singapore Singapore, Singapore [email protected]
Adil Ahmad
Shanqing Guo
Arizona State University Tempe, United States [email protected]
Shandong University Qingdao, China [email protected]
Abstract
Keywords
Visual aimbots have emerged as a serious cheating threat in firstperson shooter (FPS) games, as they evade existing anti-cheat defenses by operating only on rendered frames rather than game memory. However, existing defenses fail to provide an end-to-end solution: post-hoc behavior detectors cannot protect match integrity in real time and are increasingly fragile against human-mimicking aimbots, while proactive runtime defenses often lack accountability, incur substantial overhead, or require intrusive system integration. We present AimTrap, the first end-to-end defense against visual aimbots that combines real-time protection with post-game detection using two adversarial texture mechanisms. Adversarial Camouflage Textures (ACT) hide real players from aimbots, while Adversarial Honeypot Textures (AHT) lure aimbots into locking onto fake targets, yielding strong evidence of cheating. To make this practical, AimTrap integrates differentiable rendering with Expectation over Renderings for robust 3D texture synthesis, secure texture management, and a novel honeypot-interaction trajectory analysis pipeline for accurate cheating attribution. In real-game evaluation against a state-of-the-art visual aimbot, ACT achieves 85.1% defense success, AHT achieves 96.9%. Compared with prior baselines, AimTrap attains extremely low falsepositive rates, while incurring negligible runtime overhead. These results show that AimTrap provides a practical and effective endto-end defense against visual aimbots.
Game Security, Proactive Defense, Visual-Cheating Detection
CCS Concepts • Do Not Use This Code → Generate the Correct Terms for Your Paper; Generate the Correct Terms for Your Paper; Generate the Correct Terms for Your Paper. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. Conference acronym ’XX, Woodstock, NY © 2018 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-XXXX-X/2018/06 https://doi.org/XXXXXXX.XXXXXXX
ACM Reference Format: Jianing Wang, Chuqi Zhang, Yuancheng Jiang, Adil Ahmad, and Shanqing Guo. 2018. Shoot the Honey, Cloak the Player: Towards Zero-RuntimeOverhead Proactive Defense and Detection for Visual Game Cheating. In Proceedings of Make sure to enter the correct conference title from your rights confirmation email (Conference acronym ’XX). ACM, New York, NY, USA, 15 pages. https://doi.org/XXXXXXX.XXXXXXX
1
Introduction
Global video game revenue is projected to reach $564 billion by 2026 [51], with first-person shooters (FPS) remaining one of the most popular and lucrative market [50]. Unfortunately, FPS games are persistently plagued by cheating, which undermines fair competition, degrades player experience, reduces retention, and causes substantial financial losses for the gaming industry [7, 13, 19, 31]. Among these threats, aimbots are particularly damaging in competitive FPS games because they automatically aim and shoot opponents to provide cheaters with an unfair advantage [53, 68, 69]. Aimbots broadly fall into two categories: memory-based and visual-based. Memory-based aimbots directly read or manipulate game memory to recover precise enemy locations. They are increasingly constrained by existing anti-cheat systems based on memory monitoring, kernel-level protection, and trusted execution support [5, 6, 9, 14, 36, 59]. In contrast, visual-based aimbots [2, 34, 45, 54] operate solely on rendered display frames and therefore evade these defenses by never tampering with game memory. Powered by advanced object detection models such as YOLO [41, 43, 44], they can achieve superhuman aiming precision and speed while remain highly stealthy. Existing defenses against visual-based aimbots either perform post-hoc behavior detection or implement proactive runtime defense. Post-hoc detectors [3, 18, 20, 25, 26, 33, 39, 49, 65–69] analyze gameplay statistics to identify suspicious behavior after a match, whereas runtime defenses [32, 53, 64] intervene during gameplay by perturbing rendered visuals to mislead the aimbot. However, they face the following fundamental limitations: L1. Lack of both accountability and prevention. Neither approach delivers an end-to-end solution. Post-hoc detectors offer
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
accountability without prevention: they identify cheating only after unfair advantage has already been gained and therefore cannot protect match integrity in real time. Runtime defenses provide prevention without accountability: although they may disrupt cheating during play, they cannot provide forensic evidence for post-game enforcement, lack the ability to confidently attribute misconduct, and thus fail to penalize cheaters effectively. L2. Fragile against advanced human-mimicking aimbots. Visual aimbots do not exhibit many explicit unnatural behaviors of memory-based cheats, such as pre-firing or perfect tracking enemies through obstacles, which existing detectors rely on, as they share the same field of vision as humans. Moreover, modern cheats employ advanced strategies to mimic human aiming behavior, such as mouse smoothing [2, 45, 54], GAN-based trajectory generation [24], or neuromuscular aim assist [21]. This further narrows the statistical gap between skilled legitimate players and cheaters. L3. Face practical deployment barriers in real FPS games. Prior defenses face three practical barriers. First, display-perturbation defenses impose substantial per-frame overhead, making them unsuitable for latency-sensitive gameplay [32, 53]. Second, textureperturbation defenses [64] offer limited geometric coverage: they can only apply to 2D planar surfaces and cannot protect general geometry, such as 3D player and non-planar building models. Third, many defenses require intrusive integration into the game stack, including high-frequency game data collection, peripheral logging, or hooks into shaders and graphics APIs [3, 14, 32, 36, 39, 53]. Together, these barriers limit their portability, maintainability, and adoption in production games. These limitations raise a key question in the defense landscape: can a visual anti-cheat solution simultaneously prevent cheating online, produce actionable post-game evidence, and remain lightweight enough for deployment in modern FPS games? We answer this question affirmatively with two key insights. First, we transform visual-aimbot detection from passive behavior classification into an active visual challenge-response problem. Rather than inferring cheating from noisy and increasingly human-like aiming behavior, we introduce external visual signals that are salient to visual aimbots but unlikely to affect benign players. Second, unlike display-space perturbations that require expensive per-frame processing or prior texture-space defenses that are limited to 2D planar surfaces, we shift the cost to an offline, 3D-aware adversarial texture synthesis stage. To instantiate these insights, we propose two complementary mechanisms (Fig. 1). Adversarial Honeypot Textures (AHT) are static decoys placed in game scenes. They appear as high-confidence, player-like objects only to vision aimbots, inducing deliberate aiming behaviors (i.e., lock-on) for visual aimbots, while are non-salient to honest players. Adversarial Camouflage Textures (ACT) are static noises applied to player models that suppress the aimbot’s detection confidence while remaining visually natural to humans. Together, ACT reduces aimbot’s ability to detect real opponents, while AHT redirects it toward non-existent targets; repeated lock-on to such targets then becomes strong evidence of visual cheating. Realizing an end-to-end solution based on proposed mechanisms poses two technical challenges. C1. It is non-trivial to synthesize robust adversarial textures (AHT/ACT) that survive in the 3D rendering pipeline, including UV mapping [62], viewpoint changes,
Jianing Wang, Chuqi Zhang, Yuancheng Jiang, Adil Ahmad, and Shanqing Guo
Adversarial Camouflage Texture (evades aimbot targeting)
Adversarial Honeypot Texture (lures aimbot lock-on)
Honest Player View
Visual Aimbot View
Figure 1: A high-level illustration of AimTrap’s principles.
and lighting variations. In addition, secure and scalable texture management is also challenging, as textures must be protected from client-side adversaries and deployed efficiently across millions of online matches. C2. Even with honeypot textures, reliably detecting cheating with high accuracy and low false-positive rates remains difficult. The key challenge is to precisely identify sparse honeypot interactions from massive gameplay events while remaining robust to noisy interactions from honest players. To this end, we present AimTrap, a framework that both proactively defends against visual aimbots at runtime and detects their presence with strong and explainable evidence, while preserving practical deployability in real-world FPS games. To enable robust texture synthesis (C1), AimTrap integrates an end-to-end differentiable rendering pipeline and adopts Expectation over Renderings (EoR) to optimize texture-space perturbations under diverse rendering conditions (§5.2, §5.3). It further incorporates strategies for secure texture management (§5.4) and efficient deployment (§5.5). To enable effective and reliable cheating detection (C2), AimTrap designs a honeypot-interaction mouse trajectory extraction and abnormal hoenypot-interaction identification algorithm (§6). We evaluate AimTrap against a state-of-the-art visual aimbot [45] in real-game settings with real textures, replay logs, and environments. AimTrap achieves strong proactive defense, with ACT reaching an average success rate of 85.1% and AHT 96.9% across diverse rendering conditions (§7.2, §7.5). Its cheating detector outperforms state-of-the-art baseline [69] by delivering exceptionally low falsepositive rates of 1.84 × 10−5 in simulation and 3.49 × 10−8 real-game matches (§7.3, §7.4). Compared with prior perturbation-based defenses [32, 53], AimTrap incurs negligible runtime overhead, while preserving perceptual quality and practical deployability (§7.2, §7.7, §7.6). These results demonstrate that AimTrap is a practical and effective end-to-end defense against visual aimbots. Contributions. This paper makes the following contributions: (1) We introduce a novel and reliable signal for distinguishing visual aimbots from benign players: adversarial honeypots that induce cheat-specific lock-on behavior. (2) We present AimTrap, the first end-to-end defense against visual aimbots that unifies proactive runtime protection and postgame detection through two complementary and effective adversarial texture mechanisms, without introducing runtime overhead. (3) We evaluate AimTrap in real-game environments against an open-source visual aimbot, demonstrating superior effectiveness,
Shoot the Honey, Cloak the Player: Towards Zero-Runtime-Overhead Proactive Defense and Detection for Visual Game Cheating
explainable detection signals, and practical deployability compared to state-of-the-art baselines.
2 Background and Motivation 2.1 Visual Aimbot: A New Threat in FPS Games Unlike traditional memory-based aimbots, visual aimbots [2, 34, 45, 54] achieve superhuman precision without tampering with game memory. Instead, they capture real-time display frames and process them through high-speed object detection models, such as YOLO, faster-RCNN, and NanoDet, to identify on-screen enemies and automatically lock onto targets [41, 43, 44]. This vision-based paradigm offers three distinct advantages over memory-based aimbots. Stealthiness via system-level evasion. Visual aimbots can bypass conventional memory-based anti-cheats [5, 6, 9, 59] as they operate only on legitimate video output. They can also avoid kernel-level monitoring [6, 9] through two-PC setups, where an external machine processes frames through a capture card and returns control signals via simulated peripherals [55]. Recent proof-of-concept systems further show that visual targeting can be coupled with Electrical Muscle Stimulation (EMS) to induce rapid user input, making cheating behavior appear closer to organic human control [21]. Adaptability. Their vision-only pipeline inherently game-agnostic. They can seamlessly transfer across different games, platforms, and even cloud gaming environments [4, 10, 30, 35, 48, 56], where traditional memory-based aimbots are infeasible. Low barrier to entry. Visual aimbots eliminate the need for complex, continuous reverse engineering of obfuscated game binaries. Open-source vision models and LLM-assisted development tools further lower the technical barrier, enabling individuals with minimal technical expertise to develop and deploy effective cheats.
2.2
Existing Defenses Against Visual Aimbots
Existing defenses against visual aimbots can be categorized into the following two paradigms, summerized in Tab. 1. Post-hoc behavior detection. Such detectors [3, 18, 20, 25, 26, 33, 39, 49, 65–69] analyze gameplay statistics to detect cheating behavior after a match. The statistics can be collected from in-game or system-level data, or extracted from post-game replay logs. They analyze these statistics using machine learning techniques to identify suspicious behavior. For instance, Hawk [68] requires gamespecific features (e.g., flash bang affection duration on opponents and teammates) to evaluate player behavior, while XGuardian [69] relies on pitch and yaw angle data to inspect aiming trajectories. Proactive runtime defenses. Such approaches [32, 53, 64] directly interfere with the aimbot’s vision functionality during gameplay. In particular, display-perturbation methods [32, 53] inject imperceptible adversarial noise into each rendered frame to suppress the functionality of aimbots, but incur significant performance overhead. For instance, Invisibility Cloak [53] applies camouflage perturbations to hide real players. Similarly, Nhu et al. [32] combine camouflage perturbations with decoy perturbations (injecting fake players) to degrade the cheat’s accuracy. Alternatively, texture-perturbation approaches [64] apply noises directly within the texture space to avoid per-frame computational costs.
2.3
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
Limitations of Existing Defenses
We compare AimTrap with state-of-the-art anti-cheat solutions in Tab. 1, identifying critical limitations motivating our approach: L1. Lack of both accountability and prevention. Neither posthoc behavior detection nor proactive runtime protection delivers an end-to-end anti-visual-cheating solution (Tab. 1). Post-hoc detectors offer accountability without prevention: they identify cheating only after an unfair advantage has been gained, failing to protect match integrity in real time. Runtime defenses provide prevention without accountability: although they may disrupt cheating during play, they typically cannot provide reliable forensic evidence for post-game enforcement, lack the ability to confidently attribute misconduct, and thus fail to penalize cheaters effectively. L2. Existing detectors are fragile against advanced visual aimbots. Visual aimbots easily evade conventional signature-based detection [5, 6, 9, 59] (§2.1). They can also evade behavioral detectors [3, 18, 20, 25, 26, 65–69] for two primary reasons. First, they do not exhibit explicit unnatural behavior patterns of memory-based cheats, such as pre-firing or perfectly tracking enemies through obstacles. Second, they employ advanced strategies to mimic human aiming trajectories, such as mouse smoothing [2, 45, 54] and GAN-based generation [24], making them difficult to distinguish from highly-skilled legitimate gameplay. Moreover, neuromuscular aim assist [21] (§2.1) produces aiming patterns physiologically consistent with natural muscle responses, further blurring the line between human and machine behavior. L3. Face practical deployment barriers in real FPS games. First, display-perturbation defenses [32, 53] struggle to meet the strict performance standards of real-time FPS games (144–360 fps) [37, 58]. As shown in Tab. 2, Nhu et al. [32] require 8.5 seconds per frame, while Invisible Cloak [53] achieves only 21–77 fps on a high-end RTX 4090 (extrapolating to 9–34 fps on commodity RTX 3060s [15, 17]). Second, texture-perturbation defense [64] reduces runtime overhead but exhibits limited generalizability. Specifically, AdvMap [64] are restricted to 2D planar surfaces and thus cannot be extended to general 3D geometry, including player models and non-planar building models. Last, integrating prior approaches requires disruptive engine or system changes. Behavior-based detectors [3, 14, 39] depend on high-frequency game data collection, peripheral logging, or specialized hardware support (e.g., the legacy Intel SGX). Furthermore, display-perturbation approaches [32, 53] require deep integration with the rendering pipeline, such as hooking shaders or graphics APIs. These intrusions complicate compatibility and maintainability of off-the-shelf games.
2.4
Problem Statement and Threat Model
This paper addresses the emerging threat of visual aimbots in FPS games with a defense that (i) proactively disrupts them during gameplay and (ii) provides reliable evidence to identify cheaters. Assumptions. We assume that standard anti-cheat mechanisms (e.g., EAC and Vanguard) already protect the game client against memory tampering and code injection [5, 6, 59]. We trust the integrity of the game engine, operating system, and network stack. Thus, we specifically focus on external, vision-based cheats. Adversary Capabilities. Consistent with today’s common practice, cheaters have the following capabilities:
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
Jianing Wang, Chuqi Zhang, Yuancheng Jiang, Adil Ahmad, and Shanqing Guo
Table 1: Comparison between AimTrap (this work) and state-of-the-art visual anti-cheat solutions. Post-hoc Behavior Detection System
Proactive Runtime Protection
Category
Deployment Input
Evidence
Anti-Mimic
Space
Camouflage
Decoy
Overhead
BotScreen [14] (SEC’23)
Detection
Gamedata
✗
✗
N/A
N/A
N/A
N/A
✗ (Legacy Intel SGX)
Nhu et al. [32] (IPCCC’23)
Protection
N/A
N/A
N/A
Display output
✓
✓
Severe
✗ (Display modification) ✗ (Display modification)
Invisibility Cloak [53] (SEC’24)
Protection
N/A
N/A
N/A
Display output
✓
✗
High
AdvMap [64] (ToG’25)
Protection
N/A
N/A
N/A
2D textures
✗
✓
Negligible
✓
Hawk [68] (TIFS’25)
Detection
Replay
✗
✗
N/A
N/A
N/A
N/A
✓
XGuardian [69] (SEC’26)
Detection
Replay
✓
✗
N/A
N/A
N/A
N/A
✓
Both
Replay
✓
✓
3D textures
✓
✓
Negligible
✓
AimTrap (this work)
Evidence: Whether the method provides human-interpretable evidence for forensic analysis or manual inspection. Anti-Mimic: Denotes resilience against advanced aimbots designed to mimic human aiming behavior [21, 24]. Deployment: Whether the method can be deployed transparently in practice without requiring intrusive client-side changes.
Table 2: Runtime overhead comparison of AimTrap and prior proactive runtime protection solutions. System / Baseline
Defense Space
Resolution
Honeypot
FPS†
Gameplay Baseline (Casual – Esports)
1920 × 1080
144–360
Hardware Baseline (RTX 3060 [17] – RTX 4090)
1920 × 1080
200–600
Nhu et al. [32]
1920 × 1080
∼ 0.12
Rendering display
Honeypot
Invisibility Cloak [53]
Rendering display
320 × 320
21–77
AdvMap [64]
Texture (2D planar)
1920 × 1080
400–600
AimTrap (this work)
Texture (3D model)
1920 × 1080
400–600
Abnormal Lock-on Mouse Trajectory
Normal Scanning Mouse Trajectory
Figure 2: Honeypot-interaction trajectory comparison.
Note: FPS for [53], [64], and AimTrap measured on CS2 with NVIDIA RTX 4090; hardware for [32] was not reported.
(1) Frame Capture: Accessing rendered game frames directly or via external hardware (e.g., HDMI capture cards) at runtime to bypass signature-based detectors. (2) Input Injection: Generating synthetic mouse and keyboard inputs using OS-level simulation or external USB emulators. (3) Computer Vision: Applying models (e.g., YOLO [43]) to captured frames for superhuman aiming precision. (4) Behavioral Mimicry: Post-processing aiming trajectories and adding natural delays to evade behavioral detection [21, 24].
remain relatively stable at specific points due to normal pre-aiming. In contrast, aimbots are attracted to honeypots and repeatedly lock onto them, exposing automated target selection. Observation 3. Relative motion makes static cues dynamic aimbot targets. FPS gameplay is inherently dynamic: as players move or rotate their view, the perspective projection of the 3D scene continuously changes. By the principle of relative motion, static honeypots continuously shift in screen space and can repeatedly enter aimbot’s detection region around the crosshair. This makes static honeypots behave like dynamic fake targets from aimbot’s perspective, without runtime animation or rendering modification.
3 Approach 3.1 Enabling Observations
3.2
Our approach is motivated by three FPS gameplay observations. Observation 1. Visual aimbots react to detector confidence rather than human semantic understanding. Visual aimbots operate on rendered frames and rely on object detectors to identify targets. Therefore, they can react to detector-salient visual cues even when those cues do not correspond to meaningful enemies from a human player’s perspective. This creates an opportunity to manipulate aimbots through visual cues that are recognizable to detectors but imperceptible to legitimate players. Observation 2. If a detector-salient but human-imperceptible visual cues induces repeated lock-on, that behavior becomes a cheat-specific signal. We define such cues as visual honeypots. Fig. 2 illustrates the contrast between normal players and visual aimbots. Since normal players cannot perceive honeypots as meaningful targets, they do not intentionally aim at those locations. Their mouse trajectories either pass smoothly across honeypot regions, like scanning, or
Building on these observations, we present two key insights. Insight 1. We transform visual-aimbot detection from passive behavior classification into an active visual challenge-response problem. Rather than inferring cheating only from noisy and increasingly human-like aiming behavior, we introduce detector-salient visual signals that are unlikely to affect legitimate players. Insight 2. Static game assets provide a practical carrier for 3D-aware adversarial visual cues. By embedding adversarial cues directly into textures, we can synthesize them in an offline, 3D-aware pipeline and preserve their detector salience across diverse rendering conditions, avoiding expensive per-frame runtime perturbation. We therefore propose two complementary mechanisms (Fig. 1). Adversarial Honeypot Textures (AHT) contain static decoys, i.e., honeypots, which are placed in game scenes. They are optimized to lure aimbots into targeting non-existent enemies while remaining visually non-salient to legitimate players. AHT degrades
Adversarial Texture Mechanisms
Shoot the Honey, Cloak the Player: Towards Zero-Runtime-Overhead Proactive Defense and Detection for Visual Game Cheating
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
❷ Client Pre-Game Initialization
❶ Server Offline Preparation Adversarial Honeypot Textures (AHT)
Adversarial Texture Synthesis
Embedded in Game World
Memory
Adversarial Texture Pool
Adversarial Textures
Randomly Select
Adversarial Camouflage Textures (ACT)
Game Sessions
Applied to Player Models
(In-Memory-Only)
Transfer
Replay Logs
Trajectories
Abnormal HoneypotInteraction Identification
(Hash Check)
Disk Game Assets (3D Models, Audio, Animation, …)
❸ Client In-Game Runtime Defense Zero Overhead Honest
Cloaked Player Model
❺ Server Post-Game Detection Honeypot-Interaction Trajectory Extraction
Asset Integrity Verification
(evades aimbot detection)
Player-Level Aimbot Cheating Decision
Normal Scanning Trajectories
Honest Players
Abnormal Lock-on Trajectories
Aimbot Cheaters
Honeypot Map (lures aimbot lock-on)
Honest Player
Visual Aimbot
❹ Client Post-Game Processing Memory
destroy Adversarial Textures
Figure 3: Overview of AimTrap. cheat effectiveness by redirecting aimbot precision toward irrelevant targets and provides explainable post-game evidence through abnormal lock-on behavior. Adversarial Camouflage Textures (ACT) apply static perturbations to player models. They suppress the aimbot’s detection confidence while remaining visually natural to humans, inspired by prior display-perturbation defenses [32, 53]. ACT reduces the aimbot’s ability to engage real players and complements AHT by redirecting target selection toward visual honeypots. Together, AHT and ACT degrade visual aimbots at runtime while enabling post-game cheat detection, addressing L1. Unlike detectors that infer cheating from noisy human-mimic aiming behavior, our visual honeypots introduce an explicit in-game signal: repeated, intentional lock-on to human-imperceptible decoys, which is cheatspecific and unlikely to arise from benign play, addressing L2. Both AHT and ACT are synthesized offline and rendered as normal assets, requiring neither per-frame computation nor invasive displaypipeline integration. Addtionally, detection is performed server-side using standard in-game replay logs already available in modern FPS games, addressing L3.
3.3
Challenges
Realizing an end-to-end solution presents two technical challenges. C1: Robust adversarial texture synthesis and management. Synthesizing static 2D textures that remain adversarial after 3D game rendering is challenging. In games, textures are mapped onto 3D meshes and processed by complex rendering pipelines, while viewpoints and distances vary unpredictably across players. Thus, a single perturbation must remain effective under diverse rendering conditions encountered in practice (§5.2, §5.3). Moreover, since these textures are deployed on the client, adversaries can mount adaptive attacks, for example by probing to infer honeypot locations or extracting the textures to retrain their aimbots for increased robustness. This requires a secure and efficient texture management mechanism that limits attacker predictability (§5.4, §5.5).
C2: Effective honeypot-based detection. Designing a detector that uses honeypot interactions as reliable evidence without causing false positives is also challenging. The system must locate, aggregate, and interpret sparse interactions within massive replay datasets—often the proverbial needle in a haystack. In addition, benign players may occasionally trigger such interactions by chance. Therefore, the detector must tolerate rare benign events while still confidently identifying cheat-driven behavior (§6).
4
System Overview
AimTrap is an anti-visual-cheat framework that proactively interferes with aimbots at runtime with zero overhead and detects aimbot cheating behavior. To address outlined challenges (§3.3), AimTrap consists of five key phases as illustrated in Fig. 3: 1 Server Offline Preparation. The server synthesizes a diverse pool of adversarial textures offline (§5), including (a) Adversarial Camouflage Textures (§5.2) for player models to evade aimbot targeting, and (b) Adversarial Honeypot Textures (§5.3) embedded in the game world to lure aimbots and expose their cheating behavior. We randomize the texture synthesis and per-session selection to limit attacker predictability (§5.4). 2 Client Pre-Game Initialization (§5.4). In this phase, the client loads and prepares game assets. In detail, (a) adversarial textures are securely transmitted from the server to the client’s memory before the match starts, and (b) other assets (e.g., 3D models) are loaded from disk and verified against expected hash values. This integrity verification prevents attackers from tampering with game assets to weaken our adversarial textures. 3 Client In-Game Runtime Defense. At runtime, our adversarial textures proactively disrupt aimbot’s functionality: ACTcamouflaged player models evade aimbot detection, while AHTbased honeypots embedded in the map lure aimbot to lock onto them. As these textures are 3D-robust and static game assets, AimTrap does not need to modify the rendering pipeline at runtime,
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
Jianing Wang, Chuqi Zhang, Yuancheng Jiang, Adil Ahmad, and Shanqing Guo
unlike baselines that inject or alter rendering [32, 53], and therefore introduces no performance overhead during gameplay (§7.6). 4 Client Post-Game Processing (§5.4). The client discards all downloaded adversarial textures immediately after the match. This in-memory-only lifecycle places them under existing memory-based anti-cheat protections (see Assumptions in §2.4) and prevents any on-disk persistence that could expose them to aimbot developers. 5 Server Post-Game Detection (§6). AimTrap performs an effective and efficient post-game detection on standard replay logs. Note that AimTrap requires no instrumentation beyond standard replay logging, incurring no additional recording or storage cost. The detection pipeline has three stages: (i) extracting honeypotinteraction aiming trajectories from tick-level logs via geometric gating and temporal clustering (§6.1); (ii) classifying each interaction based on its aiming pattern to identify abnormal aimbot-like trajectory (§6.2); and (iii) aggregating interaction-level inferences into a player-level decision for the match (§6.3).
5
Preliminaries
Expectation over Transformations (EoT). EoT [8, 11, 46, 63] is a training-time strategy for crafting robust adversarial examples by optimizing not for a single input, but for the expected model loss under a distribution of transformations (e.g., scaling, rotation, viewpoint, lighting, noise, compression). Expectation over Renderings (EoR). When adversarial examples must remain effective after a 3D rendering pipeline, nuisance variables arise from the rendering process that maps 3D assets (e.g., geometry, materials, and textures) and scene conditions (e.g., camera pose, distance, FOV, lighting, background, and motion blur) to the final image. We therefore adapt EoT to Expectation over Renderings (EoR), which optimizes asset-space parameters—here, the texture—so that the rendered outputs remain adversarial over a distribution of rendering states. Let 𝑀 denote the mesh, 𝜏 the texture parameters to optimize, 𝜃 ∼ 𝐷 the rendering parameters, 𝑅 a differentiable renderer, 𝑓 the aimbot vision model, and 𝑦 the attack target (evasion or decoy). The EoR objective is min E𝜃 ∼𝐷 L 𝑓 𝑅 (𝑀, 𝜏; 𝜃 ) , 𝑦 .
(1)
𝜏 ∈T
Fully Differentiable Rendering Pipeline. To optimize under the EoR objective above, we integrate an end-to-end differentiable rendering pipeline [22, 38]. The renderer 𝑅(𝑀, 𝜏; 𝜃 ) maps the textured asset to an image 𝐼 given a render condition 𝜃 . Because rasterization and shading are differentiable in our setup, gradients of the detection loss with respect to the texture follow the chain rule: UV Mapping
𝑅 (·; 𝜃 )
𝑓 (·)
L
𝜏 −−−−−−−−→ 𝑀 −−−−→ 𝐼 −−−→ detections −−→ ∇𝜏 L,
(2)
𝜕𝑓 i.e., ∇𝜏 L = 𝜕𝜕𝑓L 𝜕𝐼 𝜕𝑅 𝜕𝜏 .
5.2
Θ𝑡 = {𝜃 1 , . . . , 𝜃𝑚 },
Adversarial Camouflage Textures
Adversarial Camouflage Textures (ACT) degrade aimbots’ performance by reducing their confidence of game player models, thereby hindering localization and recognition. To ensure robustness across rendering conditions, we optimize ACT under EoR framework.
i.i.d.
𝜃 𝑗 ∼ D.
(3)
ACT’s EoR Objective. We optimize ACT under Eq. (1) using a stochastic estimator over the current minibatch Θ𝑡 : 𝑚 ∑︁ bACT (𝜏; Θ𝑡 ) = 1 L ℓdet 𝑓 (𝑅 (𝑀, 𝜏; 𝜃 𝑗 ) ) , 𝑚 𝑗 =1
i.i.d.
𝜃 𝑗 ∼ D.
(4)
This unbiased estimator is differentiated end-to-end through the bACT . rendering pipeline (Eq. (2)) to obtain ∇𝜏 L Constrained Update. We update 𝜏 with projected gradient steps [27] in an ℓ∞ ball of radius 𝜖 around the initial texture 𝜏0 , with perchannel clamping to [0, 1]: bACT 𝜏 (𝑡 ) ; Θ𝑡 , 𝜏˜ (𝑡 +1) = 𝜏 (𝑡 ) − 𝛼 sign ∇𝜏 L 𝜏 (𝑡 +1) = clip [0,1] Π B∞ (𝜏0 ,𝜖 ) 𝜏˜ (𝑡 +1) ,
Adversarial Texture Synthesis
This section presents our adversarial texture synthesis pipeline (Fig. 4), covering preliminaries (§5.1), synthesis process (§5.2, §5.3), and their secure and efficient management strategies (§5.4, §5.5).
5.1
Rendering Condition Distribution. Let the game-engine rendering condition be 𝜃 = (𝑑, 𝜙,𝜓, 𝜆, 𝑏), where 𝑑 is camera distance (𝑑 ∈ [𝑑 min, 𝑑 max ]), (𝜙,𝜓 ) are yaw/pitch angles (𝜙 ∈ [𝜙 min, 𝜙 max ], 𝜓 ∈ [𝜓 min,𝜓 max ]), 𝜆 parameterizes lighting (e.g., ambient/point), and 𝑏 indexes background assets (𝑏 ∈ B). We define a distribution D over 𝜃 and, at each iteration 𝑡, draw a minibatch of 𝑚 rendering states
(5) (6)
where Π B∞ (𝜏0 ,𝜖 ) (𝑧) = 𝜏0 + clip [ −𝜖,𝜖 ] (𝑧 − 𝜏0 ) is the projection onto the ℓ∞ ball about 𝜏0 . At each iteration, we resample Θ𝑡 (viewpoints, distances, lighting, backgrounds), accumulate minibatch gradients via Eq. (4), and apply Eq. (5).
5.3
Adversarial Honeypot Textures
Adversarial Honeypot Textures (AHT) are embedded in 3D world to expose aimbot behavior: they are visually natural to human players, yet appear to vision-based aimbots as highly salient, target-like objects. We again use the EoR strategy to ensure robustness under rendering variability. Rendering Condition Distribution. We follow nearly the same rendering distribution D as in Eq. (3), excluding the background 𝑏 term since the honeypot is part of the scene. Targeted Detection with Uniqueness. We want a single high-confidence decoy in aimbot’s detection area, suppressing competitors; otherwise multiple decoys can affect aimbot’s decision-making process, leading to unstable aiming behavior. Let 𝑝 1 be the top detection score and 𝑝 2 the highest-confidence non-overlapping competitor. We enforce this with a margin and confidence calibration term: Lrank = 𝑎 ReLU 𝑚 − (𝑝 1 − 𝑝 2 ) + 𝑏 (1 − 𝑝 1 ) 2 ,
(7)
where 𝑚 is the desired margin and 𝑎, 𝑏 weight the terms. Geometric Consistency. To reduce unstable locks under viewpoint changes, we regularize the top box toward desired normalized dimensions. Let (𝑤, ℎ) be the width/height of the top box, and (𝑊𝑇 , 𝐻𝑇 ) be the reference extents for normalization under 𝜃 𝑗 . ∗ , ℎ ∗ . The Define 𝑤 frac = 𝑤/𝑊𝑇 , ℎ frac = ℎ/𝐻𝑇 and targets 𝑤 frac frac geometric loss is ∗ ∗ Lgeo = 𝜇 𝑤frac − 𝑤frac + 𝜈 ℎ frac − ℎ frac ,
(8)
with 𝜇, 𝜈 > 0 weighting width/height deviations. AHT’s EoR Objective. We optimize AHT using a stochastic estimator over Θ𝑡 : 𝑚 h i ∑︁ (𝑗) (𝑗) bAHT (𝜏; Θ𝑡 ) = 1 L 𝜆𝑟 Lrank + 𝜆𝑔 Lgeo , 𝑚 𝑗 =1
i.i.d.
𝜃 𝑗 ∼ D,
(9)
Shoot the Honey, Cloak the Player: Towards Zero-Runtime-Overhead Proactive Defense and Detection for Visual Game Cheating
Adversarial Camouflage Texture Synthesis Pipeline Player Mesh
Texture
EoR Sampling Strategy Expectation over Rendering (EoR) Sampler
Lighting Conditions Field of View (FOV) Distance
…
…
Perturbation
Player View
Visual Aimbot
16%
Visually natural to humans
Adversarial Honeypot Texture
Augmented Samples Texture
Aimbot View
Evasion Objective
92% Confidence
Differentiable Renderer
World Mesh
Adversarial Camouflage Texture
Camera Pose
Background
Perturbation
Adversarial Honeypot Texture Synthesis Pipeline
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
Aimbot View Decoy Objective
Wall
Player View
Target
Figure 4: Adversarial texture synthesis. which is differentiated end-to-end through the pipeline (Eq. (2)) bAHT . Finally, we update the texture 𝜏 following the to obtain ∇𝜏 L same method described in Eq. (5).
5.4
Secure Adversarial Texture Management
This section details the security guarantees of adversarial textures, enforced by the following three mechanisms. Randomized Synthesis and Per-Session Selection. Following well-established practices to counter predictability, such as address space layout randomization (ASLR) [47], we randomize both texture synthesis and per-game-session selection. In detail, we synthesize a diverse pool of adversarial textures offline by varying the synthesis initialization (e.g., random seeds). Then we randomly sample a subset from the pool for each game session ( 1 , Fig. 3). Such randomization obscures both which textures are adversarial and the specific perturbation patterns in each texture, limiting an aimbot developer’s ability to anticipate or adapt across sessions. In-Memory-Only Deployment. Adversarial textures, transmitted over the network from the server, are kept solely in the client’s memory, and then cleared immediately in memory when the match ends ( 2 , 4 , Fig. 3). This in-memory-only deployment keeps the textures within the protection scope of existing memory-based anti-cheat mechanisms (see Assumptions in §2.4). By avoiding any persistent disk storage, it prevents an aimbot developer’s ability from extracting, reverse-engineering, or adapting to our textures. Asset Integrity Verification. Because our textures are applied to existing client-side 3D models, an adversary might attempt to degrade effectiveness by altering models or UV mappings [62]. To prevent such tampering, we verify the integrity of all game assets loaded from the client’s disk ( 2 , Fig. 3). This integrity verification follows standard practice already enforced by vanilla clients (e.g., Valve’s VPK and Unreal Engine’s PAK file integrity check). Thus, our approach introduces negligible integration overhead.
5.5
Efficient Adversarial Texture Deployment
This section explains how we achieve efficient texture deployment through the following three design choices.
Offline Synthesis. We pre-synthesize a diverse pool of adversarial textures on the server, entirely offline, so no on-the-fly synthesis is incurred during live gameplay. The average synthesis time for AHT is 12 s and ACT 75 s (§7.6). Cross-Session Reuse. The server reuses each texture across multiple sessions to amortize the synthesis cost. As reported by [40], CS2 has averaged 902k online players over the past two years, peaking at 1.8M. Assuming 10 players per match, this corresponds to roughly 90k concurrent matches on average. At this scale, reusing each texture for hundreds to thousands of sessions still yields ample variety while keeping costs manageable. Suppose each texture is reused for 1,000 sessions, the amortized per-session cost is ≈0.012 s (AHT) and ≈0.075 s (ACT), both < 0.1 s. Such overheads are readily affordable for production servers. Lightweight Network Transmission. Adversarial textures are lightweight image files, far smaller than heavyweight assets, such as 3D models. In our implementation, AHTs average 0.83 MB and ACTs 7.48 MB (§7.6). Thus, per-session download introduces negligible bandwidth and latency overhead to the whole system.
6
Aimbot Cheating Detection
This section presents our post-game aimbot detection, comprising three phases: (i) honeypot interaction trajectory extraction (§6.1), (ii) abnormal trajectory identification (§6.2), and (iii) player-level cheating detection (§6.3).
6.1
Honeypot-Interaction Mouse-Aiming Trajectory Extraction
Extraction Overview. We convert tick-level replay logs (detailed in §C) into precise honeypot-interaction mouse aiming trajectories in two stages. First, geometric gating retains only spatially-valid ticks: the player must be within the Honeypot Proximity Zone and their view (aiming) ray must intersect the Aiming Determination Area on the honeypot plane, as illustrated in Fig. 5. Second, temporal clustering groups valid ticks to segment contiguous interactions. For each cluster, the intersections between the aiming ray and the honeypot plane define a 2D honeypot-interaction mouse trajectory.
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY Honeypot
Honeypot Proximity Zone
Aiming Ray
Aiming Determination Area
Normal Vector
Interaction Mouse Trajectory
yaw
Jianing Wang, Chuqi Zhang, Yuancheng Jiang, Adil Ahmad, and Shanqing Guo
c
Front View 𝑟𝑟𝑚𝑚𝑚𝑚𝑚𝑚
𝑟𝑟𝑚𝑚𝑚𝑚𝑚𝑚
c
c α θ r
𝑝𝑝𝑡𝑡
（x, y, z）
pitch
𝑝𝑝（ 𝑡𝑡 x, y, z）
Top View
where Δ𝑡 = (𝑡𝑖𝑐𝑘𝑡 − 𝑡𝑖𝑐𝑘𝑡 −1 )/64 normalized tick rate, (𝑥𝑡 , 𝑦𝑡 ) are 2D coordinates in ADA, [0, 1] indicates whether the hit is inside the honeypot HP. In addition, we append the honeypot’s normalized box coordinates [𝑥 HP, 𝑦HP, 𝑤 HP, ℎ HP ] as static features. Sequences are truncated or padded to 𝑇max = 320 with masks. Model architecture. We encode each sequence with a bidirectional LSTM. Let the final forward and backward states be ℎ →, ℎ ← ∈ R𝑑 and define the sequence embedding ℎ = [ℎ → ||ℎ ← ] ∈ R2𝑑 . We concatenate ℎ with 𝑏 HP and feed it to a two-layer MLP 𝑔(·) with BatchNorm and Dropout: 𝑧 = 𝑔([ℎ||𝑏 HP ]) ∈ R, where 𝑧 is the logit for the positive class. We train at the sequence level using class-weighted binary cross-entropy with logits and ℓ2 regularization. For a batch 𝑁 with 𝑦 ∈ {0, 1} and logits 𝑧 = 𝑔([ℎ ||𝑏 {(𝑆𝑖 , 𝑏 HP,𝑖 , 𝑦𝑖 )}𝑖=1 𝑖 𝑖 𝑖 HP,𝑖 ]), 𝐵𝐶𝐸𝐿𝑜𝑔𝑖𝑡 (𝑧𝑖 , 𝑦𝑖 ) = log(1 + 𝑒 𝑧𝑖 ) − 𝑦𝑖 𝑧𝑖 ,
Figure 5: Adversarial honeypot for aimbot detection 𝑁
Ldata =
Honeypot Proximity Zone (HPZ). We define HPZ as the neighborhood around each honeypot in which a player is considered spatially eligible for interaction. Let 𝑐 be the honeypot center projected to the floor plane, 𝑝𝑡 the player’s floor-projected position at tick 𝑡. Define 𝑟 = ∥𝑝𝑡 − 𝑐 ∥ and 𝜃 the incidence angle relative to the honeypot surface. We instantiate the HPZ as the circular sector, as illustrated in the top view of Fig. 5: HPZ =
(𝑟, 𝜃 ) 𝑟 min ≤ 𝑟 ≤ 𝑟 max , 𝛼 ≤ 𝜃 ≤ 𝜋 − 𝛼 ,
excluding viewpoints too close, far, or excessively grazing. Ticks with (𝑟, 𝜃 ) ∉ HPZ are discarded to improve accuracy and efficiency. Aiming Determination Area (ADA). Conditioned on being in HPZ, we further require that the player’s view ray intersects a target region on the honeypot plane (see the front view in Fig. 5). The ADA is an axis-aligned 2D box on the honeypot plane, centered at the honeypot. A tick is aim-valid if the ray cast from the player’s position along their (Yaw, Pitch) direction intersects this box. The resulting aiming trajectory is the ordered sequence of 2D intersection points within ADA. We size ADA slightly larger than the physical honeypot to capture enough aiming patterns. Temporal Clustering. After HPZ/ADA gating, we cluster the remaining tick indices using 1-D DBSCAN to form contiguous interaction segments. We set the neighborhood radius to 𝜀 = 64 ticks (≈ 1.0 s) and the minimum samples to 𝑚 = 32 ticks (≈ 0.5 s), so that clusters correspond to sustained interactions rather than spurious single-frame hits. Each cluster yields a 2D mouse trajectory in ADA plane, representing a complete honeypot interaction.
1 ∑︁ 𝑤𝑦 𝐵𝐶𝐸𝐿𝑜𝑔𝑖𝑡 (𝑧𝑖 , 𝑦𝑖 ), 𝑁 𝑖=1 𝑖
where 𝑤 1 = 𝜌, 𝑤 0 = 1, and 𝜌 = 𝑁 neg /𝑁 pos when positives are rarer. The final objective is L = Ldata + 𝜆 ∥𝜃 ∥ 22 ,
with 𝜃 denoting all trainable parameters and 𝜆 set via weight decay in the optimizer.
6.3
Player-Level Aimbot Cheating Detection
This section formalizes our player-level decision rules based on trajectory-level identification. Cheating Decision Making. Trajectory-level identification (§6.2) does not directly translate into player-level cheating detection. Instead, we aggregate predictions across multiple honeypot-interaction trajectories into a player-level decision: a player is flagged if they exhibit at least 𝑇 abnormal honeypot interactions in a match. Player-Level Cheating Detection. We model each honeypot interaction within a match as independent, as honeypots are placed at distinct locations and interactions occur at different times. Let TPR𝑇 and FPR𝑇 denote per-trajectory true-positive and false-positive rate respectively. For a match with 𝑛 interaction opportunities, the number of abnormal interactions follows Binomial distribution. The player-level true-positive rate TPR𝑃 and false-positive rate FPR𝑃 for 𝑛 flagged interactions are: TPR𝑃 (𝑛,𝑇 ) =
6.2
𝑘
Abnormal Interaction Identification
Given the extracted honeypot-interaction aiming trajectories, we formulate abnormal trajectory detection as supervised sequence classification. Each trajectory is labeled and encoded with temporal deltas, 2D intersection points, and honeypot context, and a bidirectional LSTM is trained to distinguish abnormal from normal trajectories. Below, we describe our approach in detail. Dataset. We build a dataset of 3,074 labeled trajectories for training and evaluating our classification model (§7.3). Sequence representation and normalization. Given a clustered mouse aiming trajectory of length 𝑇 , we encode each tick into a four-dimensional token 𝑠𝑡 = [Δ𝑡, 𝑥𝑡 , 𝑦𝑡 , 1{ (𝑥𝑡 , 𝑦𝑡 ) ∈ HP} ] ∈ R4
(𝑡 = 1 . . . 𝑇 ),
𝑛 ∑︁ 𝑛
TPR𝑇𝑘 (1 − TPR𝑇 ) 𝑛−𝑘 ,
𝑘=𝑇
FPR𝑃 (𝑛,𝑇 ) =
𝑛 ∑︁ 𝑛
𝑘
FPR𝑇𝑘 (1 − FPR𝑇 ) 𝑛−𝑘 .
𝑘=𝑇
Tunable Thresholds. Developers can tune the aggregation threshold𝑇 to trade recall for precision: increasing𝑇 lowers FPR at the cost of TPR, and decreasing 𝑇 does the opposite (Tab. 6 in §7.3). Because mis-flagging legitimate players undermines the anti-cheat system’s trustworthiness, real-world deployments typically prioritize a low false-positive rate over occasional misses. In our real-game evaluation (§7.4), we empirically find thresholds 𝑇 ∈ [2, 5] provide a practical operating range, accurately identifying player-level cheating while keeping no false alarm.
Shoot the Honey, Cloak the Player: Towards Zero-Runtime-Overhead Proactive Defense and Detection for Visual Game Cheating
7
Evaluation
We answer the following research questions (RQs): • RQ1. How effective is AimTrap in proactively defending against vision cheating during gameplay (§7.2)? • RQ2. How does our detection model perform in distinguishing cheating honeypot-interaction trajectories from normal trajectories? How does it perform at player-level? Does the visualized mouse trajectory reveal a strong signal? (§7.3) • RQ3. How effective is our detection model in real-game scenarios, and how does its performance compare against state-of-the-art baselines? (§7.4) • RQ4. How robust is our approach under diverse game rendering conditions (§7.5)? • RQ5. What is AimTrap’s performance overhead (§7.6)? • RQ6. Do adversarial textures degrade real-world player experience (e.g., distraction or visual strain) (§7.7)? • RQ7. How well does our approach transfer across different aimbot models (§7.8)?
7.1
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
Table 3: Effectiveness of Adversarial Camouflage Textures (ACT) for evading aimbots Male Character
7.1.1 Evaluation Metrics. We assess AimTrap using the following four metrics. Decoy Success Rate (DSR). Measures how effectively AHTs attract the aimbot. We consider a successful deception when aimbot’s top-1 detection is a honeypot with confidence ≥ 0.4 (default threshold §7.1). We evaluate DSR across various conditions, including different camera distances and angles (§7.5). Evasion Success Rate (ESR). Measures how effectively ACTs hide players from the aimbot. We consider a successful evasion if no player-aligned detection exceeds 0.4. ESR is reported under the same rendering variations. Uniqueness Rate (UR). Measures whether AHT yields a single, unambiguous attractor (§5.3). We consider it unique if exactly one honeypot exceeds detection threshold. High uniqueness reduces multi-target ambiguity for both attraction and detection. Structural Similarity Index (SSIM) [60]. Quantifies perceptual similarity between original textures and adversarial textures (AHT/ACT) on RGB maps. We report mean SSIM in [0, 1], where higher values indicate closer resemblance to the original asset.
Aimbot
Texture
Aimbot
Texture
Aimbot
Texture
Aimbot
Total
Original Texture Example
Adversarial Camouflage Texture Example
Male
Female
# of Textures
2
2
4
# of ACT
20
20
40 51,200
# of EoR Sampling
25,600
25,600
Original Confidence Score
67.7%
56.8%
62.3%
ACT Confidence Drop
↓ 49.9%
↓ 42.5%
↓ 46.3%
ACT Confidence Score
17.8%
14.3%
16.0%
SSIM
81.5%
80.5%
81.0%
Evasion Success Rate
84.1%
86.0%
85.1%
Experimental Setup
Implementation. We provide implementation details in §B. Texture Assets. We evaluate scalability by synthesizing adversarial textures from real-game assets and 3D generation pipelines [1, 23, 29]. AHT uses 24 official CS2 textures across 7 material types. ACT uses Tripo [1] to generate 4 male and female player models (§D). Map Construction and Honeypot Deployment. We use Valve’s Hammer editor [16] to build a custom CS2 map, whose structure is inspired by the classic CS1.6 map, iceworld (detailed in §B). This map deploys 16 AHTs at diverse locations. Aimbot and Proxy Models. We evaluate against a widely used open-source aimbot [45] (∼ 1.8 𝑘 GitHub stars) that detects players with YOLOv5-series models [43]. We use the default confidence threshold 0.4 for our evaluation. More details of aimbot configurations are in §G. Following the existing work [53], we adversarially train against YOLOv5n (proxy model) and evaluate cheating performance primarily with YOLOv5s (attacker model).
Female Character
Texture
7.2
Proactive Defense Effectiveness
To answer RQ1, we evaluate the two defenses provided by AimTrap: (i) Adversarial Camouflage Textures (ACT) for evasion (Tab. 3), and (ii) Adversarial Honeypot Textures (AHT) for deception (Tab. 4). ACT (Evasion). We assess ACTs using Evasion Success Rate (ESR), the aimbot’s confidence score, and visual fidelity (SSIM). We consider four distinct player models (covering both male and female characters), and for each model we synthesize ten ACT variants, yielding 40 ACTs in total. To ensure robustness, we adopt Expectationover-Rendering optimization, randomly sampling 1,280 combinations of various conditions (detailed in §7.5) per ACT (51,200 EoR samples overall). We evaluate the corresponding original textures under identical conditions as a baseline. Tab. 3 shows that ACTs substantially depress the aimbot’s confidence in detecting the player, reducing mean confidence from 62.3% to 16.0% (a 46.3% drop), well below the default detection threshold 40%. Concurrently, ACTs maintain high perceptual quality with a mean SSIM of 81.0%, indicating strong visual fidelity. The average ESR is 85.1% across rendering conditions, demonstrating effective proactive evasion against vision-based aimbots. AHT (Deception). We measure AHTs using Decoy Success Rate (DSR), Uniqueness Rate, aimbot confidence on honeypots, and SSIM. Following §7.1, we curate 24 real-game textures spanning seven material types (e.g., brick, cinderblock) and synthesize ten AHT variants per texture, producing 240 AHTs in total. For each AHT, we sample 512 EoR condition combinations (122,880 samples overall); condition details are provided in §7.5. AHTs reliably draw the aimbot’s top-1 detection to the honeypot with high confidence (mean 79.3%), yielding a DSR of 96.9%. Moreover, AHTs exhibit a Uniqueness Rate of 96.9%, indicating that, in almost all views, exactly one honeypot surpasses the threshold—providing a clean, unambiguous signal for downstream cheat detection. Perceptual quality remains acceptable (mean SSIM
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
Jianing Wang, Chuqi Zhang, Yuancheng Jiang, Adil Ahmad, and Shanqing Guo
Table 4: Effectiveness of Adversarial Honeypot Textures (AHT) for misleading aimbots Material
Brick
Cinderblock
Concrete
Mudbrick
Plaster
Sand
Stone
Total
Original Texture Example Adversarial Honeypot Texture Example # of Textures
4
2
3
3
6
2
4
24
# of AHT
40
20
30
30
60
20
40
240
# of EoR Sampling
20,480
10,240
15,360
15,360
30,720
10,240
20,480
122,880
Confidence Score
82.5%
75.4%
72.7%
72.1%
79.3%
87.8%
84.2%
79.3%
Uniqueness Rate
98.3%
99.3%
93.3%
95.3%
94.7%
100.0%
99.8%
96.9%
SSIM
70.9%
63.7%
72.5%
70.4%
67.3%
75.3%
77.3%
71.0%
Decoy Success Rate
98.3%
99.3%
93.3%
95.6%
94.7%
100.0%
99.9%
96.9%
Table 6: Player-level cheating detection performance
71.0%), enabling AHTs to blend into the scene without distracting human players (real player impact study is in §7.7).
7.3
Cheating Honeypot Interaction Identification Performance Table 5: AimTrap’s performance on honeypot-interaction cheating trajectory identification Accuracy 98.05%
Precision 96.53%
Recall 98.98%
F1 97.74%
One-Match Decision
Two-Match Decision
TPR𝑷
FPR𝑷
TPR𝑷
FPR𝑷
1
98.98%
2.640 × 10 −02
97.97%
6.970 × 10 −04
2
97.97%
6.970 × 10−04
95.98%
4.858 × 10 −07
3
96.97%
1.840 × 10−05
94.03%
3.386 × 10 −10
4
95.98%
4.858 × 10 −07
92.13%
2.360 × 10 −13
5
95.00%
1.282 × 10−08
90.26%
1.645 × 10−16
𝑻
AUC-ROC 99.29% Normal Scanning Trajectory Cheating Lock-On Trajectory
250
Setup. Following §6, we set the honeypot proximity area parameters to 𝑟𝑚𝑖𝑛 = 60.0, 𝑟𝑚𝑎𝑥 = 520.0, and 𝛼 = 30.0, and the aiming determination area to 256 × 256 pixels. Dataset. We record the replays from human players and the aimbot (configured in §G) on our map (§7.1). We collect 3,074 aiming trajectories in total, with 1,326 labeled as aimbot (positive examples) and 1,748 as human (negative examples). We split the data into 2,151/461/462 sequences for training/validation/testing. Trajectory-Level Detection Results. Tab. 5 summarizes AimTrap’s performance on trajectory-level cheating detection: accuracy 98.05%, precision 96.53%, recall 98.98%, and F1 97.74%, with 99.29% AUC-ROC indicating excellent separability. Errors are rare: a small number of false alarms (7/462), while missed cheating trajectories are extremely uncommon (2/462). Consistently, the trajectorylevel false positive rate is 2.64% and the false negative rate is 1.02%, supporting the model’s suitability for high-recall screening of abnormal honeypot-interaction trajectories. Player-Level Detection Performance. As discussed in §6.3, we aggregate trajectory-level predictions and flag a player once they exceed the threshold 𝑇 . Tab. 6 summarizes player-level cheating detection for 𝑇 ∈ [1, 5], given trajectory-level rates (TPR𝑇 = 98.98%, FPR𝑇 = 2.64%). In real-world anti-cheating deployment, minimizing false positives is critical to ensure the trustworthiness of our anti-cheat system, which ensures legitimate players not being misflagged as cheaters. With a single match for decisions, AimTrap attains very low player-level FPR for 𝑇 ≥ 2, while maintaining high
200
200
150
150
100
100
50
50
0
Normal Scanning Trajectory Cheating Lock-On Trajectory
250
0
0
50
100
150
200
250
300
(a) 𝐻 1 Interaction Trajectories
0
50
100
150
200
250
(b) 𝐻 2 Interaction Trajectories
Figure 6: Typical mouse trajectories of aimbots and normal players on two distinct honeypots.
recall; aggregating two matches further reduces false positives by orders of magnitude. As discussed in §6.3, developers can tune 𝑇 to achieve their desired precision-recall trade-off. Trajectory Visualization and Case Studies. Fig. 6 visualizes representative honeypot-interaction mouse trajectories for aimbot cheaters and normal players. Red rectangles mark two honeypots (𝐻 1, 𝐻 2 ); gray denotes the wall; blue outlines the Aiming Determination Area (§6). Colored dots plot the aiming trajectory with red denoting aimbot and blue denoting human trajectories. The arrow represents the mouse moving direction. These figures reveal a clear signal: aimbot trajectories exhibit deliberate lock-ons that converge tightly on the honeypots, whereas human trajectories
Shoot the Honey, Cloak the Player: Towards Zero-Runtime-Overhead Proactive Defense and Detection for Visual Game Cheating
pass smoothly through the scene without sustained fixation. More visualization cases can be found in §E.
7.4
Real-Game Cheating Detection Performance
To answer RQ3, we evaluate AimTrap against our baseline [69] in a real-world CS2 setting. Real-world Gaming Environment Setup. We conducted a paid gameplay study on our map (§7.1) in CS2’s Competitive mode. Twenty participants each played two matches: one without cheating and one assisted by the aimbot (configuration in §G) to simulate cheating. Twenty participants are blind to the study’s purpose and are recruited from a diverse pool of CS2 players with varying experience levels (from novices to veterans). In total, we collected 40 matches (20 non-cheating, 20 cheating). Results. Tab. 8 summarizes the real-world detection statistics for AimTrap. Across all 40 matches, AimTrap correctly classified every non-cheating and cheating match. (1) Non-cheating matches. Across 20 non-cheating matches, participants triggered 𝐼𝐴 = 306 honeypot interactions (mean = 15 per match). Only one interaction by player R was misclassified, yielding a trajectory-level false positive rate of 1/306 ≈ 3.27 × 10−3 . Applying the aggregation rule in §6.3 with 𝑇 = 1 gives a player-level false positive rate of 3.49 × 10−8 , substantially lower than the simulated rate reported in Tab. 6 (1.84 × 10−5 ). These results provide strong evidence of AimTrap’s precision under real-world gameplay. (2) Cheating matches. Across 20 cheating matches, AimTrap record 𝐼𝐴 = 325 honeypot interactions (mean = 16), including 𝐼𝐶 = 202 cheating trajectories (mean = 10). All players exceeded the threshold 𝑇 = 3 (𝐼𝐶 = 5–21), confirming its effectiveness for real-game detection. The gap between 𝐼𝐴 and 𝐼𝐶 is expected, as the honeypot proximity zone (§6) is recall-oriented and may include interactions where the honeypot is too distant or off-axis for aimbot lock-on. Comparison with state-of-the-art baseline. Tab. 8 shows that AimTrap consistently distinguishes cheating from benign gameplay, correctly classifying all 40 matches. In contrast, XGuardian [69] (XG) detects only 3 out of 20 cheating matches and correctly classifies 14 out of 20 benign matches, with several processing failures. These results highlight the effectiveness of adversarial honeypot interactions as a reliable cheat-specific signal in real-game settings.
7.5
Robustness
We assess AimTrap’s robustness across various conditions. (1) Camera Distance (𝑑): distance from camera to target (player model for ACT; honeypot for AHT). Default 𝑑 = 1.0; we sweep 𝑑 ∈ [0.8, 1.2] (smaller ⇒ closer). (2) Camera Yaw (𝜓 ): horizontal rotation with default 𝜓 = 0◦ (target facing camera). For ACT, we sweep 𝜓 ∈ [−60◦, 60◦ ] for wide lateral views; for AHT, 𝜓 ∈ [−20◦, 20◦ ] suffices since honeypots lie on near-planar walls that require limited yaw range. (3) Camera Pitch (𝜙): vertical rotation. Default 𝜙 = 0◦ (level). For ACT we sweep 𝜙 ∈ [−2◦, 2◦ ]; for AHT we use 𝜙 ∈ [−20◦, 20◦ ] to include steeper up/down views of wall-mounted textures. ACT Robustness. We randomly sample 1,280 EoR combinations per ACT from a Gaussian centered at the defaults (51,200 total). Tab. 7 reports slices over (𝑑,𝜓 ) with fixed pitch 𝜙 ∈ [−2◦, 2◦ ], including aimbot confidence on original and ACT textures as well
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
as ESR. ACTs are stable across most viewpoints. At extremes (large |𝜓 | and long distance), ESR drops due to reduced visible surface and foreshortening, suggesting room for further EoR augmentation. AHT Robustness. We sample 512 EoR combinations per AHT (122,880 renders total). Tab. 9 summarizes honeypot confidence and DSR across representative (𝑑,𝜓, 𝜙) ranges. AHTs sustain uniformly high deception: all ranges exceed 95% DSR (avg. 96.9%), indicating robust decoys across various rendering conditions.
7.6
Performance Overhead
Server Offline Synthesis Overhead. Tab. 10 shows synthesizing one ACT averages 74.95,s and AHT 12.05,s. Since synthesis runs offline to pre-generate texture pools (§4), AimTrap does not increase client overhead. Moreover, cross-session reuse (§5.5) amortizes this one-time cost: reusing one texture across 1,000 sessions reduces per-session overhead to < 0.1 s while maintaining sufficient variety. Client Pre-Game Initialization Overhead. Before matches, the server transmits adversarial textures to clients (§4). Small average payloads—0.83,MB per AHT and 7.48,MB per ACT—ensure transfer and asset installation introduce negligible loading time. Client In-Game Runtime Defense Overhead. AimTrap incurs near-zero runtime overhead (Tab. 2). Adversarial textures are standard assets that replace existing ones, introducing no additional per-frame computation beyond normal rendering paths. Although file sizes differ slightly (typically smaller than the originals), we observed no measurable latency or FPS degradation. Server Post-Game Detection Overhead. Evaluated on 40 realworld matches (§7.4), end-to-end post-game detection averages 8.46 s per player per match (8.33 s for trajectory extraction, 0.13 s for cheating inference). This low computational overhead makes AimTrap suitable for production-level deployment.
7.7
Real-World Gaming Impact Analysis
We conducted a questionnaire-based user study to assess AimTrap’s impact on players in real-world gaming scenarios, covering Perceptibility, Indistinguishability, and Naturalness, including 113 participants with diverse FPS experience (detailed in §F). Perceptibility. We examine its impact on human’s perceptiblity by asking whether (i) ACT makes player models imperceptible and (ii) AHT misleads them into noticing a human-like target on a wall. Overall, participants reported no loss of perceptibility and no misleading salience. Indistinguishability. We tested whether participants could distinguish adversarial textures from the originals. After a brief warm-up with a side-by-side comparison image, participants answered two multiple-choice questions for ACT and AHT with four options: (i) all targets deploy AimTrap, (ii) only the first, (iii) only the second, and (iv) none deploy. The correct answers for the two items were (ii) and (i) (green in Fig. 7), respectively. The results show that most participants selected “none deploy,” indicating that the adversarial textures were perceived as visually consistent with the originals. The remaining responses, including the correct options, were dispersed in a near-uniform manner, suggesting that AimTrap is difficult to distinguish from standard textures. Naturalness. Finally, we evaluated naturalness by presenting paired targets: one with AimTrap and one without. The participants were
Conference acronym ’XX, June 03–05, 2018, Woodstock, NY
Jianing Wang, Chuqi Zhang, Yuancheng Jiang, Adil Ahmad, and Shanqing Guo
Table 7: 3D rendering robustness of Adversarial Camouflage Textures Yaw
[−60◦ , −45◦ ]
[−45◦ , −30◦ ]
[−30◦ , −15◦ ]
[−15◦ , 0◦ ]
[0◦ , 15◦ ]
[15◦ , 30◦ ]
[30◦ , 45◦ ]
[45◦ , 60◦ ]
CD0
Conf ESR
36% → 3% 99.2%
45% → 8% 94.4%
49% → 8% 95.4%
61% → 12% 94.7%
64% → 13% 91.7%
58% → 9% 92.1%
62% → 15% 88.2%
68% → 31% 66.7%
CD1
Conf ESR
62% → 17% 81.2%
60% → 13% 83.1%
63% → 17% 82.3%
71% → 27% 70.9%
72% → 22% 78.2%
70% → 18% 82.5%
75% → 26% 72.4%
76% → 43% 39.1%
Note: CD0 denotes camera distances ∈ [0.8, 1.0] , while CD1 ∈ [1.0, 1.2] . Conf denotes the change in the aimbot’s confidence score before and after the application of ACT. ESR denotes Evasion Success Rate. Camera Pitch is set to [−2◦ , 2◦ ] .
Table 8: Comparison of visual-cheat detection in real-game settings. Green indicates correct predictions. Player ID A B C D E F G H I J K L M N O P Q R S T
No Cheating AimTrap
FPS Exp.
300–1000 > 1000 300–1000 300–1000 300–1000 < 100 300–1000 300–1000 > 1000 100–300 < 100 100–300 300–1000 > 1000 300–1000 < 100 100–300 300–1000 > 1000 100–300 Average Overall
AimTrap
𝐼𝐶
Pred
Pred
𝐼𝐴
𝐼𝐶
Pred
Pred
20 17 7 14 12 10 12 12 18 11 29 19 13 16 7 17 10 19 24 19
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
F F F F F F F F F F F F F F F F F F F F
F F F ⊥ F T F ⊥ ⊥ T F F F F F F T F F F
25 11 16 16 13 10 18 23 26 11 11 14 15 23 10 16 14 17 10 26
12 5 12 9 7 5 10 12 13 7 8 8 12 19 5 11 9 11 6 21
T T T T T T T T T T T T T T T T T T T T
F ⊥ F ⊥ T F ⊥ ⊥ F F F F T F F F ⊥ T F F
15
0
16
10
306
1
325
202
20
3
AHT