Reverse Engineering a Commercial AI Cheat: How AI Agents Changed the Way We Work (Part 1)

This story is just scratching the surface. Want to read the full report with extensive and detailed technical notes? Download it here.

Introduction 

Welcome to a security company's first blog post about video game cheats. That's probably a surprising point for us to write about but let me lay out some facts that'll make this clearer.

First of all, some background on me as the author to establish why a threat intelligence professional would care about this. I have a long and documented public history examining game cheats, previously on behalf of Bungie, Inc., the developers originally responsible for the Halo franchise and currently operating Destiny 2 and Marathon.  

I submitted expert declarations in the Bungie v. Wallhax case related to the cheat reading browser windows, including health portals for active US military service members.¹ I also testified in federal court in the Bungie v. Phoenix Digital case and have gone on the record offering my findings and opinions on cheat operations and the developers responsible for them.

Personally, I have over 2,200 hours logged in Destiny 2. Images of my Guardian² were used within my federal expert witness submissions, and how good my in-game fashion was is a matter of public record. That's not a confession or a flex; it's context on my stake in this process.  

Why Write About Cheats?  

Let’s talk about the scale of the cheat industry as a whole. It’s no longer a niche annoyance for a small collection of individuals or game companies. Current research shows that video game cheats are now a legitimate security and business concern worth serious attention.

As of 2026, the commercial game cheat economy has been estimated at $8.5 billion in annual revenues by the game security firm Intorqa,³ which represents larger revenue than the entire UK video games market, as well as the projected global esports revenue. That’s not a hobbyist grey market, it’s an industry with storefronts, subscriptions, customer support, and structured product lines. A quick search for any major title will surface dozens of openly operating commercial cheat providers.  

As I mentioned briefly, the legal industry is starting to catch up to this economic shift. Publishers have pursued cheating companies through civil lawsuits with increasing aggression and success. Bungie’s case against Phoenix Digital Group, responsible for the Aimjunkies suite of cheats, is the most instructive recent example.  

In a jury trial, believed to be the first of its kind for a modern video game cheat case, returned a verdict in Bungie’s favor, and subsequent judicial findings of evidence destruction pushed total damages to over $4.3 million, including $3.65 million in damages and more than $738,000 in legal fees.^4,5 The case also established precedent in the legal system to make it meaningfully easier for other game companies to bring similar cases.  

The stakes for developers, however, aren’t simply legal. The reputational concerns related to cheating within the game ecosystem are substantial and quantifiable. Research indicates that 78% of players are put off a game with the perception of being infested by cheaters, 70% say they have encountered cheating directly, and 46% say they’re less likely to purchase in-game content in games where they’ve encountered cheaters.^6,7  

For a live-service game whose revenue model depends on sustained player engagement and microtransaction purchases, a cheat ecosystem isn’t a background nuisance. It’s a direct threat to the business.  

With this context in mind, we can develop a clear understanding of what these products actually are on technical, architectural, and commercial levels as related to professional security work, rather than the curiosity of a single gamer. Even if the two aren’t mutually exclusive when the target is an $8.5 billion shadow industry with litigation implications.

A Unique Cheat 

With all of that in mind, let’s start dissecting what actually happened. I have to admit that at multiple events, and in private conversations, I have been very skeptical of the idea of AI-powered cheats. The concept of a model capable of doing real-time screen reading and mouse input while the same machine was running a resource intensive modern AAA video game felt very unreasonable. 

So when I began hearing about a commercial AI-powered cheat that had been quietly operating in the Destiny 2 ecosystem, as well as additional games, for some time, I wasn’t approaching it as an abstract threat actor tooling issue. I was annoyed. I wanted to know what it actually was. 

So I bought it. 

To be clear about something upfront; this was not a client engagement or done at the behest of any entity beyond my own curiosity. Neither risk3sixty nor the Armada team were hired to do this. Rather, given my professional background, this piqued my interest and drove me to understand the nuts and bolts of the cheat, and why it represents a significant escalation in the ongoing arms race between cheat developers and game security professionals.  

Something else worth noting here before we go any further: I won’t be naming the cheat vendor in these posts, nor will I be providing specific IOCs related to their cheat. Frankly, I’m not in the business of providing cheat developers free advertising through corporate blog posts. That said, we do maintain all of that information internally. If you’re interested in learning more specific details, please reach out.  

