Project 06 - Pixel Triggerbot

Count3rbalanc3

Python Valorant Color Detection Anti-Cheat Research License System tkinter

Overview

Count3rbalanc3 is a fully-featured, color-based triggerbot built in Python, targeting Valorant. It is the fiftieth iteration of an evolving codebase, reflecting extensive incremental development over a long period.

Beyond its function as a game tool, the project serves as a practical case study in screen-capture-based detection evasion — a research domain that exposes a fundamental blind spot in kernel-level anti-cheat systems. The tool operates entirely through standard OS APIs, making it indistinguishable at the system level from legitimate software such as accessibility tools or screen recorders.

Core Concept

Traditional game cheats work by reading or writing to game memory — injecting DLLs, hooking system calls, or manipulating rendering pipelines. Anti-cheat software like Vanguard (Valorant) and EAC (various titles) specifically targets these vectors through kernel-level drivers, integrity checks, and signature scanning.

Count3rbalanc3 sidesteps all of this by operating outside the game process entirely. It uses only:

• Screen capture via mss — a standard OS screenshot API
• NumPy pixel analysis — pure computation on captured image data
• Synthetic key input via pynput — the same mechanism used by accessibility software and test automation

There is no memory reading, no code injection, no driver interaction, and no game process communication of any kind. This means the entire attack surface that anti-cheat systems monitor is bypassed by design.

Architecture

The application is structured around four main components that operate concurrently:

• License Gate — runs once at startup, validates the user's license key against a remote Supabase backend before anything else launches.
• ColorTrigger — the core detection and input engine, running in a dedicated daemon thread. Continuously captures and analyzes a configurable screen region and injects key presses when conditions are met.
• tkinter GUI — the primary interface running on the main thread: sliders, dropdowns, preset management, session persistence.
• Overlay Windows — two always-on-top transparent windows updating via after() polling loops: one visualizing the scan region, one showing toggle state.

All components are non-blocking relative to each other. The capture loop runs on its own thread, overlays update asynchronously, and the GUI remains responsive at all times.

Trigger Engine

The ColorTrigger.run() loop uses mss to capture a small rectangular region — the "grab zone" — centered on the screen where the crosshair sits. The grab zone dimensions and offsets are all configurable via sliders. The default is 10×10 pixels, deliberately small to minimize false positives and reduce CPU overhead. Each captured frame is converted to a NumPy array for pixel-level processing.

Color Detection

Two target colors are hardcoded as the detection targets:

target_colors = [(255, 100, 255), (122, 15, 110)]
# Bright magenta/pink and dark purple — enemy highlight colors in-game

Two complementary methods run on every frame:

• searcherino(img) — flattens the entire grab zone to a pixel array and checks whether any pixel falls within tolerance of either target color using vectorized NumPy operations.
• is_color_in_crosshair(img) — checks only the exact center pixel of the grab zone, providing a tighter, lower-latency confirmation for direct crosshair hits.

Color matching applies a configurable tolerance (default: 33) symmetrically across each RGB channel:

mask = (
    (pixels[:, 0] > R - tol) & (pixels[:, 0] < R + tol) &
    (pixels[:, 1] > G - tol) & (pixels[:, 1] < G + tol) &
    (pixels[:, 2] > B - tol) & (pixels[:, 2] < B + tol)
)

Input Injection

When a color match is detected and all gate conditions pass, a key press is injected via pynput:

self.keyboard_controller.press(resolve_key(key))
self.keyboard_controller.release(resolve_key(key))

The key is user-configurable (default: e). A helper resolve_key() translates string names like 'f9', 'space', or 'ctrl_l' into pynput key constants, covering the full range of special keys.

Gate Conditions

The trigger only fires when all of the following are simultaneously satisfied:

Condition	Default	Purpose
Activation key held or always-on active	Shift / F9 toggle	Prevents accidental triggers
Movement key delay not active	0 ms	Suppresses fire during WASD + N ms after release
Right-click delay elapsed	250 ms	Suppresses fire immediately after scoping in
Color detected in grab zone	—	Core detection condition

After a match, two optional delays run in sequence: a first shot delay before the keypress (simulating human reaction lag) and a trigger delay after (preventing mechanical rapid fire).

Keyboard & Mouse Listeners

Two pynput listeners run as background threads:

• Keyboard listener — tracks pressed keys for the activation key, toggle hotkey, preset hotkeys (F1–F8), and WASD movement state. Also binds number/function keys to directly update the "key to press" dropdown for quick in-game remapping.
• Mouse listener — detects right-click events and records the timestamp for the right-click delay gate.

GUI & UX

The interface is built with tkinter styled in a Nord color scheme — the same palette as this site. The window is 335×750 pixels, compact enough to sit alongside a game window or on a secondary monitor.

Nine sliders control core behavior. Each uses a custom slider_row() helper that wires together a ttk.Scale, a live value label, and a double-click popup for entering exact numerical values — a UX detail that reflects the 50-iteration polish of the codebase.

Slider	Range	Default
Color Tolerance	1–100	33
Trigger Delay	0–500 ms	0
First Shot Delay	0–300 ms	0
Movement Key Delay	0–300 ms	0
Right Click Delay	0.5–300 ms	250 ms
Grab Zone Top Offset	1–40 px	8
Grab Zone Left Offset	1–40 px	8
Grab Zone Width	1–40 px	10
Grab Zone Height	1–40 px	10

