docs: expand anti-cheat documentation with AI visual aimbot detection techniques and OBS capture pipeline details

2026-06-21 13:56:22 +00:00 · 2026-05-22 11:13:15 +08:00
parent 71f536f865
commit ebf98395f8
3 changed files with 629 additions and 5 deletions
@@ -177,6 +177,261 @@ Anti-cheat KDP integration:
 - Movement and aim anomaly detection
 - Statistical improbability and ML-assisted scoring
 - Telemetry collection and server-side review
+- AI visual aimbot detection (input pattern + gameplay behavior)
+```
+
+### AI Visual Aimbot Detection
+```
+AI visual cheats (OBS capture + YOLO + hardware input) are the hardest
+class to detect because they involve no memory access, no code injection,
+no kernel driver on the gaming PC. Detection must move to behavioral
+analysis and environmental signals.
+
+Input Pattern Analysis:
+- Mouse movement micro-signature: AI-generated trajectories have
+  characteristic acceleration profiles distinct from human muscle control
+  even with smoothing and jitter injection
+- Engagement timing: AI reacts within a narrow, consistent latency band
+  (capture → inference → output, typically 20-50 ms total) that lacks
+  the variance of human reaction time distributions
+- Sub-pixel precision: hardware input devices report integer deltas,
+  but AI-calculated movements exhibit systematic rounding patterns
+  that differ from natural hand movement
+- Correction patterns: AI trajectories show characteristic overshoot-and-settle
+  patterns at consistent magnitudes; human correction is more variable
+- Target switching: AI switches between targets with machine-like
+  priority ordering (closest-to-crosshair or highest-confidence);
+  humans exhibit attention bias and tunnel vision
+
+Gameplay Behavioral Signals:
+- Anomalous K/D ratio combined with other statistical outliers
+- "Snap" engagement pattern: rapid crosshair movement to target
+  followed by immediate fire, repeated consistently
+- FOV-limited engagement: AI only engages targets within a specific
+  pixel radius (the configured FOV), creating an unnatural engagement
+  boundary visible in replay analysis
+- Consistent headshot angle distribution that doesn't match
+  the player's ranked skill bracket
+- Engagement rate: AI engages available targets at a higher percentage
+  than human players who miss, ignore, or react slowly to some targets
+
+Environmental Detection:
+- OBS process detection: Game Capture mode injects a graphics hook DLL
+  (obs-graphics-hook64.dll) into the game process; detectable via
+  loaded module enumeration, though banning it risks false-positive
+  on legitimate streamers
+- Window Capture detection: DXGI Desktop Duplication creates detectable
+  API state (IDXGIOutputDuplication usage patterns)
+- Frame readback detection: unusual GPU-to-CPU copy patterns
+  (ReadbackTexture / staging resource creation at frame rate)
+- Known hardware input device USB VID/PID signatures
+  (KMBox, certain Arduino/Teensy boards)
+- USB device enumeration anomalies: input device appearing/changing
+  mid-session
+- Logitech driver version detection: known exploitable G HUB versions
+- Interception driver (interception.sys) loaded = high-risk signal
+
+Server-Side Statistical Analysis:
+- Aim trajectory reconstruction from server-received input deltas
+- Compare aim distribution against player population at same rank
+- Detect systematic per-frame aim correction vectors
+  (AI produces consistent delta sequences)
+- Cross-session pattern analysis: AI users show unnaturally stable
+  performance metrics across sessions (low variance in accuracy)
+- Replay-based ML classifiers trained on confirmed AI aimbot cases
+
+Anti-AI Countermeasures (Game Design):
+- Visual disruption: flashbang/smoke effects that confuse CV models
+- Character skin variety and camouflage that reduce YOLO confidence
+- Dynamic UI elements overlapping character models
+- Server-side aim validation: reject physically impossible aim transitions
+- Randomized character proportions or outline disruption to break
+  trained model assumptions
+```
+
+### Server-Side Replay Analysis for AI Aimbot Detection
+```
+Server-side detection operates on input telemetry data uploaded
+from the client, independent of what runs on the gaming PC.
+This is the strongest layer against zero-memory AI cheats.
+
+Input Telemetry Collection:
+- Record raw mouse delta (dx, dy) per tick at server tick rate
+- Record timestamps of each input event (sub-millisecond precision)
+- Record crosshair angle / view angle per tick
+- Record fire events with corresponding view angle at fire time
+- Record damage events with hit location (head/body/limb)
+- Collect per-session: total engagement count, hit count,
+  headshot count, K/D, average engagement distance
+
+Replay-Based Trajectory Reconstruction:
+- Reconstruct full crosshair trajectory from recorded input deltas
+- Overlay trajectory onto 3D game state (player positions, obstacles)
+- Identify "engagement windows": trajectory segments where crosshair
+  moves toward and locks onto a target
+- Measure per-engagement: time-to-target, overshoot magnitude,
+  correction count, final hold time before fire
+
+Statistical Features for AI Detection:
+  (extracted from reconstructed trajectories)
+
+Temporal features:
+- Reaction time distribution: time from target visibility to
+  first crosshair movement toward target
+  → AI: narrow, consistent band (30-80 ms capture+inference+output)
+  → Human: wide, right-skewed distribution (150-400 ms typical)
+- Time-to-lock distribution: time from engagement start to
+  crosshair on target
+  → AI: consistent, speed-limited by smoothing algorithm
+  → Human: highly variable, depends on initial angular distance
+
+Spatial features:
+- Trajectory curvature: AI Bézier curves have characteristic
+  smooth, parametric curvature; human paths are more erratic
+  with micro-corrections and random deviations
+- Overshoot-correction ratio: AI smoothing algorithms produce
+  predictable overshoot magnitudes; humans vary wildly
+- End-point precision: AI consistently lands on bounding box
+  center or specific offset; humans show scatter distribution
+- Angular velocity profile: AI ramps up/down smoothly;
+  humans have irregular acceleration spikes
+
+Engagement pattern features:
+- Target selection consistency: AI always picks closest-to-crosshair
+  or highest-confidence target; humans show attention bias, tunnel
+  vision, and suboptimal target priority
+- FOV boundary effect: AI shows sharp engagement cutoff at
+  configured pixel radius; humans have gradual falloff
+- Engagement rate: percentage of visible targets engaged;
+  AI engages more consistently than humans who miss, ignore,
+  or react slowly to peripheral targets
+- Multi-target switch pattern: AI switches with machine-like
+  regularity; humans show grouping and hesitation
+```
+
+### ML Classifier for AI Aimbot Detection
+```
+Feature engineering and model architecture for detecting
+AI-generated mouse input at scale.
+
+Feature Vector (per engagement window):
+  f1:  reaction_time_ms
+  f2:  time_to_lock_ms
+  f3:  initial_angular_distance_deg
+  f4:  trajectory_curvature_mean
+  f5:  trajectory_curvature_std
+  f6:  overshoot_magnitude_px
+  f7:  correction_count
+  f8:  final_hold_time_ms
+  f9:  angular_velocity_max_deg_per_sec
+  f10: angular_velocity_std
+  f11: micro_correction_frequency (small deltas < 2px per tick)
+  f12: trajectory_straightness_ratio (distance / path_length)
+  f13: dx_dy_correlation (Pearson correlation of delta components)
+  f14: delta_magnitude_entropy (Shannon entropy of |delta| sequence)
+  f15: fire_timing_relative_to_lock_ms
+
+Session-level aggregate features:
+  s1:  headshot_ratio
+  s2:  hit_ratio
+  s3:  reaction_time_cv (coefficient of variation across engagements)
+  s4:  engagement_rate (targets engaged / targets visible)
+  s5:  k/d_ratio
+  s6:  fov_engagement_boundary_sharpness
+  s7:  target_selection_optimality_score
+  s8:  trajectory_curvature_consistency (inter-engagement variance)
+
+Model architecture options:
+- Gradient Boosted Trees (XGBoost/LightGBM):
+  Best for tabular feature vectors, interpretable feature importance,
+  fast inference on server. Preferred for production deployment.
+- Random Forest: simpler, less prone to overfitting on small datasets
+- 1D-CNN / LSTM on raw delta sequences:
+  Operates on raw (dx, dy, dt) sequences instead of engineered features.
+  Can capture patterns human engineers might miss.
+  Higher compute cost; suitable for batch/offline analysis.
+- Ensemble: combine tree-based (tabular features) + sequence model
+  (raw deltas) for highest accuracy
+
+Training data:
+- Positive samples: confirmed AI aimbot users (manual review, honeypot,
+  or controlled testing with known cheat software)
+- Negative samples: legitimate high-skill players (important: include
+  top-percentile players to avoid false-positives on skilled play)
+- Hard negatives: players with aim-assist controllers (console),
+  players using legitimate accessibility tools
+
+Evaluation metrics:
+- False Positive Rate (FPR): must be extremely low (< 0.01%)
+  for production deployment — banning legitimate players is catastrophic
+- True Positive Rate (TPR): secondary to FPR; 70-85% TPR is acceptable
+  if FPR is near-zero
+- Use session-level aggregation: flag a player only if multiple
+  sessions show consistent AI patterns (reduces both FP and FN)
+
+Deployment pipeline:
+  Client → input telemetry upload (per tick) → server telemetry DB
+  → batch feature extraction (per engagement window)
+  → ML inference (per session)
+  → risk score aggregation (per player, across sessions)
+  → threshold → manual review queue or automated action
+
+Adversarial robustness:
+- Cheat developers tune smoothing parameters to evade specific features
+- Defense: retrain model periodically on newly confirmed samples
+- Use feature combinations rather than single-feature thresholds
+- Ensemble across multiple sessions reduces evasion success
+- Raw sequence models (CNN/LSTM) are harder to evade than
+  hand-crafted feature thresholds because the evasion space
+  is higher-dimensional
+```
+
+### Hardware Input Device Detection
+```
+Detecting KMBox and similar hardware input injectors at the
+platform/driver level.
+
+USB Enumeration Signals:
+- Known VID/PID combinations for KMBox, Arduino Leonardo (2341:8036),
+  Teensy (16C0:0486), generic CH340/CP2102 serial adapters
+- USB device appearing/disappearing during game session
+- Multiple HID mouse devices where only one physical mouse is expected
+- USB device with HID mouse capability but no manufacturer string
+  or generic "Arduino LLC" / "Teensyduino" manufacturer
+
+USB HID Report Analysis:
+- Hardware input devices generate genuine HID reports, but:
+  - Report rate: KMBox/Arduino typically report at exactly the
+    programmed rate (e.g., every 1ms or 8ms); real mice have
+    polling rate jitter tied to USB microframe scheduling
+  - Report timing: AI-injected movements arrive in bursts
+    (idle → sudden burst of calculated deltas → idle),
+    while human movement is continuous with natural pauses
+  - Delta distribution: AI deltas cluster around computed values
+    with optional noise; human deltas follow characteristic
+    distributions per movement speed
+
+Network Traffic Indicators (KMBox Net):
+- KMBox Net uses UDP communication on the local network
+- Packet pattern: consistent-size UDP packets at high frequency
+  from a secondary device to the KMBox's IP
+- If cheat PC is on the same network: detectable via
+  network monitoring (firewall/router logs)
+
+Driver-Level Detection:
+- interception.sys: known driver signature, detectable via
+  module enumeration and PiDDBCacheTable
+- Logitech G HUB DLL injection: detect unexpected DLL loads
+  into GHUB process, or specific exploitable GHUB versions
+  via file version checking
+
+Limitations:
+- Pure hardware HID injection (KMBox, Arduino) is fundamentally
+  indistinguishable from real mouse input at the HID protocol level
+- Detection must rely on statistical input analysis rather than
+  driver/device-level signatures
+- Dual-machine setups with capture cards leave zero footprint
+  on the gaming PC beyond the hardware input device
 ```

 ## Anti-Cheat Architecture
@@ -108,11 +108,177 @@ This skill covers game-hacking techniques documented in the awesome-game-securit

 ### Aim Assistance
 ```