Regardless, what I found was more interesting than expected, and the way I found it may be just as interesting. With that in mind, this blog post is about methodology. What we used, how we got to our conclusions. Keep your eyes peeled for Part 2, where we’ll show how that methodology was used to dive into the cheat itself.  

An Agentic Approach for Reverse Engineering 

Starting Point: A Windows Installer & No Assumptions 

The cheat we purchased from the vendor’s storefront, our primary artifact for this research, was a standard Windows installer, roughly one gigabyte. No source code, no documentation, no README or installation instructions. Just a setup file and the knowledge that it installs something allegedly capable of running a machine-learning pipeline against a live game.  

The first job with any unknown binary is establishing what you’re actually holding. Not what the filename says. Not what the installer screen claims. What the file is.  

A few quick checks told an interesting story. The outer wrapper was Inno Setup, a legitimate and well known open-source Windows installer framework. Extracting it through standard tooling revealed the actual payload: a .NET/WPF application with its main assembly stripped of readable metadata. Filenames had been replaced with long hex strings, a standard obfuscation practice, and version information was wiped. The application’s primary DLL, when examined through additional tooling, appeared to contain no embedded resources at all.  

The last point there is deliberate, and is the first instance of things getting very interesting.  

Defeating Obfuscation Without Fighting It 

The main DLL we found was protected with VMProtect, a commercial code protection product that wraps native execution paths in virtualized bytecode that’s genuinely difficult to reason about statically. A lot of reverse engineering work on protected binaries tries to go through that kind of protection. That’s slow, painful, and often unnecessary.  

Instead, the approach here was to go around it.  

Commercial .NET applications frequently use a packaging technique called Costura, a library that embeds all of an application’s dependencies as compressed resources inside a single host DLL. These resources are then extracted and loaded at runtime. This is legitimate tooling used by plenty of production software, and it’s just as convenient for cheat developers as it reduces the surface area of what gets installed to disk.  

The protection layer had stripped the manifest resource table, the standard lookup mechanism, explaining why initial tooling saw nothing. But the bytes are still there. By reconstructing the catalog from the embedded resource data and walking backward through the compression scheme, we recovered 146 embedded assemblies in a matter of seconds. Many of them were found to have full PDB symbols, rich class names, and readable method signatures.

The important logic, namely the ML pipeline, input injection system, and licensing client, were all sitting there, cleanly decompiled, and with descriptive names intact.  

The lesson is one worth keeping: protection tools protect what they can reach. Indirect recovery paths frequently survive because the protector can’t know what the runtime will need to be reconstructed at execution.  

The tooling for this from our side involved ilspycmd for .NET decompilation, custom Python tooling for the catalog reconstruction and resource extraction, and Ghidra for anything in the native or obfuscated layer that needed traditional disassembly. 

AI Agents Engage 

Once you have decompiled .NET code, a different problem presents itself: scale. This application was found to have hundreds of classes spread across multiple assemblies, a rich dependency injection framework, and a layered architecture that separated the generic engine from the game-specific frontend. Understanding what it does, in the sense of mapping the full capability surface, is not something you accomplish by reading files sequentially. 

This is where the workflow for this project diverges from how I’ve conducted similar exercises in the past.  

I used Cursor, the AI-assisted coding environment, as the primary analysis layer operating over the decompiled output. At this point, I want to be very direct about this: the agents did the bulk of the exploratory work. I set directions, I validated findings, I redirected when something needed closer inspection.

But the heavy lifting like traversing the codebase, synthesizing cross-file relationships and answering questions like “what happens between when the user clicks start and when the first model inferences fires,” was agent driven.

This is a qualitatively different mode of working.  

Traditional reverse engineering on a large codebase involves a lot of context switching. Grepping for strings, following import chains, maintaining a mental model of what depends on what across dozens of files. AI agents operating over a large body of decompiled code can hold that graph in working memory and answer questions across it in a way that would be exceedingly difficult for a traditional analyst. You’re not grepping, you’re having a conversation. 

The pipeline emerged like this: I asked, “where does screen capture happen, and how does it connect to the inference step?” The answer, a dependency injection chain flowing from a configuration service, through a screen recorder abstraction, into an ONNX-backed object detector, and finally through a target selector into an input injection layer, came back as a synthesized narrative with the relevant class names, not a list of files to read.  

That narrative was manually verified to be accurate and gave me a map of what to verify next.  