Overlays

• GrabZoneOverlay — a transparent window positioned exactly over the active grab zone, outlined in magenta with a red center dot. Useful for calibrating the scan region. Toggled with H or the "Show Grab Zone" button.
• ToggleStatusOverlay — a small TOGGLE: ON indicator at the left edge of the screen whenever always-on mode is active.

Both overlays use attributes("-transparentcolor", ...) for true window transparency, polling for state updates every 100–200 ms via after().

On window close, all settings are serialized to trigger_config.json and restored on the next launch — slider values, selected keys, preset data, preset names, and hotkeys all persist across sessions.

Weapon Presets

Eight weapon presets are baked in, each pre-configured with empirically tuned movement and right-click delay values matched to the weapon's play style:

Preset	Movement Delay	Right Click Delay	Hotkey
Marshal	97 ms	109 ms	F1
Outlaw	89 ms	107 ms	F2
AWP	110 ms	207 ms	F3
Chamber Ult	113 ms	105 ms	F4
Sheriff	75 ms	90 ms	F5
Deagle	80 ms	95 ms	F6
Operator	115 ms	215 ms	F7
Guardian	95 ms	100 ms	F8

Each preset stores the complete parameter set — not just delays but tolerance, trigger delays, activation key, toggle key, and grab zone dimensions. The higher right-click delays on scoped weapons (AWP: 207 ms, Operator: 215 ms) reflect the longer scope-in animation time, during which firing would be ineffective. Preset switching is instant and hotkey-driven, enabling mid-game weapon-matched reconfiguration without alt-tabbing.

License System

The tool includes a commercial license gate backed by a live Supabase (PostgreSQL) database.

• On first launch, a tkinter dialog prompts for a license key.
• The key is validated against the remote licenses table via the Supabase REST API.
• If the license's machine_id field is null, it is set to the current machine's ID — locking the license to that machine.
• If the stored machine ID matches, the check passes silently. Any other machine is rejected.
• The validated key is cached locally in license_info.json to avoid re-querying on every launch.

Machine identity is derived from the MAC address via Python's uuid.getnode(). System metadata (OS version, CPU count, platform string) is also collected at validation time, though only machine_id is enforced by the current schema.

Anti-Cheat Implications

This project is a concrete demonstration of a cheat category that fundamentally challenges the model on which modern kernel-level anti-cheat is built.

Anti-cheat systems like Riot's Vanguard operate at ring-0 and are designed to detect: memory reads/writes targeting game processes, code injection or DLL hooking, unsigned kernel drivers, process integrity violations, and known cheat signatures in loaded modules. Count3rbalanc3 does none of these things. Its entire attack surface is mss.grab() (used by OBS and every streaming app) and pynput key injection (used by every automation framework and accessibility tool). From the kernel's perspective, it is semantically identical to a screen recorder that occasionally presses a key.

Catching screen-based triggerbots requires moving beyond process and memory inspection entirely:

• Reaction time analysis — human reaction to visual stimuli averages 200–250 ms. A triggerbot running at screen-capture frequency can react in under 16 ms (one frame at 60 fps). Server-side shot timing logs with statistical analysis of shot latency distributions can flag superhuman consistency.
• Input pattern analysis — the tool fires on every frame a color is detected with optional fixed delays, producing mechanically consistent input cadences that differ statistically from human variability. Behavioral ML models can detect this signature.
• Screen capture API monitoring — an anti-cheat driver could flag high-frequency screen capture calls from non-whitelisted processes. Technically feasible but risks breaking legitimate software.
• Hardware fingerprinting — once detected by any method, banning requires hardware-level fingerprinting beyond MAC address or account identity to prevent trivial re-entry.

Defensive Response

The existence of this class of tool suggests anti-cheat must evolve toward behavioral analysis rather than relying solely on artifact detection.

The most robust detection surface is the game server. Shot timing, crosshair position at the moment of fire, kill consistency rate, and reaction latency distributions are all observable server-side without any client instrumentation. Aggregating these over time and flagging statistical outliers — such as sub-50 ms reaction times sustained across a full game — is far harder to evade than client-side scanning, since reducing the cheat's speed enough to avoid statistical flagging also degrades its effectiveness to near-human levels.

Ethics & Research Context

The development of Count3rbalanc3 was conducted as a controlled investigation into anti-cheat evasion at the OS boundary. Testing was performed against bots in offline environments — the tool was never deployed against live players in real matchmaking and was not publicly distributed.

The value of this work lies in making the threat concrete. Abstract arguments about screen-capture cheats are less persuasive to security engineers than a working, polished, commercially-viable implementation that demonstrably evades state-of-the-art anti-cheat. Understanding what evades detection is a prerequisite for designing detection systems that don't.

The 50-iteration development history reflects the kind of sustained engineering investment that real-world adversarial tooling accumulates over time — something that point-in-time detection research often underestimates. Defensive systems need to account not just for current implementations but for the accumulated polish and adaptability of mature adversarial codebases.

Tech Stack

All dependencies are pure-Python or have lightweight native extensions. The tool runs on any Windows machine with Python 3.8+ and requires no elevated privileges or driver installation — further underlining why it presents no signature to ring-0 anti-cheat monitors.