- Aimbot algorithms
- Triggerbot (auto-fire)
+- Aimbot algorithms (memory-based and AI visual)
+- Triggerbot (auto-fire on crosshair detection)
 - No recoil/no spread
- Bullet prediction
- Silent aim
+- Bullet prediction and lead calculation
+- Silent aim (server-side angle manipulation)
+- AI visual aimbot (YOLO-based, no memory access required)
+```
+
+### AI Visual Cheats (Computer Vision Aimbot)
+```
+Architecture overview:
+"Zero memory, zero driver injection" paradigm — uses screen capture +
+AI object detection + hardware input injection. No process attachment,
+no kernel driver, no game memory reading.
+
+Typical setup:
+┌─────────────────┐     screen capture      ┌──────────────────┐
+│  Gaming PC      │ ───────────────────────▶ │  AI Pipeline     │
+│  Game + OBS     │                          │  (same PC, or    │
+│                 │ ◀─────────────────────── │   second PC)     │
+└─────────────────┘     hardware input       │  YOLO model      │
+                        (KMBox / Logitech)   │  TensorRT/CUDA   │
+                                             └──────────────────┘
+
+Dual-machine variant (maximum isolation):
+- Machine A (game): only runs game + OBS, sends frames via NDI/capture card
+- Machine B (cheat): runs AI model, sends mouse commands via USB/network
+  to hardware input device on Machine A
+- Game machine has zero cheat code/process
+
+Single-machine variant:
+- OBS + AI model run on the same PC
+- AI implemented as OBS filter plugin (looks like "OBS is running")
+- Mouse output via hardware device or driver-level injection
+
+Pipeline stages:
+
+1. Frame Capture:
+   - OBS Game Capture (injects graphics hook DLL into game process)
+   - OBS Window Capture (no injection, uses DXGI Desktop Duplication)
+   - OBS plugin filter form (AI as OBS filter, minimal footprint)
+   - Direct framebuffer copy from GPU output layer (60+ FPS)
+   - Capture card (for dual-machine: HDMI/DP input on cheat PC)
+
+2. AI Object Detection:
+   - Model: YOLOv5 / YOLOv8 / YOLOv10 / YOLO11 (lightweight variants)
+   - Training: fine-tuned on game-specific screenshots
+     (enemy bodies, heads, torsos as labeled bounding boxes)
+   - Input: cropped region around crosshair (320x320 or 640x640)
+     to reduce inference cost
+   - Output: bounding boxes with class (head/body/enemy) + confidence score
+   - Acceleration: TensorRT (NVIDIA), CUDA, DirectML, OpenVINO
+   - Target latency: < 20–30 ms per frame for competitive play
+
+3. Coordinate Transform and Aiming Logic:
+   - Convert pixel coordinates to mouse movement delta:
+     delta_x = (target_x - screen_center_x) * sensitivity
+     delta_y = (target_y - screen_center_y) * sensitivity
+   - Target selection: closest to crosshair, highest confidence,
+     head priority, or combined scoring
+   - FOV (Field of View) lock: only engage targets within
+     configurable pixel radius from crosshair center
+
+4. Human-like Trajectory Smoothing:
+   - Not instant snap — gradual movement with acceleration curve
+   - Micro-jitter injection (simulates hand tremor)
+   - Bézier curve or cubic interpolation for path
+   - End-point correction (overshoot then settle)
+   - Random engagement probability (e.g., 85-90% lock rate)
+   - Slight intentional offset (not pixel-perfect center-mass)
+   - Variable reaction delay (50-200 ms simulated human response)
+
+5. Mouse Movement Execution:
+   - Hardware input devices (see Input Simulation section below)
+   - Movement commands sent as physical HID reports
+   - Game sees genuine hardware mouse input, not API calls
+
+Why OBS specifically:
+- Legitimate streaming software, used by millions of streamers
+- Anti-cheat cannot ban OBS-related processes without collateral damage
+- Game Capture provides fast, low-latency frame access
+- Plugin system allows embedding AI as a filter (invisible to AC)
+- Supports D3D11, D3D12, Vulkan, OpenGL capture paths
+```
+
+### YOLO Model Training Pipeline (for Game AI Aimbot)
+```
+End-to-end workflow from raw game screenshots to deployed TensorRT model.
+
+1. Data Collection:
+   - Capture game screenshots during actual gameplay (OBS recording or replay)
+   - Capture diverse scenarios: different maps, lighting, character skins,
+     distances, poses, partial occlusion, smoke/flash effects
+   - Aim for 2,000-10,000+ labeled images for robust detection
+   - Include negative samples (empty scenes, friendlies, environment objects)
+
+2. Annotation / Labeling:
+   - Tools: LabelImg (YOLO format), CVAT (collaborative), Roboflow (cloud),
+     Label Studio, makesense.ai (browser-based)
+   - YOLO format: one .txt per image, each line:
+     <class_id> <center_x> <center_y> <width> <height>
+     (all values normalized to 0-1 relative to image dimensions)
+   - Class definitions (typical):
+     0: enemy_body (full body bounding box)
+     1: enemy_head (head-only bounding box, for headshot targeting)
+     2: friendly (to avoid shooting teammates)
+   - Label head separately from body for head-priority targeting
+   - Quality control: consistent label boundaries, no missed instances
+
+3. Data Augmentation:
+   - Built-in Ultralytics augmentations (mosaic, mixup, copy-paste)
+   - Game-specific augmentations:
+     - Brightness/contrast variation (simulate different map lighting)
+     - Random crop around crosshair area (match inference ROI)
+     - Motion blur (simulate fast movement)
+     - Noise injection (simulate compression artifacts)
+   - Avoid augmentations that distort aspect ratio
+     (characters would look unnatural, hurting accuracy)
+
+4. Training:
+   - Framework: Ultralytics YOLOv8/v10/v11/YOLO11
+   - Base model: yolov8n.pt or yolov8s.pt (nano/small for speed)
+     or yolo11n.pt for latest architecture
+   - Training command:
+     yolo detect train data=game_dataset.yaml model=yolov8n.pt
+       epochs=100 imgsz=640 batch=16 device=0
+   - dataset.yaml structure:
+     path: /path/to/dataset
+     train: images/train
+     val: images/val
+     names: {0: enemy_body, 1: enemy_head, 2: friendly}
+   - Key hyperparameters to tune:
+     - imgsz: 320 (fastest) or 640 (more accurate)
+     - lr0: initial learning rate (default 0.01)
+     - conf: confidence threshold for inference (typically 0.4-0.6)
+     - iou: IoU threshold for NMS (typically 0.45-0.7)
+   - Training time: 1-4 hours on RTX 3060+ for nano model
+
+5. Validation and Testing:
+   - Evaluate mAP@0.5 and mAP@0.5:0.95 on validation set
+   - Target: mAP@0.5 > 0.85 for reliable game detection
+   - Test inference speed on target hardware
+   - Visual inspection on held-out game screenshots
+
+6. Export to TensorRT (deployment):
+   - Step 1: Export to ONNX
+     yolo export model=best.pt format=onnx simplify=True opset=17
+   - Step 2: Convert ONNX to TensorRT engine
+     yolo export model=best.pt format=engine half=True device=0
+     (half=True enables FP16 precision)
+   - Or use trtexec directly:
+     trtexec --onnx=best.onnx --saveEngine=best.engine
+       --fp16 --workspace=4096
+   - FP16 performance: ~17 ms latency, ~57 FPS throughput,
+     ~0.9% mAP drop vs FP32 (acceptable trade-off)
+   - INT8 quantization: even faster but requires calibration dataset
+     and careful accuracy validation
+
+7. Runtime Integration:
+   - Load TensorRT engine in C++/Python inference loop
+   - Input: preprocessed frame (resize, normalize, HWC→CHW, float32/16)
+   - Output: [N, 6] tensor (x1, y1, x2, y2, confidence, class_id)
+   - Apply NMS (Non-Maximum Suppression) to deduplicate detections
+   - Select target based on: closest to crosshair + highest confidence
+   - Convert pixel coordinates to mouse delta
+
+Alternative acceleration backends:
+- DirectML (AMD GPUs, Windows native)
+- OpenVINO (Intel GPUs/CPUs)
+- ONNX Runtime with CUDA EP (cross-platform)
+- CoreML (macOS, less common for game cheats)
 ```

 ### Movement Cheats
@@ -340,7 +506,7 @@ Vector2 WorldToScreen(Vector3 worldPos, Matrix viewMatrix) {

 ## Input Simulation

-### Methods
+### Software Methods
 - SendInput API
 - mouse_event/keybd_event
 - DirectInput hooking
@@ -352,6 +518,129 @@ Vector2 WorldToScreen(Vector3 worldPos, Matrix viewMatrix) {
 - Keyboard filter drivers
 - HID manipulation

+### Hardware Input Devices (for AI Visual Cheats)
+```
+Hardware input devices produce genuine HID reports indistinguishable
+from real mouse/keyboard at the USB protocol level. This is the
+critical stealth layer for AI visual aimbot setups.
+
+KMBox series (KMBox Net, KMBox B Pro, KMBox B+):
+- Standalone hardware device connected via USB or network
+- Receives mouse/keyboard commands over TCP/UDP or serial
+- Generates real USB HID reports to the gaming PC
+- Gaming PC sees a standard USB mouse, not API-injected input
+- Network variant enables dual-machine setups
+- Supports relative movement, absolute positioning, button events
+- API: simple serial/network protocol for move(dx, dy), click, etc.
+
+Arduino / Teensy / STM32 microcontroller:
+- Custom firmware emulating USB HID device
+- Receives commands from cheat PC via serial/USB CDC
+- Generates USB HID mouse reports
+- Cheapest hardware option, fully customizable
+- Leonardo / Pro Micro (ATmega32U4) most common for native USB HID
+
+Logitech driver exploitation:
+- Older versions of G HUB / LGS (Logitech Gaming Software) expose
+  internal APIs for mouse movement
+- ghub_mouse_move() or lgs_mouse_move() via DLL injection into GHUB
+- Logitech devices have driver-level whitelist advantage
+- Specific driver versions required (newer versions patched)
+- No external hardware needed, but driver-version-dependent
+
+Interception driver (interception.sys):
+- Open-source keyboard/mouse filter driver
+- Intercepts and injects input at driver level
+- Commonly used with AI aimbots for zero-hardware-cost injection
+- Detectable by anti-cheat (driver signature known)
+
+HDMI/DP KVM-style middleman:
+- Hardware device sitting between mouse and PC
+- Intercepts real mouse data, injects AI-calculated deltas
+- Transparent to both the mouse and the PC
+- Highest stealth but most complex hardware setup
+
+Detection difficulty ranking:
+1. Dedicated hardware (KMBox, Arduino HID) — hardest to detect
+   (genuine USB HID, no driver anomaly)
+2. KVM middleman — very hard (transparent hardware interposer)
+3. Logitech driver method — moderate (known driver versions)
+4. Interception driver — easier (known driver signature)
+5. SendInput / mouse_event — easiest (API-level, trivially detected)
+```
+
+### KMBox Protocol Details
+```
+KMBox Net (network variant) — UDP-based protocol:
+
+Packet header (16 bytes, Little-Endian):
+Offset  Field      Size   Description
+0x00    MAC        4 B    Device UUID (unique per device, used for auth)
+0x04    RAND       4 B    Random value or parameter
+0x08    INDEXPTS   4 B    Incrementing sequence number (replay protection)
+0x0C    CMD        4 B    Command code
+
+Key command codes:
+Code          Command          Description
+0xAF3C2828    connect          Establish connection with device
+0xAEDE7345    mouse_move       Direct mouse movement (dx, dy)
+0xAEDE7346    mouse_automove   Human-like movement with interpolation
+0xA238455A    mouse_beizer     Bézier curve mouse movement
+0x9823AE8D    mouse_left       Left button press/release
+0x238D8212    mouse_right      Right button press/release
+0x97A3AE8D    mouse_middle     Middle button press/release
+0xFFEEAD38    mouse_wheel      Scroll wheel
+0x123C2C2F    keyboard_all     Keyboard key event
+
+Mouse API functions:
+- move(x, y):                 Direct relative movement, no interpolation
+- move_auto(x, y, ms):        Human-like movement over ms milliseconds,
+                               built-in Bézier curve interpolation
+- move_beizer(x, y, ms,       Second-order Bézier curve with custom
+    x1, y1, x2, y2):          control points for trajectory shaping
+
+Encrypted variants (enc_*):   Same functions with packet-level encryption
+                               to resist network packet analysis
+
+Performance:
+- Network (UDP): ~1,000 commands/second
+- Serial (KMBox B/B+, 115200 baud): ~300 commands/second
+- Network latency: < 2 ms per command (LAN)
+
+KMBox B / B Pro (serial variant):
+- USB CDC serial communication (COM port)
+- Baud rate: 115200 or higher
+- Simpler protocol: ASCII or binary command frames
+- move(x, y) over serial: ~3 ms round trip
+
+Physical keyboard/mouse monitoring:
+- monitor() function reads real user input from the device
+- Enables "pass-through + inject" mode:
+  real user input flows through normally,
+  AI-calculated deltas are added on top
+
+Arduino / Teensy HID protocol:
+- Custom serial command format (typically simple ASCII):
+  "M,dx,dy\n"      — mouse move
+  "C,button\n"      — click (1=left, 2=right, 3=middle)
+  "K,keycode\n"     — keypress
+- USB HID report generated by ATmega32U4 (Leonardo)
+  or ARM-based Teensy (3.2, 4.0, 4.1)
+- HID report descriptor mimics standard mouse:
+  buttons (3 bits) + X delta (8-16 bits) + Y delta (8-16 bits)
+- No custom driver needed — OS uses generic HID driver
+
+Logitech driver API (exploitable versions):
+- G HUB versions prior to certain patches expose internal functions
+- Key DLLs: LGS (lcore.dll), G HUB (ghub_mouse.dll or internal APIs)
+- ghub_mouse_move(dx, dy) or equivalent internal symbol
+- Accessed via DLL injection into GHUB process
+  or LoadLibrary + GetProcAddress
+- Movement appears as Logitech device input in the HID stack
+- Patched in newer G HUB versions; specific version numbers
+  circulate in cheat communities
+```
+
 ## Anti-Detection Techniques

 ### Code Protection
@@ -291,6 +291,85 @@ D3DXVECTOR3 WorldToScreen(D3DXVECTOR3 pos, D3DXMATRIX viewProjection) {
 - Kernel-level: suppress screenshot by blocking DC access
 ```

+## OBS Capture Pipeline and AI Visual Cheat Surface
+
+### OBS Frame Capture Modes
+```
+OBS (Open Broadcaster Software) is the primary frame source for
+AI visual cheats. Its capture modes have distinct detection profiles:
+
+Game Capture (most common for cheats):
+- Injects obs-graphics-hook64.dll into game process
+- Hooks IDXGISwapChain::Present (D3D11/12) or SwapBuffers (OpenGL)
+  or vkQueuePresentKHR (Vulkan) inside the game process
+- Copies backbuffer to shared texture/memory each frame
+- Lowest latency, highest quality (pre-composition, native resolution)
+- Detection: DLL appears in game process module list;
+  shared texture handle creation visible to kernel callbacks
+
+Window Capture:
+- Uses DXGI Desktop Duplication API (no injection into game)
+- Captures composited window output from DWM
+- Slightly higher latency (post-composition)
+- Detection: IDXGIOutputDuplication usage from non-game process
+
+Display Capture:
+- Captures entire monitor output
+- Highest latency, captures everything including overlays
+- No per-process interaction
+
+OBS Virtual Camera:
+- Outputs captured frames as a virtual camera device
+- Can feed AI model running in separate process or machine
+- Detectable via virtual camera driver enumeration
+```
+
+### Frame Pipeline for AI Aimbot
+```
+Capture path (latency-critical):
+  Game render → Present hook copies backbuffer
+  → Shared GPU texture (ID3D11Texture2D, GPU-side)
+  → GPU→CPU readback (staging texture + Map/Unmap)
+  → CPU-side frame buffer (system memory)
+  → Crop to ROI (Region of Interest, e.g., 640x640 around crosshair)
+  → AI inference input (CUDA/TensorRT/DirectML)
+
+OBS plugin form factor:
+  AI model implemented as OBS video filter plugin
+  → Receives frames through obs_source_frame callback
+  → Runs inference in-process
+  → Outputs mouse commands to hardware device
+  → Appears as "OBS running a filter" to the system
+
+Dual-machine pipeline:
+  Game PC OBS → NDI (Network Device Interface) or capture card
+  → Cheat PC receives video stream
+  → AI inference on cheat PC GPU
+  → Mouse commands sent via network to KMBox on game PC
+  Latency: +5-15 ms for NDI, +2-5 ms for hardware capture card
+
+Performance targets:
+  Capture: < 5 ms (GPU shared texture copy)
+  Crop + preprocess: < 2 ms
+  YOLO inference: 5-15 ms (TensorRT FP16 on RTX 3060+)
+  Coordinate calc + smoothing: < 1 ms
+  Hardware input transmission: < 2 ms (USB) or < 5 ms (network)
+  Total pipeline: 15-40 ms end-to-end
+```
+
+### Detection-Relevant Graphics Signals
+```
+- obs-graphics-hook64.dll in game process module list
+- IDXGISwapChain::Present hook or detour in game process
+- Staging texture creation at frame rate (ID3D11Texture2D with
+  D3D11_USAGE_STAGING + CPU_ACCESS_READ created per frame)
+- GPU-to-CPU memory copy bandwidth anomaly (Map/Unmap calls
+  at 60+ FPS on backbuffer-sized resources)
+- DXGI shared handle creation from game process to external process
+- NDI SDK DLLs loaded (Processing.NDI.Lib.*.dll)
+- Virtual camera driver (obs-virtualcam) registered
+```
+
 ## Anti-Detection Considerations

 ### Present Hook Detection
@@ -298,6 +377,7 @@ D3DXVECTOR3 WorldToScreen(D3DXVECTOR3 pos, D3DXMATRIX viewProjection) {
 - VTable integrity checks
 - Code section verification
 - Call stack analysis
+- Module list scanning for known capture DLLs
 ```

 ### Evasion Techniques