Introduction
Many people seem to believe that the rumoured $8.5 billion game cheating industry, a figure recently published by Intorqa's threat intelligence research, is extremely easy to get into. This is far from the truth largely because it is not actually just one scene. The underground cheat market is heavily segmented into a strict hierarchy of low-tier, mid-tier, and high-tier operators. It is a hard divide between copy-paste providers, stressed-out mid-level developers, and professional elite businesses. I should say beforehand, this will only cover proper external or internal cheats. It will not cover spoofers, macros, things similar to that. Unfortunately, it will also not cover DMA as I do not have experience in selling that. Luckily, DMA is not that prominent in the high-tier monopoly, and where it is, the DMA market is mainly dominated by providers like 'Blurred'.
I spent roughly three years inside the cheating community, spending my first two years in the lower-tier scene. I spent time in community servers, places like Enigma and Exploiters Heaven. I have also tried to package providers into 3 sets, where it obviously is not this neat in actual communities.
In this article, I will cover how modern cheats are structured and created, while breaking down the technical and business realities of each tier. But more importantly, I want to cover the human element. We are talking about the fragile egos, the immense pressure, and what is actually going through the minds of the people building and selling these tools. After all, these developers are just human, and under enough pressure, they panic and crumble.
The Low-Tier (~$1k a month)
I started roughly in 2023 by pasting GitHub drivers after getting banned from Fortnite. I was heavily into competitive play, but I got banned using a public cheat from a random YouTube video. I wanted to stay undetected, but because AIs like ChatGPT lacked the necessary depth regarding Windows Internals, I had to research it manually.. One thing average cheaters don't realize is that UnknownCheats is a treasure trove of information. When I looked at the driver I was pasting, I would look at a specific API it called and wonder how anti-cheats could detect it, where I would move over to UC to see if others had the same question.
The low-tier is where almost everyone starts. They usually make anywhere from $100 to $1,000 before burning out. While they might make up 90% of the providers you see advertised on YouTube or TikTok, they capture a tiny fraction of the actual industry revenue.
Since low-tier devs don't have much experience with internals whatsoever, they stick almost entirely to externals. They load their driver with KDMapper. For those who don't know, it is a manual memory mapper which allocates and then overwrites memory into a, usually, RWX (read-write-executable) region, with their own driver memory and it then hooks a rarely called function to execute the entry point, where KDMapper hooks NtAddAtom. Lo and behold, their memory is now in the kernel!
However, this comes with significant drawbacks. Due to the ease of this method, alongside it being public for so long, any interrupt fired will catch their unbacked code. Furthermore, these providers do not dynamically import, and if they do, they cache their imports, making it completely useless. You can just scan for imports in unbacked memory to detect these, hence why their detection is already automated. For their communication method, it is generally just IOCTL with IoCreateDriver as KDMapper does not create a DriverObject, with some people thinking manually creating the object creates a difference when the IRP will point to your memory anyway. I'm not exactly sure what goes through their minds there, I guess they assume IoCreateDriver is hooked or something?
This public mapper meta was the case before a project by a fellow researcher, noahware. He released a Hyper-V hijacker called hyper-rev, which uses Hyper-V to disguise itself. Once this project was released, oh boy, there were maybe 100 new providers suddenly claiming they had hypervisors. Obviously, this then led to every anti-cheat team enforcing TPM as they could check the boot-chain. To clarify, anti-cheats were already enforcing it and planning it, but this just sped that process up, notably EAC.
Low-tier user experience is awful. Their cheats generally only work for a specific Windows version because they don't use offsets from Microsoft's public symbols, but rather hardcoded signatures. They all use KDMapper anyway, so they don't support anything past Windows 10 on most anti-cheats, and bans occur within a few hours.
Their authentication is almost universally KeyAuth. To be fair, the infrastructure itself isn't inherently terrible, but low-tier developers implement it so poorly. They don't do any work to hide the keys or encrypt the packets by modifying the library, meaning a cracker can just intercept the traffic and return whatever response they want. They usually wrap their entire cheat into one singular application. On startup, they do a few basic checks, usually just scanning for debugger window names, and then run the KeyAuth license check. In assembly, this is typically a simple je instruction. If the license is invalid, it jumps to a routine that closes the application. A cracker can literally just patch that instruction to an unconditional jmp and bypass the entire paid system. Even when using advanced protectors like VMProtect, these developers don't bother to encrypt their strings. You can just dump the program strings and find the raw catbox.moe link where they are secretly downloading their driver payload.
Because they rely entirely on pasting public code, their products are incredibly fragile, which is funny because the defining trait of a low-tier developer is an insanely massive ego paired with a loud mouth. For whatever reason, these guys love to flash fake crypto balances in Discord and pretend they are rich. Personally, I do not see the appeal since my wealth shouldn't matter to others, but it is a rampant culture here. When a ban wave eventually hits, the cheat shatters. They obviously cannot fix the detections, so they have a complete mental breakdown in their Discord servers. They panic, they blame the users, they blame Windows updates, or they blame the anti-cheat for doing something "illegal".
Then comes the inevitable exit scam. These providers use bots like RestoreCord to farm Discord members via OAuth. When their cheat gets detected, they claim these OAuth bots are used to pull back members if the server gets terminated, but in reality, 90% of them just use it to hand over and sell that entire user list to other cheat providers before disappearing and rebranding the next month. Financially, they don't have enough money to buy ID-verified accounts. They use SellAuth and PayPal as their main method behind crypto, instantly cashing out to different PayPal accounts since PayPal locks your account if you receive too much funding via Friends & Family (F&F). Of course, this also means the buyers never get refunds!
The Mid-Tier (~$10k a month)
The mid-tier is where actual money starts flowing, and it is where I spent a significant portion of my time working alongside other developers on white-labeled builds. These were resold to huge battle royale providers that I cannot name, but who ruled the scene during the time I was working. Working directly with developers at that scale gives you a real look at how the mid-tier operates. At this level, you are actively fighting the anti-cheat, writing custom code, and handling complex infrastructure.
During my development, we made a slotted and public cheat, where the public version was focused entirely on randomization. To do this, we created a small mutation engine for the driver using tools like Zydis and a server-sided loader where it dynamically re-compiled the executable on the server with VMProtect. For the driver alongside the engine, the focus was making sure everything static was randomized per user. Whereas on the slotted cheat, the focus was solely on hiding the fact the executable was ever run, erasing traces in places such as Windows Prefetch. For the driver, I simply disabled interrupts during pretty much any operation and used an NMI (Non-Maskable Interrupt) function pointer hook that evaded leading anti-cheats integrity checks.
This is also where real obfuscation and anti-dumping techniques come into play. First, we have LLVM passes. This is something I personally used, though it is getting slightly weaker as LLMs are getting advanced enough to simplify them. LLVM is basically a framework between the compiler converting your source code into an actual program, meaning we can rewrite simple operations into much more complex ones. Then we used VMProtect or Themida on top. Ideally, you use VMProtect as the virtual machines seem to be more complex than Themida, but this just adds more layers on top of your LLVM passes. You may have seen header files released by some protection frameworks on GitHub or UnknownCheats, but you cannot do true control flow flattening through a header file.
For string encryption, low-tier providers use something like skCrypt, which is easily reversed because the decryption routine is a straightforward loop. In the mid-tier, we either introduced our own routines or used oxorany. Oxorany is a popular choice because the decrypt function is heavily unreadable. It jumbles the control-flow heavily and attempts to cause stack frame analysis failures when compiled with obfuscation enabled. There are also a lot of fake decrypt paths to confuse the reverser, alongside macros forcing the compiler to generate mathematically different encryption routines per instance.
To protect authentication, I personally used KeyAuth as a backend base whilst routing it through my own encryption and checks. Rather than a simple license check, we streamed important variables from our server. If the client needs offsets for a game, it sends a request to the server, the server validates the session key, and returns the value. The same is done for files: the driver itself is encrypted before transit, during transit, and only decrypted right before manually mapping.
To counter tools like KDStinker that extract payloads during mapping, we decrypted parts of the memory region in chunks so the entire PE header was never exposed at once. During the actual mapping, one thing that I did was check the IRP pointer to my vulnerable driver. Of course, this is always a cat-and-mouse game, because running unencrypted code in memory means security researchers can hook execution on unbacked regions eventually.
Behind the scenes, this tier is a grueling factory. The egos here shift from flashing fake crypto to ruthless business arrogance, as the business owners selling the cheats treat the actual developers like highly replaceable code monkeys. When you get hired, you are suddenly hit with extremely strict deadlines. I was frequently forced to push unfinished, unpolished products just to meet a launch date. I should also mention that this is not solely from my experience, I was obviously friends with alot of other developers in the scene working for mid-tier providers at the time, and they shared similar if not the exact same experiences as me. I won't lie, people still have an ego here, you're just essentially trained not to show it. Without it, you have no confidence. You need to believe that you can bypass the anti-cheat, even if it isn't true.
The pressure is suffocating. You push a build, and suddenly the target game decides it is a great idea to update twice a day. The providers I worked for demanded a maximum of 10 support tickets daily, which is an impossible metric when dealing with cheats on thousands of different Windows configurations. You must remember, this is now getting similar to writing production-level software. Like an anti-cheat, you need to support configurations on global machines. I used to get yelled at for hours on end when usability was not perfect. Surviving the mid-tier requires killing your own ego. The mid-tier crushed whatever ego I had left, as I quickly realized that in that environment, nobody cared how clever my code was or how proud I was of it; they just needed it to work. You simply had to learn to shut up, de-escalate, detach and deliver.
The High-Tier (~$50k+ a month)
My direct employment information here will not be as solid as the mid-tier, because I did not work as a primary developer at this tier. However, while working in the mid-tier, I managed to get an inside look at how high-tier providers operate through social engineering. I did not need a fake persona or a burner identity to do this, since they trusted me as a peer, allowing me to pick their brains on their infrastructure, bypasses, and operations.
The high-tier providers generally exist solely as slotted (invite-only, requiring ID verification), occasionally running a private public cheat for extra revenue. Slotted cheats strictly limit user slots and cost anywhere from $300 to $1,000 just for a single month. From just 50 users, you are pulling $15,000 to $50,000 a month with minimal exposure.
Unlike the loudmouths in the low-tier, high-tier developers suffer from a massive god complex. They view themselves as untouchable, elite researchers. They do not constantly hold execution in the kernel because they know that is a losing game. Instead, they use a vulnerable driver solely to set up an exploit and then immediately clean their traces. With some of the developers, they have the technical ability to back-up this god complex.
Historically, people don't realize how much anti-cheats have tunnel-visioned on the kernel, thinking user-mode is a solved space. Top-tier providers take advantage of this by finding user-mode exploits, like Samuel Tulach's PreviousMode exploit, or manipulating the supervisor bit to work around SMEP/SMAP. Not to say that they completely ignore it, but it is much harder against advanced exploits that function in user-mode to implement heuristics. You can do simple things in Ring-0, like flag if unbacked memory is executing, but most user-mode exploits now setup with a vulnerable driver and are novel. Basically; you cannot hunt it like you can DMA or KM.
Some higher low-tier and mid-tier providers try using .data pointer hijacks, pointing shellcode into a discardable section which jumps into their driver relying on a key decoded in that shellcode sequence. Sorry to break it to you guys, but EAC has their own in-house x64 emulator to counter these tricks, and if they catch execution in a discardable section, you are guaranteed a ban. Of course, they will not emulate every single pointer. However, pointing to a discardable section is more than enough reason to attempt to do so. I cannot comment on that in full detail as I reported something similar to Epic Games through HackerOne, but it shows how advanced the defensive side really is.
Financially, at $50k+ a month, the high-tier operates like a full-blown financial laundering business. They accept crypto, split and launder it across multiple wallets and privacy assets, and off-ramp using ID-verified accounts to pay out directly to bank accounts like Revolut. They also run custom-built e-commerce platforms, hiring dedicated web developers to secure payment portals rather than using public platforms that could be shut down. There are a rare few who even set up registered corporate entities, pay taxes, and pass KYC checks to keep legitimate payment processors running.
The Shift to Driverless Exploits
Over the past couple of years, the kernel space has become increasingly hostile. Anti-cheats are aggressively enforcing TPM 2.0, Secure Boot, and HVCI (Hypervisor-Enforced Code Integrity). In the past, some high-tier cheats used hypervisors to hide their internal execution or hooked the system call handler to mask their DLL calls.
Because of this, the meta is heavily shifting toward driverless exploits. To clarify, inside cheating communities, "driverless" means that you do not maintain constant kernel execution; you usually still require a vulnerable driver to set up the environment, but you clean up and get out. High-tier developers realize that user-mode is mostly treated by anti-cheats as a space for telemetry and ban-waves, opening up opportunities.
One popular driverless method involves manipulating page tables, mapping the target process memory into the cheat's own CR3 so it can access game memory externally. During my own testing with similar methods, I found that even if you write code that flawlessly evades static detection, there is always a point of failure. You still need a hook to initialize the environment, and that hook will always be detectable. No matter how clever the exploit, it inevitably leads right back to the cat-and-mouse game.
Another massive 'true' driverless vector is exploiting legitimate signed software, such as the Discord overlay. Discord's overlay allocates an RWX region directly inside the game’s memory. Cheat developers inject their shellcode straight into this region because the anti-cheat cannot easily run a hardcoded integrity check on it without breaking Discord for millions of legitimate players. Whilst this is nothing new, many people try to embed their entire logic inside of this, whereas using a handler to communicate externally worksaround any stack checks or return address checks. The reason this is 'truly' driverless, is because it usually is not done with a driver, but rather a user-mode exploit to setup which is the main detection point of this.
Inside this region, they overwrite about 50 bytes for a handler and start a small poll inside shared memory to dereference memory. They use shared memory that is practically already set up for them, achieving near internal-level performance without keeping an open driver handle. I have seen this exact method used in quite a few high-tier providers. While it is almost impossible for an anti-cheat to outright detect this via hardcoded signatures, it is highly vulnerable to telemetry-based ban waves. The anti-cheat might not catch the hook immediately, but over time their telemetry will catch the handles and patterns formed between the processes.
The Future of the Arms Race
At the end of the day, the battle between anti-cheat teams and cheat developers is no longer just about who can write the better rootkit. The arms race has completely shifted. It is now just as much about business logistics, infrastructure, mental endurance, and user experience as it is about pure code.
When an anti-cheat enforces a feature like HVCI or TPM, they aren't just patching code, they are actively attacking the cheat provider's customer base. Even if a cheat dev bypasses HVCI queries, if the cheat requires the customer to manually disable HVCI or boot into their BIOS to disable Secure Boot, average users will refuse. They do not trust third-party cheat software tinkering with their low-level BIOS settings, and honestly, they shouldn't.
For me, the transition from offensive development to defensive security was not about some sudden moral awakening. It was just a realization of where the actual engineering challenge lies. Anyone can paste a driver, and even at the mid and high tiers, you are ultimately playing a losing game. Over a long enough timeline, every cheat is eventually detected, disrupted, or rendered commercially unviable. It is just a matter of how much telemetry the anti-cheat wants to collect before they nuke your user base.
Thanks for reading, and I hope this gave you a genuine look into how the cheat industry operates under the hood, from the code to the human egos behind it. I wanted to share this threat intelligence perspective first as a sequel to my original "Understanding Anti-Cheat Architecture" post, looking at the opposite side of the exact same war.