UltimateAntiCheat shows what usermode integrity checking can and cannot do

The stated goal is a reference point, not a product

UltimateAntiCheat is an open source, educational usermode anti-cheat system made to detect and prevent common attack vectors of game hacking, and the README is unusually clear about what that means in practice.

The main goal is to provide a generic reference point for educational purposes, rather than to be commercial software. It serves as an approximate example of what a typical defensive usermode software might look like. The project implements several fundamental and standard detection and integrity techniques, along with a few the author says he found on his own, and aims to cover as many attack surfaces as possible while being limited by a usermode process environment.

That last clause is the important framing. Usermode means the anti-cheat runs as an ordinary Windows process with ordinary Windows privileges, and there is a ceiling on what that can achieve. The stated goal is that an attacker is not able to gain a foothold from usermode into the process without being detected, which is a real but bounded claim.

The detection model is explained through two worked examples rather than a list. If someone tries to debug the code from usermode, they will likely re-map image sections and change the page protections of `.text` or `.rdata`, or some other section, in order to perform memory edits to patch over debugger detections, and those memory edits and re-mapping are then caught by the program's integrity checker.

The second example is about external interference. If an attacker opens a process handle to ours and allocates heap memory and writes a PE image or executable shellcode into it, the detection class will report manual mapping and report that an external process opened a process handle to us.

That pair of examples is a good summary of the whole approach. The defence is noticing that the process's own memory has been altered, and noticing that somebody else is interfering with it.

The repository layout is the architecture

The top-level entries map out the modules, and the names are the clearest description of what the anti-cheat does.

There is an AntiDebug/ directory and an AntiTamper/ directory, which are the two halves of the idea above. There is a Common/ directory for shared code, which includes the Settings.hpp file where the kernel mode toggle lives. Core/ holds the detection and prevention logic, and the README refers to a Detections class inside it, which is the piece the author later says is messy. There is a Process/ directory for process-related work and an Environment/ directory, which is where the machine's Windows version is fetched at startup.

Then the supporting directories. GameEvents/ is presumably where game-side hooks live, DLLs/ and Libs/ for the library dependencies, LibTest/ for testing the libraries, Network/ for the optional client and server communication, Obscure/ for the obfuscation-related code, MiscFiles/ for resources, and Server/ which contains the server as its own project solution with its own README.

At the root there is main.cpp, which is where the settings and the startup sequence live, along with SplashScreen.cpp and SplashScreen.hpp for the startup window, a Doxyfile for generating documentation, the Visual Studio project files with filters, and the .aps and .rc resource files for the icon and version information.

So this is a proper Visual Studio solution rather than a script or a header-only library, which is consistent with the stated recommendation that Visual Studio 2022 was the primary IDE and is recommended for project viewing and compilation.

Usermode, kernel mode and the limit of the design

The optional networking and optional kernel mode features are the two extensions to the core, and each has an honest caveat attached.

The project features an optional basic client-server mechanism, with a simple heartbeat being sent every minute to clients. The server lives in the Server folder as its own project solution, and networking is optional and can be turned on or off through the variable `bool bNetworkingAvailable` in main.cpp, as part of the Settings class. If you choose to use networking, the instructions say to follow the README in the server folder.

The privacy position is stated directly. No privacy-invasive techniques are used, and the heartbeat is the only traffic described.

The kernel mode path is the more significant caveat. A hybrid kernelmode plus usermode approach can be used through the settings in main.cpp and Common/Settings.hpp, and the note in parentheses is the important part: you will need to make or provide your own driver for this.

So the kernel half is not shipped. The architecture supports it, the settings expose it, and the driver is yours to write. That is a deliberate choice for an educational project, since a kernel driver is the part with the highest barrier to entry and the largest blast radius, and it also makes the usermode half something you can study on its own.

The compiler story has the same honesty about it. The project supports CMake and the LLVM/clang-cl compiler, which can be found in the llvm-clang branch, with a caveat that the branch may be lagging behind the main branch or may not be error-free.

The author also mentions that in the future, time permitting, they may attempt to add code obfuscation via LLVM transformative passes. So the obfuscation work is planned rather than present, and the recommendation in the meantime is to run an obfuscator on the compiled binary, or on the IR if compiled with LLVM/clang-cl, for added security through obscurity.

How to integrate it, and why a static library beats a DLL

The integration advice is specific and it is the part that matters if you are considering using this in a real game.