Ghidra stayed in the workflow for the components that needed it; native DLLs, obfuscated dispatch mechanisms, and low-level input injection paths. The agentic approach and traditional disassembly are complementary, not competing. You use agents where you have clean decompiled output and structure to reason over. You use a disassembler when you need to look at actual instructions.  

Custom Python tooling filled the gaps. We used these to scan memory mapped sections for encrypted blobs, validate AES key material recovered from the decompile, and extract and verify the machine learning model files. That tooling itself was partly agent-assisted, scaffolded by agents and refined iteratively as the investigation developed.  

Dynamic Validation: Confirm, Don’t Discover 

Static analysis like that tells you what the code can do. Dynamic analysis tells you what it actually does in a given context. The two aren’t interchangeable.  

The validation environment was an isolated Windows VM on a cloud instance, air-gapped from the public internet by default. When the cheat needed to reach its licensing infrastructure, outbound traffic was routed through mitmdump with a trusted CA imported into the Windows certificate store. This gave us decrypted TLS flows, like hostnames, request paths, and payloads, without relying on DNS or SNI alone.  

Process and filesystem telemetry came from Procmon, watching what the application created, opened, and modified. A few things confirmed by the dynamic session that were harder to assert from the static analysis alone: the heartbeat cadence of the license validation (roughly every 60 seconds), the process footprint at startup, and the logging behavior.  

A few things we explicitly did not try to exercise dynamically: the dual-PC capture card mode, the kernel-mode input injection paths, and obviously live Destiny 2 gameplay. Dynamic validation was about confirming the static map in key areas, not running the full capability surface. The environment also needed to be repeatable. If our findings are going to stand up to scrutiny, the methodology needs to support a second analyst arriving at the same conclusions from the same artifacts.  

One operational note worth passing along. Raw packet captures are insufficient for modern commercial software. Almost everything of interest is TLS-encrypted. If you’re not running a MITM proxy or capturing SNI/DNS in your egress path, you’re only seeing handshakes, not the conversation.  

Workspace Architecture at a Glance 

At a high level, the research environment broke down into three layers that didn’t share network access with each other, or with analyst workstations:  

• A static analysis host with the decompiled output, Cursor, Ghidra, Python tooling, and the recovered artifacts. This host ran distinctly from other pieces of architecture and never attempted execution of the cheat.  

• An isolated execution sandbox (the cloud VM) for controlled dynamic runs.  

• A proxy/capture host that sat between the sandbox and permitted egress, running mitmdump with the CA installed.  

Everything that came out of the installer was hashed at intake. The artifact stayed versioned and documented. Not because we believed we would be litigated, but because the findings need to be traceable to something real. “I believe the code does X” is a much weaker statement than “class Y has a method that explicitly does X, here is the decompile.”

Scope discipline also matters. The investigation explicitly excluded live gameplay, production Destiny 2 accounts, or any attempt to defeat or circumvent the vendor’s license checks. The goal was to understand the software, not operate it.

What This Means for How We Do This Work 

While my findings on the cheat are obviously an important part of this engagement, this methodology turned out to be just as interesting. Agentic AI tooling applied to reverse engineering is not a marginal improvement. The economies of large-codebase analysis have shifted. A piece of commercial software that might have required weeks of manual static analysis to map structurally can be characterized in days when you’re asking questions rather than reading files.

The bottleneck moves from “how fast can I read code” to “how well do I know what to ask for,” and that shift favors experienced analysts who understand what they’re looking for.  

It also changes what’s tractable. Investigations that would have been resource prohibitive as manual exercises are now feasible. This has implications for the kind of proactive research we can do, and for the economics of adversarial software analysis more broadly. The same techniques can be readily applied to malware analysis.  

This isn’t to say that agents replace human judgment. They don’t. They misread structure sometimes, they conflate related but distinct code paths, and they need direction. The value lies in the collaboration; an experienced analyst asking good questions of a system that can traverse a large codebase with patience and breadth contributes significantly to what we can get done in the time we have.

The second post in this series gets into what we actually found in our analysis, and in our humble opinion the findings are worth the read. The “AI aimbot” framing has been accurate in ways that have significant implications for detection and enforcement strategies, particularly around a design choice that pushes the entire detection problem in an uncomfortable direction. 

If the issue of commercialized adversarial software, game security, or agentic reverse engineering methodology is something you’re working on, the Armada team wants to talk to you. The full technical report from this investigation is available on request to qualified parties, be they game publishers, platform security teams, or legal counsel. But read on to Part 2 for the juicy technical bits.  

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.