Sleepy Anti-cheat (BO3)

Note: The objective of this article is to document research performed on the Black Ops 3 anti-cheat and explain some critical mistakes in the design which can lead to total failure of the security systems. I do not condone cheating or attacking anti-piracy measures.

Introduction

While working on BO3Enhanced, there were a few cases where a debugger became almost a necessesity. Unfortunately, Black Ops 3 ships with anti-debugging techniques built into the anti-cheat. The proccess will usually silently exit upon detecting a debugger – if the debugger is even just running in the background, the game will close!

Up to this point, we had believed the anti-debug to be primarily built into Arxan (now digital.ai) which is the DRM solution used to protect Call of Duty games on PC. This is a bit more challenging to attack, and thanks to research was done by momo5502, we have the ability to disable the process integrity checks and disable a few anti-debugging techniques (primarily process module name detections). Sadly the game still would not be debuggable using regular methods (although lower level hypervisor debugging would work just fine).

This is still the case (currently) for the Steam version of Black Ops 3, but recently a Windows Store version of the game was released that shipped without any DRM. This is a bit mind boggling – the Windows Store exe is built from the same source as the Steam version, and besides some slightly better optimizations, is nearly identical! This is a huge blunder because we can easily restore Steam specific functionality to the game with patching, resulting in a DRM-free build to tamper with to our heart’s content.

The interesting part is that upon trying to attach a debugger to the Windows Store version, the game still closes! This of course means that Treyarch implemented in-house anti-debugging, and that we would need to analyze the executable further to achieve our desired result. I decided that while we were attacking this part of the anti-cheat, we may as well just gut the entire thing – given there is no (commercial) obfuscation, it could be manageable to completely disable the anti-cheat.

Treyarch Anti-Cheat: An Overview

Treyarch Anti-cheat (TAC) is a completely usermode, in house solution to detecting common cheats and cheating methods. This post primarily aims to explore attacking the anti-cheat, so many components of the internals will be greatly simplified or skipped altogether in favor of highlighting what it takes to disable the mechanisms. If you are interested in learning more about the behavior of the anti-cheat (and on a newer game), check out this excellent writeup by my friend ssno that dives into the Black Ops Cold War version of TAC.

I will at least provide a high level overview of TAC, because it is important to understand the general design so that we can highlight its flaws.

Initialization

TAC initializes in the TLS (Thread Local Storage) callbacks for the process, which are executed before the main entrypoint and at the initialization of every thread created in the process. It is quite easy to identify TAC functions because every call to the Windows API is obscured with an inlined runtime lookup for the function in its respective DLL.

TLS Callback Code

The general methodology is the following:

  1. Check a global which will contain a pointer to the desired function if already located. If the global is set, check the current time using the __rdtsc() mnemonic, and occasionally restore the global’s value.
  2. If unset or cached for too long, walk the process in load order module list by accessing the Process Environment Block and find the desired module and function name by comparing against an FNV1a constant generated for the enclosing function (more info in ssno’s blog post).
  3. Store the pointer in the global allocated for this particular function. NOTE: this is a huge blunder!! The function pointer is not encrypted so we can easily figure out which functions are attributed to which global, greatly reducing analysis efforts.

Fortunately, all uses of the same function (eg. VirtualAlloc, NtQuerySystemInformation, etc.) will utilize the same global, so we can easily xref the global in IDA and resolve all the locations in the executable where the function is used. This was, by far, the easiest way to navigate the anti-cheat while analyzing – the code generation for accessing these functions is quite large, and most functions in the anti-cheat cannot be decompiled.

The TLS callback is responsible for:

  1. Initializing pointers to ntdll and kernelbase – more on the ntdll pointer later!
  2. Setting ThreadHideFromDebugger and doing some checks to make sure NtSetInformationThread and NtQueryInformationThread are not hooked – when a debug breakpoint is hit, a thread with ThreadHideFromDebugger applied will completely bypass a debugger and the exception generated will usually be fatal or caught by an anti-cheat exception handler for reporting.
  3. Check that the thread entrypoint was in a valid module.

After the TLS callback has completed, the application entrypoint is invoked, where quite early in Main, a call to more anti-cheat code is performed. The developers at Treyarch anticipated some novel attacks (such as simply patching the anticheat init to return instantly), and the initializer is interlaced with standard memory initialization for other critical components for the game.

Similarly, the main anti-cheat thread also is interlaced with the game’s thread manager, so it’s not as easy as just patching out the main anti-cheat thread (well… more on this later :D). Upon attempting to patch out either of these functions, the game will exit with a fatal error about memory stacks being uninitialized.

Some of the essential tasks performed by the other initializers:

  1. Verify that ThreadHideFromDebugger is set correctly.
  2. Create a mutex for Black Ops 3 and make sure that there are not duplicate instances running,
  3. Setup the main anti-cheat thread and initialize other critical game components mixed within the code.

Runtime Behavior

While the game is running, the anti-cheat thread will periodically check for various cheating behaviors. Some (but not all) of the things checked:

  • Iterates the running processes and window titles for known bad applications (eg. Cheat Engine, Wireshark, windbg, etc.)
    • Note: These are hashed but the hashes are stored in the read-only section of the executable and can be patched out, although it is much easier to hook the respective user32 functions and mask processes.
  • IsRemoteDebuggerPresent
    • Quite funny because debugging any 64-bit executable while BO3 is running can cause this to trip. It is also only checked in one place and is easily removed.
  • Check if a console is allocated to the current process.
    • Note that they actually check the console window class.