The project should be integrated into your game or software directly as source code or static library instead of a standalone DLL, in order to avoid DLL proxying and spoofing attacks, and a .lib build configuration is now supported. The reasoning is straightforward once stated: a standalone DLL sitting on disk is something an attacker can replace with their own, and a DLL proxying attack works by inserting a malicious DLL earlier in the search order.

That is a meaningful change in how much work integration is. The alternative of shipping a DLL is much simpler, and it is exactly the configuration that the project asks you not to use.

The second recommendation is that you run an obfuscator on the compiled binary, or on the intermediate representation if you are using the LLVM path, for added security through obscurity. The phrase is deliberately modest. Obfuscation is a layer, not a defence, and the author says so.

The contribution guidance is worth reading because it describes the standards you would have to meet. Anyone is welcome to contribute a code push as long as the contribution uses the same C++ standards, which are C++14, and formatting as the existing codebase, and you have successfully regression-tested your code additions with the project, with all protective features required to work the same or better.

And there is an offer of help with adding or maintaining anti-cheat in a studio's game, by email. That is unusual to see in a project README and suggests the author is open to real engagements rather than only to pull requests.

Windows version targeting and the AGPL terms

Two practical details are set out that would otherwise be discovered at compile time.

The preprocessor definition `_WIN32_WINNT=0x...` can be used to target different versions of Windows at compile time. Using 0x0A00 targets Windows 10 and above, and 0x0601 targets Windows 7 and above. Certain features may only work on newer Windows versions, and are excluded from compilation based on that definition. The client also fetches the machine's Windows version at program startup in main.cpp.

So there are two version gates rather than one. The compile-time macro removes code that cannot work on the target, and the runtime check lets the program know what it is actually running on. That is a sensible pairing, because a feature that only works on Windows 11 can still be compiled for a Windows 7 target and then simply be skipped.

The licensing section is unusually explicit about what the AGPL means in practice for a game project. The GNU Affero general public license is used, and you do not have permission to rip or copy this project's code into your own commercial project, or use the project in your own code base, without your project also being open source. You do have permission to use it if your project is fully open source.

The specific prohibition is on private game servers and any other stolen code or leaked binaries, which automatically violates the licence. And the author takes no responsibility for any possible legal actions taken by game publishers against private servers which unlawfully use the project.

That is a fair and unusually clear statement for an AGPL project in the games space, where the private server question comes up constantly.

The sibling projects and the honest quality note

The README contains two paragraphs that a reader should not skip, because they are the author telling you what is wrong with the project.

The first is about code quality. Certain sections of the code such as the Detections class may be considered messy, lacking C++ design concepts and modularity, as the project was originally written in a plain old C style and later moved into using C++14 concepts. That is an accurate description of what happens when a project grows from a different language's habits, and it is unusual to see it stated plainly in the project description rather than in an issue.

The second points you somewhere better. If you are looking for a modular, light-weight code integrity library with far cleaner code, check out UltimateDRM, and a much improved detection library can be found at DetectionEngine. Both are by the same author. And the note is that these two projects will be implemented or used by UltimateAnticheat if there is time in the future to merge them and add auto-compilation scripts for each library.

So the ecosystem is a set of related projects with a stated direction of travel, and the current one is the older and messier of the set. A reader who wants to study the detection techniques will find them cleaner in DetectionEngine, and a reader who wants to integrate a code integrity library will find UltimateDRM the cleaner choice.

That is a pattern worth naming. UltimateAntiCheat is the integration shell with the most moving parts, and its siblings are the focused libraries. Understanding which is which tells you where to look for a technique and where to look for something to drop into a game.

The class flow diagram is the other artefact to look at, and the README explains its convention: each bold line indicates the above class holds an object or pointer of the bottom class, with only classes relevant to core program features shown. So the diagram documents the ownership relationships, which is exactly what you want when reading a codebase where the author has just told you the design is not clean.

Editorial conclusion

Adopt UltimateAntiCheat as a reference if you are learning how usermode integrity checking works, since the build is a Visual Studio solution and the trade-offs are documented rather than hidden. Skip it if you need production protection, because the project is explicitly educational, the Detections class is described as messy, and it has no kernel component of its own. Verify first that you can build with Visual Studio 2022, that you understand the AGPL terms, since using it inside a closed-source game is not permitted, and which Windows versions you need to support, because the target version macro excludes some features from compilation.

Frequently asked questions

Official sources

1. AlSch092/UltimateAntiCheat on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases