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.
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.
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.
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:
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.
The cheat ships five separate screen capture backends, selectable by user configuration:
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.
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:
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.
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.
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.
With all this in mind, we have six things worth taking away from this article we want to call out:
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.