Welcome back to the blog. If you’re just joining us, I’d highly recommend starting with Part 1 of this series, where we go into why we reverse engineered a video game cheat, and our methodology behind it. In this post, we’ll be detailing our findings on the cheat itself, and provide some defensive takeaways for professionals to help secure their ecosystem.
As a reminder, due to my own past experiences, work, and personal preferences, I’ve chosen a cheat for Bungie’s Destiny 2 as my working sample.
One more point before we continue: while this blog breaks down the cheat we examined, I won’t be naming the vendor or providing specific IOCs related to them. I’m not in the habit of providing cheat developers free advertising on a corporate blog.
But if this grabs your interest, the full technical report is available to vetted parties to help your teams increase possible detections and raise awareness about this new cheat variant.
Download it here and you can always contact us with any questions.
With that in mind, let’s dive right in.
Introduction
The marketing is fairly straightforward: an AI-powered aimbot, undetectable, and available to anyone with a credit card. The vendor sells varying subscription tiers for more than eighteen game titles, operates a Discord community with thousands of active members, and has been in operation long enough that its product line has matured into something that feels much closer to an enterprise software business than a hobbyist side project.
I know these are bold claims. But after spending time taking this software apart, independently and outside of any client engagement or request, and largely out of professional annoyance, I can tell you which ones are accurate.
Most of them, it turns out.
More Than a Hobby
Let’s start by framing the investigation, because it matters for how we think about enforcement going forward.
The cheat was legitimately purchased from the vendor’s storefront. That’s a functional website with product tiers, subscription pricing, refund policies, and customer support. The purchase process itself was unremarkable. Pay, receive a license key, download and execute an installer. No back channels or subterfuge required.
The vendor operates under a brand that covers a family of cheats built on the same underlying engine. At the time of our research, there are over eighteen games offered in their catalog, spanning first-person shooters, battle royales, and ARPG automation bots.
The community infrastructure is substantial, featuring a Discord server with over 12,000 members, multilingual support, and structured channels for announcements, tier-specific help, and hardware guidance. The vendor appears to originate internationally, with payment infrastructure routing through international processors.
This is a commercial software business, not one individual’s side project. It has the threat model of such a business: storefront presence, customer relationships, payment rails, and community infrastructure. The actual cheat binary is interesting, but it’s only part of the picture.
Another note I want to call out before continuing: the vendor has already shipped cheats for titles released just in the past year. While we examined the Destiny 2 cheat variant, another version exists for Bungie’s newest title, Marathon. While we didn’t break down the Marathon cheat, based on our findings the engine carries over. The problem isn’t simply confined to one game.
The AI Claim is Real – And Designed Specifically to Avoid Detection
Here’s the big design choice that gives the whole product its character: it does not read, write, or touch the game’s memory.
Most people who’ve followed the anti-cheat arms race are familiar with memory read cheats. They’re software that dips directly into the game process’s address space to pull coordinates, health values, or player state directly. Kernel-level anti-cheat systems like BattlEye and Easy Anti-Cheat are heavily oriented around detecting this kind of intrusion. They monitor process access, hook system calls, and watch for suspicious model loads.
This cheat sidesteps all of that. Instead of reading the game’s memory, it watches the screen. While this means that the cheat isn’t as fully featured as others on the market, lacking wallhack or infinite ammo features for example, it has one key advantage: it is much, much, much harder to detect.
The screen reading pipeline is a computer vision stack: capture the game’s framebuffer, run a neural network object detector over those pixels, identify targets, move the mouse. This means that the “AI” label is in fact accurate; these are real, trained models doing real inference. We were able to recover three of them.
The models are all YOLOv5-family ONNX detectors, encrypted inside the host DLL. Once recovered, they’re quite cleanly structured:
- Light (~13.8 MB): a YOLOv5n-class architecture optimized for speed, aimed at users whose GPU is already competing with the game for resources.
- General (~24.3 MB): A YOLOv5s-class middle tier that splits the difference between the upper and lower bounds.
- Large (~148 MB): a YOLOv5l-class high-precision model for setups where accuracy matters more than frame rate.
All three operate on 480×480 pixel input and detect three classes: “Enemy,” “AllyDot,” and “Head.” The class list is game-specific; enemy silhouettes, friendly unit markers to suppress false positives, and head regions for specific targeting.
The models themselves are not public Ultralytics exports. The two smaller tiers use “LeakyReLU” as their activation function rather than the Ultralytics’s default “SiLU” export. This serves two purposes for these models: better inference performance on weaker GPUs, and resistance to naïve graph-matching detections that compares against known public YOLO checkpoints. The vendor chose an activation that makes both operational and evasion sense.
The large model does use “SiLU,” but with custom weights. This is a 3-class fine-tune, not a public checkpoint.
These design decisions are impactful for defenders. Memory-read cheats can make decisions in microseconds. Meanwhile, a computer vision pipeline operating at 480×480 takes milliseconds, thousands of times slower than memory-read. That’s the trade the vendor has chosen to make, stealth over speed. However, in practice this isn’t as relevant to the average cheater. Aim assistance shouldn’t be instantaneous when you’re trying to mimic a real human’s reaction time.
The evasion implication is stark. Kernel-level anti-cheat watching the game process boundary will see nothing unusual, because there’s nothing unusual to see. The cheat lives and operates entirely outside the destiny2.exe process.
Five Ways to Watch the Screen
The cheat ships five separate screen capture backends, selectable by user configuration:
- DXGI Desktop Duplication: The same family of APIs that OBS and other legitimate game capture software use. It’s efficient, GPU-accelerated, and commonly observed in anti-cheat telemetry.
- GDI BitBlt: A classic fallback, used when the DXGI path is unavailable or unreliable.
- WinRT Graphics Capture: The modern Windows Graphics Capture API
- DWM Thumbnail: A lower-level path using “DwmRegisterThumbnail” on the target window handle. This is less commonly instrumented in anti-cheat telemetry.
- Capture Card: The one that changes the conversation entirely.
The first four screen capture mechanisms all share a common property: they run on the machine where the game is running. That means the cheat process, its modules, and its capture activity all exist on the same endpoint watched by anti-cheat.
The fifth doesn’t work that way.
In a capture card setup, we have the actual game, in this case Destiny 2, running on Machine A. The cheat itself runs on Machine B, an entirely separate device. A hardware capture card passes the video signal between them over HDMI or USB. Machine A sends the video out, Machine B receives it, runs inference on it, and sends back mouse commands over a separate path.
In that topology, there is no cheat process on the game machine. Anti-cheat software watching Machine A sees a normal game client, normal video output going out to what looks like a standard display, and seemingly normal mouse input coming in from a connected device. The entire machine learning inference workload, like captured frames, model execution, and the target selection logic, is on a machine that anti-cheat never looks at and has no access to.
This is architecturally similar to DMA (Direct Memory Access) cheat setups that the anti-cheat community has been contending with for the past several years, but the mechanism is entirely different. DMA cheats read memory over PCIe, while this cheat reads pixels over video. The evasion logic is the same: put the sensitive workload on a second machine that the game’s anti-cheat cannot observe.
The implications for detection strategies are blunt. If your detection model asks, “does this process look suspicious?,” you’re already asking the wrong question for this topology.
The Mouse Doesn’t Lie, if You Know Where to Look
Even when the detection and inference run on a separate machine, the aim assistance has to get back to the game somehow as mouse input. The cheat takes that injection path seriously.
Four input methods were observed:
- Arduino HID Firmware: The cheat ships with pre-compiled firmware for Arduino-class microcontrollers (specifically ATmega32U4-based boards), along with “avrdude,” as well as everything needed to flash the firmware onto a cheap development board. Once flashed, the board presents to the OS as a USB mouse.
However, the USB vendor and product identifiers written into the firmware are placeholder values that no legitimate peripheral manufacturer uses. Plug the board in, and your OS reports a new HID mouse from a VID/PID combination that exists nowhere in the hardware ecosystem. That’s a high-signal detection indicator, if you’re looking at the USB layer. - Makcu: A commercially available hardware device used by the cheat for serial-over-USB mouse emulation. This also supports the Ethernet-bridged dual-PC topology.
- DD (Driver-Based): A kernel-mode mouse driver path that leverages third-party driver ecosystems already present on the machine. These are not shipped in the installer. Rather, the cheat relies on what’s already installed.
- Interception: A low-level Windows input interception framework.
Of these, we consider the Arduino path most interesting from a detection standpoint, as the vendor supplies the firmware and flashing toolchain. There’s also no ambiguity about what this hardware is doing, and the custom VID/PID is recoverable from the firmware hex file included in the package.
Another notable detail to call out here is the advertised “humanized aiming” feature. The cheat includes UI settings explicitly designed to make automated mouse movements look human. The settings include adjustable smoothing, variable correction speed, and randomized input timing. The vendor’s own UI labels these settings as “stream-safe,” with the stated use case being cheat operation while broadcasting gameplay.
The vendor is explicitly modeling human-behavior analysis as a detection threat and building countermeasures for it into the product UI. This is crucial. It shows that the vendor has aim behavior analysis on the radar as a detection vector and is actively shipping countermeasures against it.
Network Footprint
The cheat is a commercial software product, and like most others it phones home accordingly.
License validation runs approximately every 60 seconds from a standalone process. Content updates and tier checks happen approximately every hour. The cheat also performs an active check for host file tampering; if it detects that its license servers have been blocked via an “/etc/hosts” or Windows host file modification, it immediately terminates.
The design is fail-closed: no license server contact, no execution.
The cheat also contains an alternative authentication path via Patreon OAuth, a browser-based flow that authenticates against a Patreon subscription rather than a product key. While at the time of our research the campaign in question has been suspended for policy violations, the code path remains. Two things make this particularly useful from a defensive perspective.
First, the cheat process runs independently of the game. Destiny 2 does not need to be running, and BattlEye does not need to be attached. Installation, license activation, hardware setup, and every license heartbeat can happen before the game starts and before any game-side anti-cheat is running. If you have network telemetry that predates game launch, you have a detection window that doesn’t depend on the game’s anti-cheat at all.
Of course, this asks another question of “why is your anti-cheat running when the game is not,” but the window remains.
Second, raw packet captures will not provide hostnames. Everything is TLS-encrypted. Seeing the handshakes may tell you that a connection was made, but it doesn’t say to whom. Detection at the network level requires DNS telemetry, SNI visibility, proxy logs, or memory inspection. Most network-focused detection setups aren’t instrumenting SNI on outbound client traffic, and the cheat exploits this gap by design.
One Engine, Escalating Coverage
The product catalog offered by this cheat vendor is not a collection of unique and distinct tools. It’s one engine with multiple game-specific frontends, or what we call a framework cheat. The actual operations are run from common systems for all games, with specific files added to ensure functionality with the game itself.
The internal code structure makes this explicit. A core infrastructure layer handles screen capture, machine learning inference, input injection, and licensing. Game-specific modules sit on top of it and provide title-specific target selection logic, UI configuration, and model customization.
As a result, enforcement against one product doesn’t touch the underlying engine. The operator just builds a new frontend and the rest carries over.
This matters significantly for enforcement strategies. A detection built around the engine’s behavior signatures, such as the ONNX runtime stack, the DirectML GPU execution path, the specific combination of capture and input libraries, and the license heartbeat pattern, is more durable than a detection built around one game title. The vendor updates individual products, but they can’t update the fundamental architecture characteristics without rebuilding the platform.
The developer and operator of the cheat is strongly believed to reside internationally, has been operating their service for years, and shows clear signs of active engineering investment. This is not a product that’s going to quietly disappear because one title’s anti-cheat updates its signature database.
What This Means for Defenders
With all this in mind, we have six things worth taking away from this article we want to call out:
- Game-process monitoring is necessary but not sufficient. This cheat is designed around the assumption that game-process-centric detection is the primary threat. Layered telemetry, considering peripheral devices, network traffic, and standalone processes, is required to cover the attack surface.
- The dual-PC/capture card topology creates a genuine blind spot in endpoint-centric approaches. When the inference runs on a separate machine and input arrives through emulated hardware, the game machine may show nothing anomalous at all. Behavioral aim analysis and USB/HID telemetry become primary, not secondary.
- USB telemetry is underutilized. The Arduino firmware path ships with recoverable and distinctive VID/PID identifiers that don’t correspond to any legitimate peripheral. This is a high-confidence detection signal that most detection stacks don’t instrument.
- Network detection predates game launch – but not for everyone. License heartbeats fire from a standalone process before any game-side anti-cheat is running. For endpoint security vendors, enterprise environments, or researchers doing active investigation, DNS, SNI, and proxy visibility can surface this activity entirely outside the game context. For game publishers and anti-cheat providers specifically, however, this network isn’t directly actionable. There’s no telemetry on a player’s home network. What this finding is useful for is characterizing the threat. This cheat runs a persistent, commercial licensing infrastructure that operates independently of the game. That’s the infrastructure that supports enforcement approaches like domain takedowns, payment processor reporting, and abuse team referrals.
- “Humanized Aiming” is the vendor acknowledging behavioral detection works. They’ve built smoothing and timing randomization into the product specifically to defeat aim behavior analysis. That means that such behavioral analysis is worth doing. It’s threatening enough that the vendor is investing in countermeasures against it.
- This is a commercial ecosystem with commercial attack surfaces. Storefront abuse, payment processor reporting, Discord community policy enforcement, and domain takedowns are enforcement mechanisms that don’t require breaking a single binary. For an operator running a subscription business with thousands of customers, these surfaces matter.
Closing
The full technical report from this research, which includes Sigma rules, YARA skeletons, detailed IOCs, and the complete capabilities analysis is available on request for qualified stakeholders. We consider that to be game publishers, platform security teams, legal counsel, and cybersecurity professionals interested in the mechanics of the cheat.
This analysis also reflects one build at one point in time. The vendor updates. The engine evolves. Once we publish this, the vendor will likely become aware even without their name mentioned, and our findings could be invalidated. That’s the nature of the anti-cheat arms race. However, some things don’t or cannot be changed quickly.
The architectural choice to use computer vision over memory reads, the dual-PC evasion topology, the hardware injection infrastructure, and the commercial business model are all durable characteristics that defenders can build against, regardless of which title or build version they have in front of them.
If this is the kind of problem you’re working on or piques your interest, reach out to the Armada team. Collaboration is the best step towards creating secure ecosystems for developers, their games, and the players who love them.
Steve Guris is Threat Intelligence Lead at risk3sixty, where he focuses on cybercrime research, threat actor monitoring and hunting, and incident response. His work spans the full threat intelligence lifecycle — from pre-incident adversary profiling to active investigation support.
He is best known publicly for his work in gaming security, including expert analysis in federal litigation involving commercial game cheats: a declaration in Bungie v. Wallhax and expert witness testimony at the Bungie v. Phoenix Digital (AimJunkies) federal jury trial. He has spoken at GDC on gaming security topics, most recently on a 2026 panel with Perkins Coie LLP on investigating and enforcing IP and contractual rights in games.
Part of the Armada team: CREST-accredited team members who run continuous exposure management and red teaming for our clients.