Additionally, various functions will invoke anti-cheat callbacks at random times and places within the regular game logic. The main thread of the game keeps track of a global variable with the last time the anti-cheat reported a successful status, and if this variable ends up being stale or bad, the thread exits with no error status (killing the game).

Attacking the Anti-cheat

By this point it is more apparent what must be done to disable the anti-cheat.

  1. The one-off Initializer measures must be patched.
  2. The anti-cheat thread should be killed or halted. The main thread needs to be patched to ignore a failed status update.
  3. All the callback functions must be forced to instantly return.

The approach I took to completing these tasks is a bit funny…

One-off Initializers

Remember how I said I would talk a bit more about the ntdll pointer later?

When the TLS callback initializes a pointer to ntdll, it isn’t just finding ntdll in the loaded modules. Treyarch anticipated possible hooks to ntdll, so they allocate a copy of ntdll for use with the anticheat. They also anticipated sideloading attacks, so they specifically load the ntdll found in the system directory. Unfortunately, they made a critical mistake in how they allocate memory for this copy of ntdll.

VirtualAlloc for ntdll

By using VirtualAlloc imported from the regularly loaded kernelbase, they expose a trivial way to allow for regular hooking of ntdll functions. All we have to do is hook VirtualAlloc and return a pointer to the original ntdll, making sure to patch out the code shortly after the allocation which copies the ntdll bytes from disk into the allocated space.

VirtualAlloc(...)
{
    if ((int64_t)_ReturnAddress() == expected_address) 
    {
        // they do not map in the PE header on their copy
        return (uint64_t)GetModuleHandleA("ntdll.dll") + 0x1000;
    }

    return VirtualAlloc_Original(...);
}

We have trivially enabled hooking of ntdll functions :)

We can now bypass the ThreadHideFromDebugger checks with hooks to NtSetInformationThread and NtQueryInformationThread, although it is a bit tricky because Treyarch intentionally provides invalid parameters to check for low effort hooks – I opted to simply log the return address of calls to these functions with the correct parameters and replace the calls with zero-rax instructions.

Most of the other initialization procedures can be replaced with extremely basic nops and zero-returns so I won’t bother listing them all.

Runtime Callbacks

Most of the anti-cheat callbacks can be located by xrefing the ntdll, user32, and kernel32 base addresses cached in an anti-cheat global. Additionally, the threads created by the anti-cheat for running async callbacks can be found by xrefing the CreateThread global.

Luckily, Treyarch did not interlace critical game logic with any of these callbacks. This means each of these callbacks can be patched with a nullsub! This is the reason it is important to make anti-cheat code hard to separate from the regular behavior of the game when possible :)

Main Anti-cheat Thread

The main anti-cheat thread has some initialization code which is heavily interlacted with game logic at the start of the function, which means patching out the thread completely isn’t really possible. There are multiple ways to deal with this, but I chose an extremely simple method that required very little work (and is quite funny). I present: The Sleepy Anti-cheat

NtQuerySystemInformation(...)
{
    uint64_t faultingModule;
    RtlPcToFileHeader((PVOID)_ReturnAddress(), (PVOID*)&faultingModule);

    if (faultingModule && faultingModule == gameBase)
    {
        // sleepy anti-cheat activated :)
        while (1)
        {
            Sleep(100000);
        }
    }

    auto result = NtQuerySystemInformation_Original(...);
    return result;
}

Because the anti-cheat thread transitions from interlaced game logic to becoming a dedicated anti-cheat thread, we can simply hook the first Windows api call used by the anti-cheat and put the thread to sleep.

Note: We can obviously just terminate the thread, but at the time of writing this patch I assumed there would be checks to make sure the anti-cheat thread did not exit (in the TLS callbacks)

The only issue is that now the main thread will trigger a timeout for the anti-cheat reporting success, so we have to either report success manually or patch out the exits.

That’s It?!

Surprisingly with these few techniques, the Black Ops 3 version of TAC is completely defeated. Although in the game’s prime years there would also be Demonware challenges to spoof, as of the time of this article being written there is no TAC related ban risk while playing BO3 on PC. With the local challenges being disabled, we can simply debug the game.

Of course, modern TAC is much more advanced – including some pretty detailed reporting procedures (albeit with similarly trivial bypasses :P). This methodology is also not as easily performed on the Arxan protected version of the game because most of the initialization code is completely shredded by Arxan’s jmpfuscation, however because we have a 1:1 unprotected build, we can easily modify some of the code patches to instead be api hooks for a similar effect on the Steam build of the game.

Overall, given this was one of the first genuine attemps at an anti-cheat in COD, I am pretty impressed with the thought that went into the overall system design, and especially impressed with how Treyarch handled their hidden api imports and shadow copy of ntdll. It is a bit unfortunate that they did not anticipate a VirtualAlloc hook, and very unfortunate that the anti-cheat thread transitioned into a dedicated thread during operation, but nonetheless the system was effective at stopping many cheats, even to this day.

I hope this article has been informative! Thanks for the read!

Special Thanks

  • ssno for his TAC research and assistance in analysis of the BO3 anti-cheat.
  • Emma / IPG for her work on BO3Enhanced and assistance in the analysis of the BO3 anti-cheat.
  • momo5502 for his work on Arxan and the xlabs projects.