Introduction

In this post, I introduce my first blog series, in which I'll walk through the development of my own Usermode Anti-Cheat, built from scratch and guided by my own experience as an offensive researcher and adversary. Each post will cover an individual detection or measure, my reasoning, and how it fits into the overall system.

Motivation

The motivation driving this series and project is the desire to push myself. I want to test myself, see how effective of a solution I can build, find unique detection techniques, and prove I can write something better or on par with existing solutions in industry.

Inspiration

To be better than or on par with other solutions, I must be familiar with them. Some detections and measures covered in this series are inspired by weaknesses and techniques I've observed while reverse engineering various anti-cheats, including BattlEye and Hyperion among others.

Architecture

The anti-cheat is usermode, no kernel driver, no hypervisor. It runs as a DLL loaded before the game itself actually begins execution. A dedicated launcher creates a suspended instance of the game process, injects the anti-cheat module, fully initialises it, and then allows the game to continue execution.

Once initialised the anti-cheat doesn't have a dedicated thread, it's based on a threadless philosophy, running out of hooks and other dispatches, only executing when triggered. Detections are scattered across these dispatches rather than running on a polling loop.

What's Next

In the next post, I'll cover the first layer of this solution: how I protect the anti-cheat before it can protect the game.