Aimbot vs. aim-assist: telling them apart on a demo
A hard aimbot, a low-FOV assist, and silent aim leave three different fingerprints in tick data. One clean tick is never enough to tell them apart.
People say "aimbot" like it’s one thing. In demo data it’s at least three, and they don’t look alike. A CS2 demo records every player’s view angle (pitch and yaw), position, weapon and hit result on every tick, roughly 64 times a second, so the differences are visible if you look at the right window.
Three fingerprints
- Hard aimbot / flickbot. A large, near-instant view-angle jump onto the head followed by the shot, often with trigger timing no human produces. The snap itself is the signature: the yaw delta between two ticks is bigger and cleaner than a human flick.
- FOV-limited assist. The human aims roughly, the software finishes the last few degrees. No big snap. Instead, the same tiny terminal micro-correction onto the head, kill after kill, with far less variance than a wrist.
- Silent aim. The visible crosshair never lands on the target; only the bullet vector is corrected. The fingerprint is a mismatch between where the player is looking and where the damage goes. In a casual watch it just looks lucky.
Smoothing and "humanizer" modules exist to blur the first two: vendors literally advertise injected reaction delays of 150 to 250 ms to sit inside the human band. That’s why the durable signal isn’t the size of one correction; it’s the lack of natural variation across many of them.
What the research keys on
This is a solved-enough problem that there’s a literature. A 2012 IJCNN paper introduced behavioral features that separate aimbot users from equally accurate honest players, hitting ~93% true-positive and true-negative rates. A 2026 server-side study parsed 128-tick CS demo sequences (per-tick yaw/pitch deltas, distance to target, weapon, movement), and a stacked-LSTM model reached 88.6% accuracy at a 0.97% false-positive rate.
In that 2026 study, models trained on single ticks failed. Only the models that saw a sequence of ticks could separate cheating from legit play. That is the technical version of "one clip proves nothing": the signal lives in how aim moves over time, not in any frozen frame.
Valve’s own detector works the same way
VACnet, shown at GDC 2018, is a deep network trained on human Overwatch verdicts that inspects a window of pitch/yaw around each shot. Valve reported it lifted conviction rates from 15 to 30% of player reports up to 80 to 95%. The stated limitation is the honest part: VACnet is good at blatant cheating. An assist dialed down to ~60% accuracy can slip it. That’s the whole reason closet cheating is hard, and why "flagged" should mean "reviewed," not "banned."
Suspect.gg reads the same demo tick data (our aim signals include damage-to-kill timing and crosshair pre-aim error) and expresses them as a Suspect Index against a clean-player baseline, plus a percentile against the players we’ve analysed. It’s triage that points a human at the right rounds, not a verdict machine.
- Yu et al., A statistical aimbot detection method for online FPS games (IJCNN 2012)
- Dhinge et al., Server-side anti-cheat for aimbot detection (arXiv:2607.04336, 2026)
- VACnet: "Robocalypse Now", John McDonald, GDC 2018
- PC Gamer: how VACnet works
- demoparser: per-tick pitch/yaw/position fields (LaihoE, GitHub)
