Unity’s splash screen

Mono

Unity uses C# as its primary language, and it has two scripting backends for you to choose from: Mono and IL2CPP.

When Mono is used, the compilation process is exactly as you would expect for any other .NET project: the scripts get compiled into .NET assemblies (IL), and then the Mono runtime is shipped with the game, which does the actual JIT machine code compilation and execution.

The thing about .NET assemblies, though, is that you can just open them in any .NET decompiler tool (like dnSpy), and you will get almost 1:1 code reconstruction from the original. On top of that, you can also very easily patch the code by simply recompiling parts of it.

dnSpy decompiling function from sample FPS microgame

This is not really a problem if you are making a single-player game and you want to allow your players to mod the game to their heart’s desire. There are even projects that streamline this process, and some developers even opt to integrate them into their game builds directly.

When it becomes a problem is when you are working on some sort of competitive multiplayer game. You definitely don’t want players to be modding that, and you want to preferably make it as hard as possible to reverse-engineer it.

So, what are your options? If you are using the Mono backend, then unfortunately not much. Some tricks I will show later will work there too, but realistically, your best bet is some off-the-shelf .NET obfuscator. Also, due to the JIT compilation, there is no way for you to verify the code integrity once the game is running. A malicious actor can simply overwrite the JITed machine code, and you have no reference to compare it to. That’s not the focus of this article, though, so let’s move to IL2CPP.

IL2CPP

The documentation regarding IL2CPP states the following:

The IL2CPP (Intermediate Language To C++) scripting backend is an alternative to the Mono backend. IL2CPP provides better support for applications across a wider range of platforms. The IL2CPP backend converts MSIL (Microsoft Intermediate Language) code (for example, C# code in scripts) into C++ code, then uses the C++ code to create a native binary file (for example, .exe, .apk, or .xap) for your chosen platform.

Well, that sounds like it completely solves the problem, no? Mono assemblies get somehow magically translated to C++ code, which is then compiled into a native binary. No .NET is involved past that point, so unless we ship debug symbols with the game, reverse engineering of the game should be significantly harder, and it should be impossible to recover any class, method, fields, or parameter names, right?

Unfortunately, no. IL2CPP was not designed as a system to better protect the game’s code and not even to improve performance (as some people might think), but rather for Unity to be able to run on platforms where JIT compilation is not allowed or viable.

To make matters worse, Unity uses a component-based architecture. In this system, individual scripts (C# code files) are attached to GameObjects, which are organized into scenes. Due to this, the compiled scenes (and other assets) include information about which scripts are attached to which GameObjects. This is done by referencing classes, methods, and fields by name, which in turn means that this information has to be retained by the scripting backend as well. For example, when the engine asks for PlayerCharacterController to be initialized for a GameObject, it needs to know which class it is.

As you can imagine, there are automated tools that can leverage this information. The most popular one is most likely Il2CppDumper. Let’s check how it works.

I have created a new project using the FPS microgame template in Unity 2022.3.55f1, changed the scripting backend to IL2CPP and made a Windows build.

The structure of the folder is as follows:

• Two folders containing debug symbols and managed assemblies used by IL2CPP. These files are not intended to be published with the game build.
• TestGame_Data: Contains compiled scenes, asset information, and IL2CPP metadata (we will cover this later).
• baselib.dll: An IL2CPP base library providing platform-specific implementations for file I/O, memory allocation, networking, and threading.
• GameAssembly.dll: Includes the actual game code compiled from the C++ generated by IL2CPP.
• TestGame.exe: A loader stub responsible for loading UnityEngine.dll.
• UnityEngine.dll: Contains the game engine code.

Now let’s try running the previously mentioned Il2CppDumper. All we have to do is specify the correct files as command-line parameters and run it.

This will generate several files. The main one is dump.cs, which contains information about all classes, including their fields and methods with their full names reconstructed. It also contains in-memory offsets to these elements, which makes it incredibly easy to modify them if you know where their class instance is in memory.

On top of that, there are also reconstructed .NET assemblies, which also include all the function names, parameters, fields, etc., except for the actual code logic in those functions.

If you wanted to write a cheat that would overwrite the gravity in the game while it’s running, all you would have to do now is find GameObjectManager in UnityEngine.dll (which is quite trivial given that Unity has a public debug symbol server), then use it to loop through the active game objects to find one with the PlayerCharacterController class, and then use the GravityDownForce offset you’ve just got from the dumper to overwrite the value.

Experimenting

Congratulations 🎉, now that the mandatory introduction is out of the way, we can get to the fun stuff. Most of the information that the dumper is reading is not stored in GameAssembly.dll, as you might expect, but in global-metadata.dat located in the TestGame_Data\il2cpp_data\Metadata directory.

Let’s experiment a bit and mess around with a hex editor (HxD in my case). What happens when we replace the previously mentioned GravityDownForce class field name with something else of the same length?

Now let’s try running the game.

Surprise, surprise, it runs perfectly fine. What if we run the dumper now?

So it’s that easy? Just do string replacement in the file and voilà, names obfuscated? Well, I wouldn’t be writing this article if it was that easy, would I? Let’s replace something else, like the PlayerCharacterController class.

The game launches, but it’s broken. If we look into the log (Player.log), we can see many null reference exceptions being thrown on each frame.

This is due to the previously mentioned component-based architecture. The engine wants to associate the script with the name PlayerCharacterController to the player GameObject, but that fails since there is no class with this name anymore. Other scripts fail too, as they expect the class to be present on the GameObject as well.

Now what?

In theory, it should be possible to replace all the names in both the compiled scenes and assets and in global-metadata.dat, which would be optimal since the original names would not be present anywhere in the build. In practice, though, that would mean reverse-engineering and parsing those scenes and asset formats so that you could properly do the replacement. Basic text find and replace would work only if we had super specific names (like OBFUSCATE_THIS_PlayerCharacterController); otherwise, we might end up in a situation where our class is called just Player, and replacing this string would break the entire engine.

Lets try to take a safer, more minimal approach. We will only change type names in global-metadata.dat and keep the original ones in scenes and assets.

But how do we do that without breaking the game? Instead of using completely random names, we will create a hash from them so that if we have the original name, we can easily get the corresponding hash, but not the other way around. We will then use a middleware DLL library that will act as GameAssembly.dll, redirecting most of the calls to the real library without modifying them. However, for calls that take type names as input, we will apply the hashing function to those inputs first before forwarding the call to the real library.

global-metadata.dat

To parse global-metadata.dat, we can either look at the code of the previously mentioned Il2CppDumper, Unity’s debug symbols, or directly at the source code of GameAssembly.dll. To do that, we will build our test project again, but this time, check the option “Create Visual Studio Solution.”

The created solution contains both the code generated by the IL2CPP compiler and all the supporting code of the IL2CPP runtime library.

Hold on

So we can get the whole source code of the GameAssembly.dll file. Why would we then be messing with some additional DLL? Why not edit the source code directly and just compile it? Is there something stopping us from doing so?

Good question. Yes. The Unity licensing team. Unless you have an enterprise license, which can give you access to the engine source code, you are not allowed to modify it.

If your game studio does happen to have permission to modify it, you can implement the middleware library code directly into it. Although, at that point, you could make much more advanced modifications to the engine build process itself.

Back to global-metadata.dat

If you are interested, you can go through the code to see exactly how global-metadata.dat is loaded and used. For our intents and purposes, though, all we need is a way to parse the file to hash selected type names.

The file structure is incredibly simple. It has a header with offsets to individual definitions and their count:

typedef struct _Header
{
    uint32_t Sanity;
    uint32_t Version;
    uint32_t StringLiteralOffset;
    uint32_t StringLiteralSize;
    uint32_t StringLiteralDataOffset;
    uint32_t StringLiteralDataSize;
    uint32_t StringOffset;
    uint32_t StringSize;
    uint32_t EventsOffset;
    uint32_t EventsSize;
    uint32_t PropertiesOffset;
    uint32_t PropertiesSize;
    uint32_t MethodsOffset;
    uint32_t MethodsSize;
    /* ... */
} Header;

typedef struct _FieldDefinition
{
    uint32_t NameIndex;
    uint32_t TypeIndex;
    uint32_t Token;
} FieldDefinition;

typedef struct _PropertyDefinition
{
    uint32_t NameIndex;
    uint32_t Get;
    uint32_t Set;
    uint32_t Attrs;
    uint32_t Token;
} PropertyDefinition;

/* MethodDefinition, TypeDefinition, ... */

Getting the individual definitions and strings by their index can then be done like so:

template<typename T>
inline T Offset(size_t sectionOffset, size_t itemIndex)
{
    return reinterpret_cast<T>(reinterpret_cast<uint8_t*>(header) + sectionOffset) + itemIndex;
}

inline char* GetStringFromIndex(uint32_t index)
{
    return Offset<char*>(header->StringOffset, index);
}

inline TypeDefinition* GetTypeDefinitionFromIndex(uint32_t index)
{
    return Offset<TypeDefinition*>(header->TypeDefinitionsOffset, index);
}

/* GetParameterDefinitionFromIndex, GetMethodDefinitionFromIndex, ... */

Before we go through them and start hashing the names, we need to decide what hashing function we will use. The function should be as fast as possible and preferably able to run without any additional memory allocations.

After searching for roughly 3 seconds, I found xxHash, which appears to be exactly what we need.

For the purposes of this article, I wanted to make it as simple as possible. To avoid moving the entire file around and adjusting all offsets, we are going to replace the names with their hashed counterparts but make the hash the same length.

To do this, we will use this helper function. It uses xxHash to generate a 64-bit number from the buffer, then converts it into a hexadecimal string, which is either cut or repeated depending on the needed length. No standard library functions (such as std::format) are used to maximize performance and limit the aforementioned memory allocations, as we are going to reuse this function in the middleware DLL, so it will be called quite often.

void Hash::Run(char* buffer, const size_t size)
{
    constexpr auto seed = 0x59648347113887;
    const XXH64_hash_t hash = XXH64(buffer, size, seed);

    static const char* hexDigits = "0123456789abcdef";
    char hashString[17];
    for (int i = 0; i < 8; ++i)
    {
        hashString[i * 2] = hexDigits[(hash >> (56 - i * 8)) & 0xF];
        hashString[i * 2 + 1] = hexDigits[(hash >> (52 - i * 8)) & 0xF];
    }
    hashString[16] = '\0';

    for (size_t i = 0; i < size; ++i)
        buffer[i] = hashString[i % 16];

    if (size < 16)
        buffer[size] = '\0';
}

Now let’s get to the hashing. We will first get all the types and then retrieve their fields, methods, and properties. We’ll also perform a sanity check to ensure that the file is indeed a metadata file.

void Metadata::ModifyType(TypeDefinition* type)
{
    char* namePtr = GetStringFromIndex(type->NameIndex);
    std::string name(namePtr);

    if (IsInternalType(name))
        return;

    if (!Config::ShouldProtect(namePtr))
        return;

    Hash::Run(namePtr, strlen(namePtr));
    printf("%s => %s\n", name.c_str(), namePtr);

    for (uint32_t i = 0; i < type->FieldCount; i++)
    {
        FieldDefinition* field = GetFieldDefinitionFromIndex(type->FieldStart + i);
        ModifyField(field);
    }

    for (uint32_t i = 0; i < type->MethodCount; i++)
    {
        MethodDefinition* method = GetMethodDefinitionFromIndex(type->MethodStart + i);
        ModifyMethod(method);
    }

    for (uint32_t i = 0; i < type->PropertyCount; i++)
    {
        PropertyDefinition* property = GetPropertyDefinitionFromIndex(type->PropertyStart + i);
        ModifyProperty(property);
    }
}

bool Metadata::Process(std::vector<uint8_t>& buffer)
{
    header = reinterpret_cast<Header*>(buffer.data());
    if (header->Sanity != 0xFAB11BAF)
        return false;

    printf("Version: %u\n", header->Version);

    typeCount = header->TypeDefinitionsSize / sizeof(TypeDefinition);
    printf("Types: %u\n", typeCount);

    for (uint32_t i = 0; i < typeCount; i++)
    {
        TypeDefinition* type = GetTypeDefinitionFromIndex(i);
        ModifyType(type);
    }

    return true;
}

Notice how there is the IsInternalType() and Config::ShouldProtect() check. IL2CPP has some internal types and methods that it references by name, so we cannot change those. Additionally, a config file containing target class names is used to further make the obfuscation a bit more targeted. In theory, we could switch this around and instead obfuscate everything except the internal types and methods, but this list would be very long (although finite, so it’s possible).

Here is the rest of the code. IsInternalType() also checks for method names used by MonoBehaviour (the GameObject base class), such as Awake(), Start(), and Update().

void Metadata::ModifyField(FieldDefinition* field)
{
    char* namePtr = GetStringFromIndex(field->NameIndex);
    std::string name(namePtr);

    if (IsInternalType(name))
        return;

    Hash::Run(namePtr, strlen(namePtr));

    printf(" - [field] %s => %s\n", name.c_str(), namePtr);
}

void Metadata::ModifyParameter(ParameterDefinition* parameter)
{
    char* namePtr = GetStringFromIndex(parameter->NameIndex);
    std::string name(namePtr);

    if (IsInternalType(name))
        return;

    Hash::Run(namePtr, strlen(namePtr));

    printf(" - [param] %s => %s\n", name.c_str(), namePtr);
}

void Metadata::ModifyProperty(PropertyDefinition* property)
{
    char* namePtr = GetStringFromIndex(property->NameIndex);
    std::string name(namePtr);

    if (IsInternalType(name))
        return;

    Hash::Run(namePtr, strlen(namePtr));

    printf(" - [prop] %s => %s\n", name.c_str(), namePtr);
}

void Metadata::ModifyMethod(MethodDefinition* method)
{
    char* namePtr = GetStringFromIndex(method->NameIndex);
    std::string name(namePtr);

    if (IsInternalType(name))
        return;

    if (name.find('.') != std::string::npos)
        return;

    Hash::Run(namePtr, strlen(namePtr));

    printf(" - [method] %s() => %s()\n", name.c_str(), namePtr);

    for (uint32_t i = 0; i < method->ParameterCount; i++)
    {
        ParameterDefinition* parameter = GetParameterDefinitionFromIndex(method->ParameterStart + i);
        ModifyParameter(parameter);
    }
}

Now let’s run it and save the modified buffer back into the global-metadata.dat file.

If we now run the dumper and check the generated output, we will see something like this:

If we try to run the game at this point, it will either be broken or crash right away.

Middleware

Writing the middleware DLL is pretty straightforward. All we need to do is pass through the vast majority of functions to the original DLL. This can be done through forwarded exports or by manually writing function wrappers that will then call the original.

void OnDllAttach()
{
    Console::Init();
    Console::Print("Loading module...");
    Global::GameAssembly = LoadLibraryA("GameAssembly.Real.dll");
    if (!Global::GameAssembly || Global::GameAssembly == INVALID_HANDLE_VALUE)
    {
        Console::Print("Failed to load module");
        return;
    }

    Console::Print("Module loaded at 0x%p", Global::GameAssembly);
}

#define DEFINE_PASSTHROUGH_FUNCTION(return_type, func_name, arg_types, arg_names)        \
    EXTERN_C DLL_EXPORT return_type func_name arg_types                                  \
    {                                                                                    \
        static return_type (*target_func) arg_types = nullptr;                           \
        if (!target_func)                                                                \
        {                                                                                \
            target_func = reinterpret_cast<return_type (*) arg_types>(                   \
                GetProcAddress(Global::GameAssembly, #func_name));                       \
            if (!target_func)                                                            \
            {                                                                            \
                Console::Print("Failed to resolve %s()", #func_name);                    \
                return return_type();                                                    \
            }                                                                            \
        }                                                                                \
        return target_func arg_names;                                                    \
    }


DEFINE_PASSTHROUGH_FUNCTION(int, il2cpp_init, (PVOID domain_name), (domain_name));
DEFINE_PASSTHROUGH_FUNCTION(int, il2cpp_init_utf16, (PVOID domain_name), (domain_name));
DEFINE_PASSTHROUGH_FUNCTION(void, il2cpp_shutdown, (), ());
DEFINE_PASSTHROUGH_FUNCTION(void, il2cpp_set_config_dir, (PVOID config_path), (config_path));
/* ... */

Then, in functions where a type or method name is passed in, we first try to execute the original function without hashing anything and if it fails, we use the same hash function that we used previously:

EXTERN_C DLL_EXPORT PVOID il2cpp_class_from_name(const PVOID image, const char* namespaze, const char* name)
{
    static PVOID(*target_func)(const PVOID, const char*, const char*) = nullptr;
    if (!target_func)
        target_func = reinterpret_cast<PVOID(*)(const PVOID, const char*, const char*)>(GetProcAddress(Global::GameAssembly, "il2cpp_class_from_name"));

    Console::Print("il2cpp_class_from_name(): %s.%s", namespaze, name);

    PVOID result = target_func(image, namespaze, name);
    if (result)
        return result;

    const size_t s1 = strlen(namespaze);
    const size_t s2 = strlen(name);

    char t1[256];
    char t2[256];

    if (s1 >= sizeof(t1) || s2 >= sizeof(t2))
    {
        Console::Print("Buffer too small");
        return result;
    }

    memcpy(t1, namespaze, s1 + 1);
    memcpy(t2, name, s2 + 1);

    Hash::Run(t1, s1);
    Hash::Run(t2, s2);

    Console::Print("-> %s.%s", t1, t2);

    result = target_func(image, t1, t2);

    Console::Print("-> 0x%p", result);

    return result;
}

And that’s it. If we now run the game, it will start and work just fine. We can also verify that no weird stuff is going on by checking the logs again.

Possible issues

In my proof of concept, I implemented the hashing only into il2cpp_class_from_name(), as that appeared to be all that was needed. As far as I can tell, more complex projects might require adding hashing to additional functions, such as il2cpp_class_get_field_from_name() or il2cpp_class_get_method_from_name(). That should be relatively easy to implement, though.

Another issue that will take some time to solve, but should be quite straightforward to work on, is the possibility of a hash collision. xxHash should be quite robust, but as I mentioned previously, to save time, I did name replacement with strings of the same length. This means that for very short names with 1-3 letters, the hash will also have just 1-3 letters, increasing the possibility of a collision. To solve this, a fixed length able to store at least a 64-bit number should be used, which requires shifting the entire file around and recalculating all the offsets.

While the names are hashed in global-metadata.dat and therefore will be returned like that when using off-the-shelf tools to dump them, some of them can still be restored through manual analysis. This can be done by parsing the scene and asset files, extracting the names from them, finding the hash function, running those extracted names through it, and then associating those names with the hashes returned by the dumper.

Performance can also be an issue, although from my testing, the il2cpp_*_from_name() exports don’t get called very often. The engine usually calls them once when initializing the class/type and then uses a pointer to reference them. However, there might be some cases where overhead can be introduced, such as when you need to instantiate many classes at once (e.g., AI or particles). Even then, the overhead should be minimal if memory allocations and frees are kept down.

So far, the biggest problem I have noticed is that you can use the same class, field, property, and method name as something internal in Unity. For example, you can create a class called AudioSource in your own namespace, which is perfectly fine. The issue with that is that global-metadata.dat does not store duplicate strings multiple times, so if you replace your own class name with something else, you are replacing all references to AudioSource. This can be solved by tediously going over all the definitions and checking whether multiple of them reference the same string.

And finally, stability. I did all of my testing on the example projects that Unity provides. Attempting to do something similar on projects with extremely large and complex codebases might introduce issues I had no idea about, but I am sure that with enough time and effort something similar can be ironed out to work well.

Other tricks

Those tricks are not IL2CPP-specific and can also be applied to projects using Mono. In some cases, the same concepts can even be adapted for use with entirely different game engines.

Export/Import Obfuscation

This is straightforward to implement. All we need to do is replace the export names and make corresponding replacements for the associated import names. For example, in our case, we would replace the export names in GameAssembly.dll by modifying its PE headers, and then perform string replacement in UnityEngine.dll, as it dynamically resolves the required imports.

If we wanted to get particularly creative, instead of using random names or a hashing function, we could simply swap the imports around. For example, the function il2cpp_class_from_name could be renamed to il2cpp_array_new, and il2cpp_array_new could be renamed to il2cpp_class_from_name.

Loader stub

We can write a custom loader which, on Windows, would mean replacing the main .exe file (all we need to do is call UnityMain() in UnityEngine.dll). This loader would contain UnityEngine.dll, GameAssembly.dll, global-metadata.dat, and possibly other files as encrypted resources. These resources would only get decrypted once the loader starts, and they would only reside in memory. However, this would require hooking functions such as CreateFile() and ReadFile() since Unity expects these files to exist on disk.

Alternatively, we could use a commercial protector tool like VMProtect, which includes a virtual file system that works exactly like that.

Fake engine version

We can patch out the engine version from the files which will confuse automatic tools. For example global-metadata.dat has also it’s own version depending on which Unity version is used. For Unity 2022.3.55f1 that is version 31. This version is only checked once in GameAssembly.dll and the check can be easilly patched too.

The engine version can also be changed in other places, but that might require mode modifications.

Conclusion

Obviously, the code presented here does not handle all sorts of edge cases (as noted in the issues section). However, given that it took me roughly a few hours to write it, including this article, I’d say it should not be that big of a deal for larger studios to write a proper toolset.

I am not aware of the Unity Enterprise source code access for modification pricing, but unless it’s so extremely expensive that it’s not viable even for large studios, then none of this should really be needed. They could just directly integrate obfuscation into the build process itself and, for good measure, perhaps even change the global-metadata.dat format.

What I don’t really understand though, is why Unity themselves don’t try to make reverse engineering of builds a bit harder. Imagine if you could just check a checkbox in the build settings, and all of the names would be hashed with a random seed, including the ones in scenes and assets. You would then get a file containing a list of the original and hashed names, so in case something goes wrong, you could look up the originals, as with any decent obfuscator.

Anyway, I hope that this article can spark a discussion about possible obfuscation methods a little bit and possibly even inspire someone to write more polished tools.

In case you want to experiment yourself, all of the code used here is in this repository.

Thanks for reading.

I also noted that while, on paper, such isolation seems like a perfect idea that could even potentially completely eliminate the need for kernel-mode anti-cheat solutions, in practice, at least in its current state, it is not really viable. Any experienced developer will still be able to get around it due to complete control over the system’s early boot stages.

To prove my point and to have something that can then be used for writing detections, I decided to challenge myself to develop a project that could be used to modify the game’s memory. I called the project SecureHack (very creative, I know).

If you haven’t read the previous article and have no idea what VBS enclaves are, please do so now, as I am going to assume you have read it.

Setting a goal

It seems like the goal is incredibly straightforward, just somehow gain access to the enclave’s memory. While it is the goal, just by itself, it would make an extremely short and boring article. For example, we could enable test signing mode and patch both the host process and the enclave to enable its debugging. Does this allow us to access its memory? Yes, but it’s not really what we are looking for, is it?

So, to make it more interesting, for the purposes of this article, let’s imagine that SecureGame actually has some anti-cheat system that:

• Protects the integrity of the host process (no 3rd party code execution, no patching, signature verification)
• Verifies that the enclave is loaded as an actual enclave (no API hooks that would cause the enclave to be loaded as a normal module)
• Checks that enclave debugging is disabled (no simple securekernel.exe patches or process flags override)

And to make it more fun, the final goal will be to modify the score of one of the players in the game.

SecureGame running without any modifications

Boot process

Since Hyper-V won’t allow us to access its internals from within the system once it’s booted up and virtualized, we will need to get a bit creative. The most direct approach would be to essentially write a bootkit that will hook into the boot process. The latest versions of Microsoft Windows officially support only UEFI boot.

When Hyper-V is not enabled, the boot process is very simple. First, the firmware loads bootx64.efi in the \EFI\Boot directory on the EFI partition, which is an EFI application and is the actual executable implementing the boot manager. You can also find bootmgfw.efi in \EFI\Microsoft, which is a copy of it. You can launch both of those manually through the EFI shell or programmatically with LoadImage()/StartImage().

Boot manager (bootmgfw.efi) showing boot options

The boot manager then loads the next stage, which is winload.efi. That is located on the main NTFS partition in C:\Windows\System32. Don’t be misled by the .efi extension, though. It’s not an EFI application, but instead, it has its custom PE subsystem WINDOWS_BOOT_APPLICATION (value 0x10).

This stage then loads core drivers (disk, filesystem, chipset, TPM) into memory and finally loads the OS kernel (ntoskrnl.exe, again from C:\Windows\System32). It then passes execution to the kernel, which completes the loading of those core drivers, starts loading other boot-time drivers, begins execution on all cores, and finishes the boot process.

When Hyper-V and VBS are enabled, the boot process changes significantly. Before winload.efi starts loading the kernel, Hyper-V is initialized, which virtualizes the system. This is done by loading and starting the main Hyper-V module (hvax64.exe for AMD and hvix64.exe for Intel systems; technically, this is handled through hvloader.dll, which then then calls back to winload.efi to load the actual module, more on that later).

The boot process then continues, but as a Hyper-V guest. Microsoft refers to this as virtual secure mode (VSM), which leverages hypervisor capabilities to isolate system components from each other. Microsoft also defines virtual trust levels (VTLs), where a VTL with a higher number represents a higher privilege level. In this setup, the standard kernel ntoskrnl.exe and user-mode processes run in VTL0, while securekernel.exe and its processes (including enclaves) run in VTL1.

This means that we need to somehow intercept the loading of hvax64.exe or hvix64.exe so that we can patch it. Doing it later is simply not possible because the system will already be virtualized with isolation in place.

Déjà vu?

Back in 2021, @IDontCode released the Voyager project, which implemented Hyper-V VM exit hooking for both AMD and Intel platforms and, more importantly, memory management that allowed copying memory from and to the guest as well as between different running processes. Here is the related blog article. Additionally, all the way back in 2017, @Cr4sh released Hyper-V Backdoor as one of the possible DMA payloads.

This means that much of the actual hard work has already been done, so let’s take inspiration from those two projects and work toward the goal of our VBS enclave memory manipulation.

Patching Hyper-V

So let’s finally start with the fun stuff. The two previous projects used signature based scans and quite tedious hook chain to intercept Hyper-V load. Since my goal is not to support older versions of Windows and I only have AMD based system, I will focus on that.

Conveniently, in later versions of Windows, winload.efi exports both BlLdrLoadImage(), which is used to load the Hyper-V module, and BlImgAllocateImageBuffer(), which is used to allocate its memory. The idea is as follows: similar to the previous projects, we will intercept this module load and add a new section to it using an EFI application or driver. Instead of adding a dedicated payload, however, we will just remap the entire EFI executable into it, which will double as both the Hyper-V payload and the initial patcher.

To achieve this without any complex hook chains or signature based scans, we can simply hook the EFI runtime service function GetVariable(). This function is called by winload.efi very early after it starts, to check whether secure boot is enabled or not.

To hook GetVariable(), all we need to do is swap the pointer in the EFI runtime services table and recalculate the table’s CRC.

VOID* SetServicePointer(EFI_TABLE_HEADER* serviceTableHeader, VOID** serviceTableFunction, VOID* newFunction)
{
    CONST EFI_TPL tpl = gBS->RaiseTPL(TPL_HIGH_LEVEL);

    VOID* originalFunction = *serviceTableFunction;
    *serviceTableFunction = newFunction;

    serviceTableHeader->CRC32 = 0;
    gBS->CalculateCrc32((UINT8*)serviceTableHeader, serviceTableHeader->HeaderSize, &serviceTableHeader->CRC32);

    gBS->RestoreTPL(tpl);

    return originalFunction;
}

EFI_STATUS EFIAPI UefiMain(const EFI_HANDLE imageHandle, EFI_SYSTEM_TABLE* systemTable)
{
    DebugInit(COM1);
    DebugFormat("UefiMain() @ 0x%p\n", (VOID*)UefiMain);

    OriginalGetVariable = (EFI_GET_VARIABLE)SetServicePointer(&gST->Hdr, (VOID**)&gRT->GetVariable, (VOID*)HookedGetVariable);
    Print(L"GetVariable(): 0x%p -> 0x%p\n", OriginalGetVariable, HookedGetVariable);

    return EFI_SUCCESS;
}

Once it’s hooked, we check for SetupMode or SecureBoot variable reads. If one of those variables is being read, we obtain the calling function address (_ReturnAddress()) and scan the memory downwards from there to find PE image headers. Once found, we verify that the image has exported functions BlLdrLoadImage() and BlImgAllocateImageBuffer(). If that is the case, the function is being called from within winload.efi, and we can proceed to hook those two functions. I have used a slightly modified version of the LightHook library for that.

EFI_STATUS EFIAPI HookedGetVariable(CHAR16* variableName, EFI_GUID* vendorGuid, UINT32* attributes, UINTN* dataSize, VOID* data)
{
    if (StrCmp(variableName, L"SetupMode"))
        return OriginalGetVariable(variableName, vendorGuid, attributes, dataSize, data);

    UINT64 returnAddress = (UINT64)_ReturnAddress();
    while (CompareMem((VOID*)returnAddress, "This program cannot be run in DOS mode", 38) != 0)
    {
        returnAddress--;
    }

    const UINT64 moduleBase = returnAddress - 0x4E;

    const UINT64 loadImage = GetExport((VOID*)moduleBase, "BlLdrLoadImage");
    if (!loadImage)
        return OriginalGetVariable(variableName, vendorGuid, attributes, dataSize, data);

    const UINT64 allocateImageBuffer = GetExport((VOID*)moduleBase, "BlImgAllocateImageBuffer");
    if (!allocateImageBuffer)
        return OriginalGetVariable(variableName, vendorGuid, attributes, dataSize, data);

    if (HooksInstalled)
        return OriginalGetVariable(variableName, vendorGuid, attributes, dataSize, data);

    gST->ConOut->SetAttribute(gST->ConOut, EFI_RED | EFI_BACKGROUND_BLACK);
    gST->ConOut->ClearScreen(gST->ConOut);
    Print(L"SecureHack\n");

    gST->ConOut->SetAttribute(gST->ConOut, EFI_LIGHTGRAY | EFI_BACKGROUND_BLACK);
    Print(L"ReturnAddress                -> (phys) 0x%p\n", returnAddress);
    Print(L"BlLdrLoadImage               -> (phys) 0x%p\n", loadImage);
    Print(L"BlImgAllocateImageBuffer     -> (phys) 0x%p\n", allocateImageBuffer);

    BlLdrLoadImageHook = CreateHook((VOID*)loadImage, (VOID*)HookedBlLdrLoadImage);
    if (!EnableHook(&BlLdrLoadImageHook))
    {
        Print(L"Failed to hook BlLdrLoadImage\n");
        INFINITE_LOOP();
    }

    BlImgAllocateImageBufferHook = CreateHook((VOID*)allocateImageBuffer, (VOID*)HookedBlImgAllocateImageBuffer);
    if (!EnableHook(&BlImgAllocateImageBufferHook))
    {
        Print(L"Failed to hook BlImgAllocateImageBuffer\n");
        INFINITE_LOOP();
    }

    HooksInstalled = TRUE;

    Sleep(3);

    return OriginalGetVariable(variableName, vendorGuid, attributes, dataSize, data);
}

The first function out of those two that will be be called is going to be BlImgAllocateImageBuffer(). We need to do two things:

• Extend the allocation so that it will fit our new section
• Make sure that the allocated memory has read-write-execute (RWX) permissions since the new section will contain both data and code

There is a problem though. How do we tell which image is being loaded? Even though there is no parameter passed in that has the image path or image name, there is an attributes parameter. While I have no idea what those attributes mean, by debugging, I have figured that the Hyper-V image is going to have different attributes than the rest of the images that are being loaded, and the first allocation is going to be the one we are after.

UINT64 EFIAPI HookedBlImgAllocateImageBuffer(VOID** imageBuffer, UINTN imageSize, UINT32 memoryType, const UINT32 attributes, VOID* unknown1, VOID* unknown2)
{
    /*
     * First one with this type is the actual allocation:
     * BlImgAllocateImageBuffer(): 0xFFFFF806387AA000 (4276224) (147456)
     * BlLdrLoadImage(): \WINDOWS\system32\hvax64.exe hv.exe 0xFFFFF806387AA000 (4276224)
     * BlImgAllocateImageBuffer(): 0xFFFFF80638BBE000 (77824) (147456)
     * BlLdrLoadImage(): \WINDOWS\system32\hv.exe hv.exe 0xFFFFF806387AA000 (4276224)
     */
    if (attributes == ATTRIBUTE_HV_IMAGE && !ExtendedSize)
    {
        ExtendedSize = TRUE;

        const UINTN originalSize = imageSize;
        const UINTN currentImageSize = GetCurrentImageSize();
        imageSize += currentImageSize;
        memoryType = MEMORY_ATTRIBUTE_RWX;

        DebugFormat("Extended allocation for 0x%p from %ld to %ld (+%ld)\n", imageBuffer, originalSize, imageSize, currentImageSize);
    }

    const UINT64 allocated = ((UINT64(*)(VOID**, UINTN, UINT32, UINT32, VOID*, VOID*))BlImgAllocateImageBufferHook.Trampoline)(
        imageBuffer, imageSize, memoryType, attributes, unknown1, unknown2);

    return allocated;
}

After that BlLdrLoadImage() is called. It is just a wrapper around LdrpLoadImage(). We don’t really care about any of the bazillion different function parameters except for the image path, name, and the structure holding information about the current module which is being loaded (its base address and size).

The Hyper-V image is always going to have the name hv.exe no matter the platform. When the hook is called, we call the original to load the image and then, if it’s the Hyper-V image, we change the SizeOfImage property in the NT headers of the image to match our extended allocation and proceed with the next step, which is to add the new section, copy ourselves into it, and hook VM exit.

EFI_STATUS HookedBlLdrLoadImage(VOID* arg1, VOID* arg2, VOID* arg3, VOID* arg4, VOID* arg5, VOID* arg6, VOID* arg7,
    VOID* arg8, VOID* arg9, VOID* arg10, VOID* arg11, VOID* arg12, VOID* arg13, VOID* arg14,
    VOID* arg15, VOID* arg16, VOID* arg17)
{
    const EFI_STATUS status = ((EFI_STATUS(*)(VOID*, VOID*, VOID*, VOID*, VOID*, VOID*, VOID*, VOID*, VOID*, VOID*, VOID*, VOID*, VOID*, VOID*, VOID*, VOID*, VOID*))BlLdrLoadImageHook.Trampoline)(
        arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10, arg11, arg12, arg13, arg14, arg15, arg16, arg17);

    if (EFI_ERROR(status))
        return status;

    CHAR16* imagePath = (CHAR16*)arg3;
    CHAR16* imageName = (CHAR16*)arg4;

    if (!imagePath || !imageName)
        return status;

    const PLDR_DATA_TABLE_ENTRY entry = *(PPLDR_DATA_TABLE_ENTRY)arg9;

    if (StrCmp(imageName, L"hv.exe"))
        return status;

    if (PatchedHyperV)
        return status;

    PatchedHyperV = TRUE;

    const UINT32 newSize = (UINT32)(entry->SizeOfImage + GetCurrentImageSize());

    DebugFormat("Image %S is being loaded:\n - Path: %S\n - Base: 0x%p\n - Original size: %u\n - Extended size: %u\n", imageName, imagePath, entry->ModuleBase, entry->SizeOfImage, newSize);

    entry->SizeOfImage = newSize;
    NT_HEADERS(entry->ModuleBase)->OptionalHeader.SizeOfImage = newSize;

    ProcessHvImage(entry->ModuleBase);

    return status;
}

We are creating this new section since, once Hyper-V virtualizes the system, from its execution context, our driver’s memory is not valid (it’s mapped at a different address and it’s not executable).

But now, let’s find the VM exit handler so we can hook it. A VM exit is an event where the guest stops execution and control is transferred back to the hypervisor to handle specific operations or events (like instruction intercepts or access violations). Having control over it basically gives us control over the entire hypervisor. Finding the handler is quite trivial since we can just search for the VMRUN instruction in the case of AMD SVM. There are multiple instances of it in hvax64.exe, so you might need to go through them to find the actual VM loop.

Just a heads up, for some reason IDA flags code containing the VMRUN instruction we are looking for as data, so do not search for it as text. Instead, search for the 0F 01 D8 hex sequence.

Once we find it, right under it, there are two CALL instructions. The second one points to the actual function handling the exit. If we want to hook it, all we have to do is patch the CALL instruction to point to our function instead.

So in our driver, we will do a signature scan for the function call, then replace its relative offset and save the original function address, but not as an absolute value—instead as a relative offset to the hooked function, since the memory layout will change later. We will then copy our driver’s image in its entirety into the newly created section.

extern IMAGE_DOS_HEADER __ImageBase;
VOID ProcessHvImage(const UINT64 imageBase)
{
    const UINT32 currentImageSize = (UINT32)GetCurrentImageSize();
    const UINT64 section = AddSection(imageBase, ".uwu", currentImageSize, SECTION_RWX);
    DebugFormat("Added new section at 0x%p\n", section);

    const UINT64 scan = FindPatternImage((VOID*)imageBase, "E8 ? ? ? ? 48 89 04 24 E9");
    if (!scan)
    {
        DebugFormat("Failed to find pattern\n");
        return;
    }

    const UINT64 currentImageBase = (UINT64)&__ImageBase;
    const UINT64 targetFunction = (UINT64)HookedVmExitHandler;
    const UINT64 offset = targetFunction - currentImageBase;
    const UINT64 remoteFunction = section + offset;

    const UINT64 originalBase = scan + 5;
    const INT32 originalOffset = *(INT32*)(scan + 1);
    const UINT64 originalFunction = originalBase + originalOffset;
    const INT32 newOffset = (INT32)(remoteFunction - originalBase);

    OriginalOffsetFromHook = (INT32)(originalFunction - remoteFunction);

    DebugFormat("Found function call at 0x%p:\n", scan);
    DebugFormat(" - Original offset: %d\n", originalOffset);
    DebugFormat(" - Original function: 0x%p\n", originalFunction);
    DebugFormat(" - New offset: %d\n", newOffset);
    DebugFormat(" - New function: 0x%p\n", remoteFunction);
    DebugFormat(" - Hook offset: %d\n", OriginalOffsetFromHook);

    *(INT32*)(scan + 1) = newOffset;

    CopyMem((VOID*)section, (VOID*)&__ImageBase, currentImageSize);
    DebugFormat("Remapped current image to 0x%p with size %u\n", section, currentImageSize);
}

And voilà, we have just hooked the VM exit. What now?

VM exit

We now have a custom handler that gets called every time a VM exit happens. It’s not really that useful yet, though. We need to get information about each exit and have a way to access and modify the guest’s registers.

UINT64 HookedVmExitHandler(VOID* arg1, VOID* arg2, VOID* arg3)
{
    return ((OriginalVmExitHandler_t)((UINT64)HookedVmExitHandler + OriginalOffsetFromHook))(arg1, arg2, arg3);
}

First, let’s resolve the issue of registers access. Usually, when writing a hypervisor, you would save the registers state into some sort of structure, which you would pass to the exit handler and then restore their state from this structure when entering the guest again. It’s exactly the same here. If we look just above the exit handler call, we can see that register values are being pushed into memory saved in the register R8. Since Microsoft ABI is used, R8 is the third parameter of the function.

We can use this in our handler as follows:

typedef struct __declspec(align(16)) GUEST_CONTEXT
{
    UINT8 Reserved1[8];
    UINT64 Rcx;
    UINT64 Rdx;
    UINT64 Rbx;
    UINT8 Reserved2[8];
    UINT64 Rbp;
    UINT64 Rsi;
    UINT64 Rdi;
    UINT64 R8;
    UINT64 R9;
    UINT64 R10;
    UINT64 R11;
    UINT64 R12;
    UINT64 R13;
    UINT64 R14;
    UINT64 R15;
    /* ... */
} GUEST_CONTEXT, * PGUEST_CONTEXT;

UINT64 HookedVmExitHandler(VOID* arg1, VOID* arg2, const PGUEST_CONTEXT context)
{
    return ((OriginalVmExitHandler_t)((UINT64)HookedVmExitHandler + OriginalOffsetFromHook))(arg1, arg2, context);
}

Now we need to get the virtual machine control block (VMCB) to obtain information about the exit reason and the current guest state. This is also quite easy. The VMCB holds the exit reason at offset 0x70. Inside the original exit handler function, there is a huge switch-case structure to handle different exit reasons. Right above it, we can see the actual exit reason code being read from the VMCB at the previously mentioned offset.

Then we can just look at how the VMCB value is assigned at the top of the function. There is some pointer arithmetic and dereferencing from the second argument. Let’s not overthink it and just directly copy it.

Which will get us this beautiful piece of code:

typedef struct _VMCB_CONTROL_AREA
{
    /* ... */
    UINT64 VIntr;                       // +0x060
    UINT64 InterruptShadow;             // +0x068
    UINT64 ExitCode;                    // +0x070
    UINT64 ExitInfo1;                   // +0x078
    UINT64 ExitInfo2;                   // +0x080
    UINT64 ExitIntInfo;                 // +0x088
    /* ... */
} VMCB_CONTROL_AREA, * PVMCB_CONTROL_AREA;

PVMCB_CONTROL_AREA GetVmcb(const UINT64 context)
{
    const UINT64 v3 = *((UINT64*)context - 384);
    const UINT64** v7 = (UINT64**)(v3 + 5056);
    return (PVMCB_CONTROL_AREA)(**v7);
}

UINT64 HookedVmExitHandler(VOID* arg1, VOID* arg2, const PGUEST_CONTEXT context) 
{
    PVMCB_CONTROL_AREA vmcb = GetVmcb((UINT64)arg2);
    /* ... */
}

Now the last thing that remains is to figure out how to continue execution if we want to intercept some exit but don’t call the original handler afterward (since that could overwrite our register changes, for example). The function returns a value at the 0x0 offset from the GS segment.

Let’s again just do the same as the original handler. If we want to handle the exit without calling the original, we can then do something like this:

UINT64 HookedVmExitHandler(VOID* arg1, VOID* arg2, const PGUEST_CONTEXT context)
{
    PVMCB_CONTROL_AREA vmcb = GetVmcb((UINT64)arg2);
    if (vmcb->ExitCode == VMEXIT_CPUID)
    {
        /* Custom CPUID handling code here */

        vmcb->Rip = vmcb->NRip;
        return __readgsqword(0);
    }

    return ((OriginalVmExitHandler_t)((UINT64)HookedVmExitHandler + OriginalOffsetFromHook))(arg1, arg2, context);
}

Let’s test it out. In a normal user-mode program (in VTL0), we are going to execute the CPUID instruction, which will cause an exit. We can then compare the register values to figure out if it’s coming from our program, effectively adding a backdoor that we can use. Again, we are using the Microsoft ABI, so we’ll just stick with that, which means that RCX contains the first function parameter, RDX contains the second, and RAX holds the return value. The first parameter is going to be a magic value to verify the call, and the second one is going to specify which command should be executed.

We can then implement a check to verify that our exit hook is in place as follows:

#define CPUID_BACKDOOR 0xaabbccdd12345
#define CPUID_RETURN_VALUE 0x123456789
#define COMMAND_CHECK_PRESENCE 1

VOID HandleCPUID(const PVMCB_CONTROL_AREA vmcb, const PGUEST_CONTEXT context)
{
    switch (context->Rdx)
    {
    case COMMAND_CHECK_PRESENCE:
        vmcb->Rax = CPUID_RETURN_VALUE;
        break;
    default:
        break;
    }
}

UINT64 HookedVmExitHandler(VOID* arg1, VOID* arg2, const PGUEST_CONTEXT context)
{
    /* ... */

    PVMCB_CONTROL_AREA vmcb = GetVmcb((UINT64)arg2);
    if (vmcb->ExitCode == VMEXIT_CPUID && context->Rcx == CPUID_BACKDOOR)
    {
        HandleCPUID(vmcb, context);

        vmcb->Rip = vmcb->NRip;
        return __readgsqword(0);
    }

    /* ... */
}

And in the user-mode program:

ExecuteCPUID proc
    cpuid
    ret
ExecuteCPUID endp

inline bool CheckPresence()
{
    const auto result = ExecuteCPUID(CPUID_BACKDOOR, COMMAND_CHECK_PRESENCE);
    return result == CPUID_RETURN_VALUE;
}

if (!Control::CheckPresence())
{
    printf("Test call did not return CPUID_RETURN_VALUE\n");
    return;
}

printf("Test call returned CPUID_RETURN_VALUE\n");

After running the program with our hooks in place, we should get the custom return value.

Memory

We have successfully hyperjacked Hyper-V, but it’s not very useful yet. We need to figure out how to read and write the host’s physical memory so that we can copy data between our control (or cheat) process running in VTL0 and the game’s enclave in VTL1, since in the Hyper-V context, there are no virtual memory mappings for them.

Remember how I mentioned that the previous projects already did the hard work? Well, the Voyager project uses a self-referencing PML4 entry. A self-referencing entry means that it points to the physical memory region where it itself and others are located, allowing you to freely modify the page table entries. If you want to learn how it was found, see this part of the related blog post.

We will add custom entries in such a way that each CPU core will be able to map multiple pages (again, nothing new, same as in Voyager):

EFI_STATUS MemoryInit(VOID)
{
    DebugFormat("Initialization on core %d:\n", MemoryGetCoreIndex());

    PdptPhysical = MemoryTranslate((UINT64)Pdpt);
    DebugFormat(" - PDPT: 0x%p\n", PdptPhysical);
    PdPhysical = MemoryTranslate((UINT64)Pd);
    DebugFormat(" - PD: 0x%p\n", PdPhysical);
    PtPhysical = MemoryTranslate((UINT64)Pt);
    DebugFormat(" - PT: 0x%p\n", PtPhysical);

    if (!PdptPhysical || !PdPhysical || !PtPhysical)
        return EFI_INVALID_PARAMETER;

    HyperVPml4[MAPPING_PML4_IDX].Present = 1;
    HyperVPml4[MAPPING_PML4_IDX].PageFrameNumber = PdptPhysical >> 12;
    HyperVPml4[MAPPING_PML4_IDX].Supervisor = 0;
    HyperVPml4[MAPPING_PML4_IDX].Write = 1;

    Pdpt[511].Present = 1;
    Pdpt[511].PageFrameNumber = PdPhysical >> 12;
    Pdpt[511].Supervisor = 0;
    Pdpt[511].Write = 1;

    Pd[511].Present = 1;
    Pd[511].PageFrameNumber = PtPhysical >> 12;
    Pd[511].Supervisor = 0;
    Pd[511].Write = 1;

    for (UINT32 idx = 0; idx < 512; idx++)
    {
        Pt[idx].Present = 1;
        Pt[idx].Supervisor = 0;
        Pt[idx].Write = 1;
    }

    /* ... */
}

And then walk the page tables and overwrite them to access the memory:

UINT64 MemoryMapPage(const UINT64 physicalAddress, const enum MapType type)
{
    CPUID_EAX_01 cpuidResult;
    __cpuid((INT32*)&cpuidResult, 1);

    const UINT32 index = MemoryGetCoreIndex() * 2 + (UINT32)type;
    Pt[index].PageFrameNumber = physicalAddress >> 12;

    const UINT64 mappedAddress = MemoryGetMapVirtual(physicalAddress & PAGE_MASK, type);

    __invlpg((void*)mappedAddress);

    return mappedAddress;
}

UINT64 MemoryTranslateGuestVirtual(const UINT64 directoryBase, const UINT64 guestVirtual, const enum MapType mapType)
{
    VIRTUAL_ADDRESS virtualAddress;
    virtualAddress.Value = guestVirtual;

    PML4E_64* pml4 = (PML4E_64*)MemoryMapPage(directoryBase, mapType);
    if (!pml4 || !pml4[virtualAddress.Pml4Index].Present)
        return 0;

    PDPTE_64* pdpt = (PDPTE_64*)MemoryMapPage(pml4[virtualAddress.Pml4Index].PageFrameNumber << 12, mapType);
    if (!pdpt || !pdpt[virtualAddress.PdptIndex].Present)
        return 0;

    // 1GB large page
    if (pdpt[virtualAddress.PdptIndex].LargePage)
        return (pdpt[virtualAddress.PdptIndex].PageFrameNumber << 12) + virtualAddress.Offset;

    PDE_64* pd = (PDE_64*)MemoryMapPage(pdpt[virtualAddress.PdptIndex].PageFrameNumber << 12, mapType);
    if (!pd || !pd[virtualAddress.PdIndex].Present)
        return 0;

    // 2MB large page
    if (pd[virtualAddress.PdIndex].LargePage)
        return (pd[virtualAddress.PdIndex].PageFrameNumber << 12) + virtualAddress.Offset;

    PTE_64* pt = (PTE_64*)MemoryMapPage(pd[virtualAddress.PdIndex].PageFrameNumber << 12, mapType);
    if (!pt || !pt[virtualAddress.PtIndex].Present)
        return 0;

    return (pt[virtualAddress.PtIndex].PageFrameNumber << 12) + virtualAddress.Offset;
}

UINT64 MemoryMapGuestVirtual(const UINT64 directoryBase, const UINT64 virtualAddress, const enum MapType mapType)
{
    const UINT64 guestPhysical = MemoryTranslateGuestVirtual(directoryBase, virtualAddress, mapType);
    if (!guestPhysical)
        return 0;

    return MemoryMapPage(guestPhysical, mapType);
}

EFI_STATUS MemoryCopyGuestVirtual(const UINT64 dirbaseSource, UINT64 virtualSource, const UINT64 dirbaseDestination, UINT64 virtualDestination, UINT64 size)
{
    while (size)
    {
        UINT64 destSize = PAGE_SIZE - (virtualDestination & PAGE_MASK);
        if (size < destSize)
            destSize = size;

        UINT64 srcSize = PAGE_SIZE - (virtualSource & PAGE_MASK);
        if (size < srcSize)
            srcSize = size;

        VOID* mappedSrc = (VOID*)MemoryMapGuestVirtual(dirbaseSource, virtualSource, MapSource);
        if (!mappedSrc)
            return EFI_INVALID_PARAMETER;

        VOID* mappedDest = (VOID*)MemoryMapGuestVirtual(dirbaseDestination, virtualDestination, MapDestination);
        if (!mappedDest)
            return EFI_INVALID_PARAMETER;

        const UINT64 currentSize = (destSize < srcSize) ? destSize : srcSize;
        InternalCopyMemory(mappedDest, mappedSrc, currentSize);

        virtualSource += currentSize;
        virtualDestination += currentSize;
        size -= currentSize;
    }

    return EFI_SUCCESS;
}

But hold on a second, the function name has “guest” in it. Does it copy the guest memory then? How is that possible though? This code runs on the host in the Hyper-V context, and the directory table base address is going to be a guest physical address (GPA) and not a host physical address (HPA).

Well, to put it simply, Hyper-V uses a 1:1 physical memory mapping for both VTL0 and VTL1. This means that if something is running on the system under Hyper-V in VTL0 and has data at physical address 0x20000, it will correspond to the actual host physical address 0x20000. This is for practical reasons, since Hyper-V, for example, needs to copy data between VTLs. Having the same physical address makes mapping the same physical memory region to both VTLs much more straightforward.

If you are wondering how this looks from the VTL0 perspective, if you write a kernel-mode driver that scans the whole physical memory, you will find that certain regions where Hyper-V components and securekernel.exe with its processes are located will just appear as empty and read-only, or they will be completely invalid (attempting to read them will crash the system).

WinDbg kernel-mode debugger attached to VTL0, trying to read securekernel.exe base physical address

This makes things significantly easier for us, since we can just get the directory table base from VTL0 or VTL1 and directly use it without worrying about where it comes from or doing any additional GPA -> HPA translation.

securekernel.exe

In theory, there are many ways we can now proceed to get to the game’s enclave, but having information about where securekernel.exe is loaded and its image size will help us a lot (as you’ll see later).

To get this information, we will use the fact that when securekernel.exe wants to return execution back to VTL0 (for example, after a call to load the enclave module) or to call some function in VTL0 directly, it will use a custom hypercall to do so.

We can see it in the SkCallNormalMode() function, where the variable ShvlpVtlReturn stores a function address that then performs the actual hypercall. Since the instruction to perform the hypercall depends on the platform (VMCALL for Intel, VMMCALL for AMD), this function is allocated at runtime and therefore does not directly reside in any of securekernel.exe sections.

We can intercept this hypercall (in my case on AMD, the VMMCALL instruction) and then compare the RCX register value, which is used as the hypercall code. These codes are documented by Microsoft themselves in their Hypervisor Top Level Functional Specification. The call we are looking for is HvCallVtlReturn with call code 0x0012.

Which means that the code can then look something like this:

#define HvCallVtlReturn 0x0012

if (!CalledVtlReturn && vmcb->ExitCode == VMEXIT_VMMCALL && context->Rcx == HvCallVtlReturn)
{
    CalledVtlReturn = TRUE;
    HandleVTL1ToVTL0(vmcb, context);
}

Now that we have intercepted it, we can get the securekernel.exe information by searching the memory downward for PE headers (just as we did in the GetVariable() hook). But watch out—remember how I mentioned that the ShvlpVtlReturn value is not in any securekernel.exe section and is instead allocated at runtime? As such, we cannot just take the current execution location from RIP; instead, we have to read the return address from the stack (which is going to point somewhere in SkCallNormalMode, for example).

To do that, we will map the RSP register value, read the first value on top of the stack (which is going to be at 0x0), and then use this value to iterate through memory until we find securekernel.exe’s headers.

VOID HandleVTL1ToVTL0(const PVMCB_CONTROL_AREA vmcb, PGUEST_CONTEXT context)
{
    const UINT64 rspPhysical = MemoryTranslateGuestVirtual(vmcb->Cr3, vmcb->Rsp, MapSource);
    const UINT64 rspMapped = MemoryMapPage(rspPhysical, MapSource);

    const UINT64 returnAddress = *(UINT64*)rspMapped;
    const UINT64 returnPhysical = MemoryTranslateGuestVirtual(vmcb->Cr3, returnAddress, MapSource);

    DebugFormat("VTL1 to VTL0 transition:\n");
    DebugFormat(" - RIP: 0x%p\n", vmcb->Rip);
    DebugFormat(" - RSP: 0x%p\n", vmcb->Rsp);
    DebugFormat(" - CR3: 0x%p\n", vmcb->Cr3);
    DebugFormat(" - Stack physical: 0x%p\n", rspPhysical);
    DebugFormat(" - Stack mapped: 0x%p\n", rspMapped);
    DebugFormat(" - Return virtual: 0x%p\n", returnAddress);
    DebugFormat(" - Return physical: 0x%p\n", returnPhysical);

    UINT64 currentPagePhysical = returnPhysical & ~0xFFF;
    const UINT64 searchLimit = 1024 * 1024 * 64; // 64mb
    UINT64 searchCount = 0;

    while (searchCount < searchLimit)
    {
        const UINT64 currentPageMapped = MemoryMapPage(currentPagePhysical, MapSource);
        const PIMAGE_DOS_HEADER dosHeader = (PIMAGE_DOS_HEADER)currentPageMapped;
        if (dosHeader->e_magic == IMAGE_DOS_SIGNATURE)
        {
            if (dosHeader->e_lfanew > 0 && dosHeader->e_lfanew < 4096 - sizeof(IMAGE_NT_HEADERS))
            {
                const PIMAGE_NT_HEADERS ntHeaders = (PIMAGE_NT_HEADERS)((UINT64)dosHeader + dosHeader->e_lfanew);
                if (ntHeaders->Signature == IMAGE_NT_SIGNATURE)
                {
                    DebugFormat("Found securekernel.exe:\n");
                    DebugFormat(" - Base virtual: 0x%p\n", ntHeaders->OptionalHeader.ImageBase);
                    DebugFormat(" - Base physical: 0x%p\n", currentPagePhysical);
                    DebugFormat(" - Checksum: 0x%x\n", ntHeaders->OptionalHeader.CheckSum);
                    DebugFormat(" - Size of image: 0x%x\n", ntHeaders->OptionalHeader.SizeOfImage);

                    SecureKernelInfo.BaseAddressVirtual = ntHeaders->OptionalHeader.ImageBase;
                    SecureKernelInfo.BaseAddressPhysical = currentPagePhysical;
                    SecureKernelInfo.Size = ntHeaders->OptionalHeader.SizeOfImage;
                    SecureKernelInfo.CR3 = vmcb->Cr3;
                    break;
                }
            }
        }

        currentPagePhysical -= 4096;
        searchCount += 4096;
    }

    if (searchCount >= searchLimit)
    {
        DebugFormat("No image was found\n");
        return;
    }
}

Enclave

So, what do we actually need to access the enclave’s memory? We need to figure out where in memory it’s located. Either find its physical address directly or find its virtual address and directory table base so we can translate it to physical.

The first thing that could come to your mind is to find some structure in securekernel.exe that would hold that information. That is not super easy, though, since the internal process list SkpsProcessList, which is referenced in functions like SkpsInitializeProcess(), does not hold the enclave’s process information. Enclaves are loaded in the securekernel.exe’s system process (PsIumSystemProcess) and therefore are not in the process list at all. Theoretically, we could traverse some internal structures from the system process to find the enclave module, but that seems like a lot of work given that these structures are not documented.

Another possibility would be to iterate the handle table and search for objects with the type SkmiEnclaveType, but that would also mean traversing dozens of undocumented structures.

Fortunately, we don’t need to do any of that. Instead, we can use a similar trick as with securekernel.exe. The C runtime (CRT) used by the MSVC compiler (and other compilers as well) includes CPUID instruction calls to, for example, check which Advanced Vector Extensions (AVX) version (if any) is available.

This means that we can assume that a VM exit due to CPUID will occur at least once from within the enclave when it gets loaded. How do we tell that we are in the enclave itself?

We are going to use the previously found securekernel.exe information to check the LSTAR value against. LSTAR contains the address of system calls entry point, so in VTL0 it will be pointing somewhere into ntoskrnl.exe and in VTL1 to securekernel.exe. Then, we are just going to filter only user-mode intercepts by checking that the current execution address (in RIP) is a user-mode address (below 0x7FFFFFFFFFFF). If those conditions are met, we are just going to save the current execution address and the current CR3 value for later use.

if (vmcb->ExitCode == VMEXIT_CPUID && 
    vmcb->Rip < 0x7FFFFFFFFFFF &&
    vmcb->LStar > SecureKernelInfo.BaseAddressVirtual &&
    vmcb->LStar < SecureKernelInfo.BaseAddressVirtual + SecureKernelInfo.Size)
{
    EnclaveInfo.TotalCalls++;
    EnclaveInfo.LastRip = vmcb->Rip;
    EnclaveInfo.LastCR3 = vmcb->Cr3;
}

Now we are going to add more commands to our CPUID backdoor to initialize the paging structures, translate and copy memory, and retrieve the information we have gathered. Since we need to get and return more data, we will use a struct that will be read and then written back to the control process (COMMAND_DATA).

VOID HandleCPUID(const PVMCB_CONTROL_AREA vmcb, const PGUEST_CONTEXT context)
{
    COMMAND_DATA data;
    switch (context->Rdx)
    {
    case COMMAND_CHECK_PRESENCE:
        vmcb->Rax = CPUID_RETURN_VALUE;
        break;
    case COMMAND_INIT_MEMORY:
        vmcb->Rax = MemoryInit();
        break;
    case COMMAND_GET_CR3:
        vmcb->Rax = vmcb->Cr3;
        break;
    case COMMAND_VIRTUAL_MEMORY_COPY:
        data = GetCommand(vmcb, context);
        vmcb->Rax = MemoryCopyGuestVirtual(data.VirtualMemoryCopy.SourceCr3, data.VirtualMemoryCopy.SourceAddress, data.VirtualMemoryCopy.DestinationCr3, data.VirtualMemoryCopy.DestinationAddress, data.VirtualMemoryCopy.Size);
        break;
    case COMMAND_SECUREKERNEL_INFO:
        data.SecureKernelData.BaseVirtual = SecureKernelInfo.BaseAddressVirtual;
        data.SecureKernelData.BasePhysical = SecureKernelInfo.BaseAddressPhysical;
        data.SecureKernelData.Size = SecureKernelInfo.Size;
        data.SecureKernelData.CR3 = SecureKernelInfo.CR3;
        SetCommand(vmcb, context, &data);
        break;
    case COMMAND_ENCLAVE_INFO:
        data.EnclaveData.TotalCalls = EnclaveInfo.TotalCalls;
        data.EnclaveData.LastRip = EnclaveInfo.LastRip;
        data.EnclaveData.LastCR3 = EnclaveInfo.LastCR3;
        SetCommand(vmcb, context, &data);
        break;
    default:
        break;
    }
}

/* In the control process */
inline UINT64 CopyVirtual(const UINT64 sourceCr3, const UINT64 sourceAddress, const UINT64 destinationCr3, const UINT64 destinationAddress, const UINT32 size)
{
    COMMAND_DATA data;
    data.VirtualMemoryCopy.SourceCr3 = sourceCr3;
    data.VirtualMemoryCopy.SourceAddress = sourceAddress;
    data.VirtualMemoryCopy.DestinationCr3 = destinationCr3;
    data.VirtualMemoryCopy.DestinationAddress = destinationAddress;
    data.VirtualMemoryCopy.Size = size;

    return ExecuteCPUID(CPUID_BACKDOOR, COMMAND_VIRTUAL_MEMORY_COPY, &data);
}

Let’s try to read the enclave’s memory. For now, just the PE headers information.

void Entry()
{
    /* ... */
    
    const UINT64 cr3 = Control::GetCR3();
    printf("VM:\n");
    printf(" - CR3: 0x%llX\n", cr3);
    printf("\n");
    
    /* ... */

    const SECUREKERNEL_DATA data = Control::GetSecureKernelInfo();
    printf("securekernel.exe:\n");
    printf(" - Base physical: 0x%llX\n", data.BasePhysical);
    printf(" - Base virtual: 0x%llX\n", data.BaseVirtual);
    printf(" - Size: 0x%llX\n", data.Size);
    printf(" - CR3: 0x%llX\n", data.CR3);

    /* ... */

    printf("Waiting for SecureGame.exe process...\n\n");
    DWORD pid;
    do
    {
        pid = Utils::GetPidByName(L"SecureGame.exe");
        Sleep(100);
    } while (!pid);

    Sleep(1000);

    /* ... */

    const ENCLAVE_DATA enclave = Control::GetEnclaveInfo();

    printf("Enclave:\n");
    printf(" - Total calls: %llu\n", enclave.TotalCalls);
    printf(" - Last RIP: 0x%llX\n", enclave.LastRip);
    printf(" - Last CR3: 0x%llX\n", enclave.LastCR3);

    const UINT64 moduleBase = FindEnclaveBase(cr3, enclave.LastCR3, enclave.LastRip);
    if (!moduleBase)
    {
        printf("Failed to find module base!\n");
        return;
    }

    printf(" - Headers: 0x%llX\n", moduleBase);

    IMAGE_DOS_HEADER dosHeader = {};
    IMAGE_NT_HEADERS ntHeader = {};
    Control::CopyVirtual(enclave.LastCR3, moduleBase, cr3, reinterpret_cast<UINT64>(&dosHeader), sizeof(dosHeader));
    Control::CopyVirtual(enclave.LastCR3, moduleBase + dosHeader.e_lfanew, cr3, reinterpret_cast<UINT64>(&ntHeader), sizeof(ntHeader));

    printf(" - Image base: 0x%llX\n", ntHeader.OptionalHeader.ImageBase);
    printf(" - Checksum: 0x%X\n", ntHeader.OptionalHeader.CheckSum);
    printf(" - Size of image: 0x%X\n", ntHeader.OptionalHeader.SizeOfImage);
    printf(" - Timestamp: 0x%X\n", ntHeader.FileHeader.TimeDateStamp);

    /* ... */
}

And this is what we get:

You have probably noticed that there is a bit more information in the screenshot than I have described as needed. That’s because I was experimenting a bit, but I want to highlight one thing. As I mentioned in the previous article, a copy of the enclave’s module is loaded in the host process as well. For some reason, I expected the base addresses to match, but as you can see, that’s not the case. Also, the module does not show up when you use the usual CreateToolhelp32Snapshot()/Module32First() to iterate modules (so it’s not in PEB module list). The reason why System Informer sees it is because it also uses NtQueryVirtualMemory() with MemoryMappedFilenameInformation on memory regions with the type of MEM_IMAGE.

I haven’t really been able to look into this in-depth, though. The actual virtual address of the enclave is committed even in the host process, although it’s just a large region that includes the enclave as well and you can’t read it. So it’s possible that you might be able to get the enclave’s base address in VTL1 from VTL0 user-mode somehow, but I’m not sure.

Writing the cheat

Now that we can access the memory of the enclave, it’s time to reach our goal:

And to make it more fun, the final goal will be to modify the score of one of the players in the game.

Since the game is made by us and we have the debugging symbols, all we have to do is open the enclave image SecureCore.dll in some disassembler, load the symbols, and search for the variables that store the player’s score.

As you can see in the screenshot above, the offset from the enclave’s base address to the left player’s score is 0x67AC and to the right player’s score is 0x67BC (the image base IDA uses is 0x180000000).

Let’s try reading the score first:

while (true)
{
    constexpr UINT64 leftScoreOffset = 0x67ac;
    constexpr UINT64 rightScoreOffset = 0x67bc;

    int leftScore = 0;
    Control::CopyVirtual(enclave.LastCR3, moduleBase + leftScoreOffset, cr3, reinterpret_cast<UINT64>(&leftScore), sizeof(leftScore));

    int rightScore = 0;
    Control::CopyVirtual(enclave.LastCR3, moduleBase + rightScoreOffset, cr3, reinterpret_cast<UINT64>(&rightScore), sizeof(rightScore));

    printf("\r - Left score: %i Right score: %i", leftScore, rightScore);

    Sleep(100);
}

Seems to be working, so let’s try to overwrite it…

while (true)
{
    printf("Press key to overwrite score...\n");
    getchar();

    constexpr UINT64 leftScoreOffset = 0x67ac;
    constexpr UINT64 rightScoreOffset = 0x67bc;

    int leftScore = 999999;
    Control::CopyVirtual(cr3, reinterpret_cast<UINT64>(&leftScore), enclave.LastCR3, moduleBase + leftScoreOffset, sizeof(leftScore));

    int rightScore = 0;
    Control::CopyVirtual(cr3, reinterpret_cast<UINT64>(&rightScore), enclave.LastCR3, moduleBase + rightScoreOffset, sizeof(rightScore));
}

And finally, it’s done. The complete project can be found here.

Detection

This might seem like a perfect way to cheat in some video game (regardless of enclave use), since even if there was some anti-cheat, it would have a really hard time figuring out what is going on. This is because it would be running either in user-mode or in kernel-mode but still in VTL0, and it would not have access to Hyper-V or higher VTLs… right?

While definitely stealthier than other methods, there are still quite a few ways you could detect this messing around with Hyper-V, but that’s something for a future article, since this one is already too long.

Just to give you an idea, extending the Hyper-V image will move every single allocation made right after it by its size, which you can then calculate and detect.

Final words

I think this is the longest article I have written yet. I still have trouble trying to balance the technicality of it so it’s not just technical jargon and a bunch of code, or so overly explanatory that it’s boring for the intended audience. If you have any tips for writing in the future, let me know.

Anyway, thanks for reading, and have a nice day.

What are VBS enclaves?

Hyper-V is a type-1 hypervisor, which means that when enabled, the Windows installation it’s running on becomes a guest.

Virtualization-based security (VBS) is built on top of the Hyper-V platform. Since it operates at a higher privilege level than the kernel itself, it can help enforce strict code signing requirements (HVCI) or completely isolate data even from code running at the kernel level.

VBS enclaves allow developers to leverage VBS in their applications to isolate code and data from anything else running on the computer. Think of it as running Windows inside VirtualBox or VMware Player as one VM, with this isolated environment as another. Neither can access the other unless the hosting application explicitly permits it.

Trusted execution enclaves using VBS (source)

Anti-cheat?

Traditionally on Windows, anti-cheat software utilizes kernel-mode drivers to (among other things) prevent any user-mode programs from accessing the game’s memory. I have written about it in more detail here.

The idea of using VBS enclaves is that we could run parts of the game in this isolated environment. That would mean that even if cheat developers somehow got kernel-mode code execution, they would still not be able to manipulate the code and data in this enclave.

A bit of skepticism

While it sounds like a good idea on paper, there are currently a few problems with the use of VBS enclaves:

• Limited APIs - You can’t just take an existing program and tell Windows to run it in an enclave. It has to be a library (.DLL) specifically designed to run in such enclave which then needs a host process. There is a very limited set of APIs available (libvcruntime, vertdll, UCRT, bcrypt).
• Performance - Since virtualization is involved, there will always be some overhead, which in other use-cases is not that significant, but for a game trying to run logic or get data in/out of the enclave on each frame, this overhead is something that developers have to account for.
• Security - While in theory, the enclave should be absolutely impenetrable, in practice, cheat developers will always have the edge unless the system becomes completely locked down including the firmware. While it’s true that the enclave is inaccessible to anything running inside the OS (since anything running inside the OS will run inside the virtualized environment), nothing is stopping cheat developers from writing a bootkit that will load before the OS even starts, therefore before any virtualization takes place. With a clever hook chain, they can gain complete control over the Hyper-V/VBS architecture itself (something I will be exploring in future blog posts).

Regardless of these issues, I decided to write a simple proof-of-concept project to test this idea out and to have something to experiment with in the future.

Getting started

Since VBS enclave functionality is quite new, the available sample projects and documentation are very sparse. In fact, I was not able to find any open-source project utilizing VBS enclaves, so the only starting point I could use was the official documentation and sample project.

Development tools required:

• Visual Studio 2022 version 17.9 or later
• Windows Software Development Kit (SDK) version 10.0.22621.3233 or later

Device/OS requirements:

• Windows 11 or later or Windows Server 2019 or later
• VBS/HVCI must be enabled
• For debugging and running enclaves without production signing, test-signing must be enabled

I used VMware Workstation to run the latest version of Windows 11. Don’t forget to enable nested virtualization in setting if you also do so (Virtualize Intel VT-x/EPT or AMD-V/RVI).

Since I wanted something extremely simple, I decided to write a game inspired by the classic Pong. The idea was to have a host process that would handle initialization, window creation, keyboard input and rendering, while the enclave would run the actual game logic.

I created a new solution with two projects: SecureGame, which would be the host process, and SecureCore, which would be the enclave itself.

I used vcpkg to install SDL2 and then started implementing the game logic. There’s nothing special about it; I ended up with a game loop like this:

void Game::Loop()
{
    constexpr int FPS = 240;
    constexpr int frameDelay = 1000 / FPS;

    bool running = true;
    while (running)
    {
        const Uint32 frameStart = SDL_GetTicks();

        SDL_Event event;
        while (SDL_PollEvent(&event))
        {
            if (event.type == SDL_QUIT)
                running = false;
        }

        SDL_SetRenderDrawColor(m_Renderer, 0, 0, 0, 255);
        SDL_RenderClear(m_Renderer);

        Tick();

        SDL_RenderPresent(m_Renderer);

        const int frameTime = SDL_GetTicks() - frameStart;
        if (frameDelay > frameTime)
            SDL_Delay(frameDelay - frameTime);
    }

    SDL_DestroyRenderer(m_Renderer);
    SDL_DestroyWindow(m_Window);
    SDL_Quit();
}

The interesting stuff

When the enclave is loaded, the host process can call any exported function from the enclave library using CallEnclave().

Enclave lifecycle (source)

There are several ways we could approach using it:

1. Use it only for save/load - Store and load data from the enclave, keeping the loaded data in host process memory for the least amount of time possible and only for the time they are needed.
2. Supply all required input and run the entire game logic inside the enclave. The enclave then returns data needed for rendering, which is performed by the host process.
3. Put everything in the enclave - The CallEnclave() function can also perform a “reverse call” back to the host process according to the documentation. We could write a function that allows arbitrary function calls in the host process and then call this single function from within the enclave. This would allow us to put the entire game inside the enclave and work around its limitations.

While option 3 seems the most interesting, I went with option 2 to keep things simple.

Initially, I wondered whether you could pass a pointer to host process data into the enclave and access it directly. The documentation doesn’t mention whether the host process memory is accessible to the enclave at all, and to make matters worse, the sample code only passes data values, never pointers.

CallEnclave() (very helpful) documentation (source)

By trying it out, I discovered that the enclave has access to the host process memory, so you can pass pointers to data structures inside the host process. With this knowledge, I created a structure to be shared between the enclave and the host process.

typedef struct _TICK_DATA
{
    float DeltaTime;

    bool KeyW;
    bool KeyS;
    bool KeyUp;
    bool KeyDown;

    struct
    {
        float X;
        float Y;
        float Width;
        float Height;
    } LeftPaddle, RightPaddle, Ball;

    int LeftScore;
    int RightScore;
} TICK_DATA;

This structure would hold information about which keys are pressed on the current tick, the time elapsed since the last frame rendered, and the output from the enclave containing game object positions and score.

The enclave would then implement the game logic like this (peak coding performance, don’t judge):

void Reset()
{
    Data::BallPositionX = static_cast<float>(WINDOW_WIDTH) / 2 - BALL_SIZE / 2;
    Data::BallPositionY = static_cast<float>(WINDOW_HEIGHT) / 2 - BALL_SIZE / 2;

    Data::BallVelocityX = (rand() % 2 == 0) ? BALL_SPEED : -BALL_SPEED;
    Data::BallVelocityY = (rand() % 2 == 0) ? BALL_SPEED : -BALL_SPEED;

    Data::State = Data::StateId::Running;
}

void Run(TICK_DATA* currentTick)
{
    const float deltaTime = currentTick->DeltaTime;

    if (currentTick->KeyW && Data::LeftPaddleY > 0)
        Data::LeftPaddleY -= PADDLE_SPEED * deltaTime;
    if (currentTick->KeyS && Data::LeftPaddleY < WINDOW_HEIGHT - PADDLE_HEIGHT)
        Data::LeftPaddleY += PADDLE_SPEED * deltaTime;
    if (currentTick->KeyUp && Data::RightPaddleY > 0)
        Data::RightPaddleY -= PADDLE_SPEED * deltaTime;
    if (currentTick->KeyDown && Data::RightPaddleY < WINDOW_HEIGHT - PADDLE_HEIGHT)
        Data::RightPaddleY += PADDLE_SPEED * deltaTime;

    Data::BallPositionX += Data::BallVelocityX * deltaTime;
    Data::BallPositionY += Data::BallVelocityY * deltaTime;

    if (Data::BallPositionY <= 0 || Data::BallPositionY + BALL_SIZE >= WINDOW_HEIGHT)
        Data::BallVelocityY = -Data::BallVelocityY;

    const bool ballInLeftPaddleYRange = Data::BallPositionY + BALL_SIZE >= Data::LeftPaddleY &&
        Data::BallPositionY <= Data::LeftPaddleY + PADDLE_HEIGHT;
    const bool ballInRightPaddleYRange = Data::BallPositionY + BALL_SIZE >= Data::RightPaddleY &&
        Data::BallPositionY <= Data::RightPaddleY + PADDLE_HEIGHT;

    if (Data::BallPositionX <= 20 + PADDLE_WIDTH &&
        Data::BallPositionX >= 20 &&
        ballInLeftPaddleYRange)
    {
        Data::BallPositionX = 20 + PADDLE_WIDTH;
        Data::BallVelocityX = -Data::BallVelocityX;
    }

    if (Data::BallPositionX + BALL_SIZE >= WINDOW_WIDTH - 20 - PADDLE_WIDTH &&
        Data::BallPositionX <= WINDOW_WIDTH - 20 &&
        ballInRightPaddleYRange)
    {
        Data::BallPositionX = WINDOW_WIDTH - 20 - PADDLE_WIDTH - BALL_SIZE;
        Data::BallVelocityX = -Data::BallVelocityX;
    }

    if (Data::BallPositionX <= 0)
    {
        Data::RightScore++;
        Data::State = Data::StateId::Reset;
    }
    if (Data::BallPositionX + BALL_SIZE >= WINDOW_WIDTH)
    {
        Data::LeftScore++;
        Data::State = Data::StateId::Reset;
    }
}

extern "C" __declspec(dllexport) void* CALLBACK GameTick(PVOID context)
{
    TICK_DATA* currentTick = static_cast<TICK_DATA*>(context);

    switch (Data::State)
    {
    case Data::StateId::Reset:
        Reset();
        break;
    case Data::StateId::Running:
        Run(currentTick);
        break;
    }

    currentTick->LeftPaddle.X = 20;
    currentTick->LeftPaddle.Y = Data::LeftPaddleY;
    currentTick->LeftPaddle.Width = PADDLE_WIDTH;
    currentTick->LeftPaddle.Height = PADDLE_HEIGHT;

    currentTick->RightPaddle.X = WINDOW_WIDTH - 20 - PADDLE_WIDTH;
    currentTick->RightPaddle.Y = Data::RightPaddleY;
    currentTick->RightPaddle.Width = PADDLE_WIDTH;
    currentTick->RightPaddle.Height = PADDLE_HEIGHT;

    currentTick->Ball.X = Data::BallPositionX;
    currentTick->Ball.Y = Data::BallPositionY;
    currentTick->Ball.Width = BALL_SIZE;
    currentTick->Ball.Height = BALL_SIZE;

    currentTick->LeftScore = Data::LeftScore;
    currentTick->RightScore = Data::RightScore;

    return nullptr;
}

And then the enclave function is called from within the game tick in the host process, and then the resulting game objects are rendered:

void Game::Tick()
{
    const Uint8* keystates = SDL_GetKeyboardState(nullptr);

    static Uint32 lastTime = SDL_GetTicks();
    const Uint32 currentTime = SDL_GetTicks();
    const float deltaTime = (currentTime - lastTime) / 1000.0f;
    lastTime = currentTime;

    TICK_DATA data;
    data.DeltaTime = deltaTime;
    data.KeyW = keystates[SDL_SCANCODE_W];
    data.KeyS = keystates[SDL_SCANCODE_S];
    data.KeyUp = keystates[SDL_SCANCODE_UP];
    data.KeyDown = keystates[SDL_SCANCODE_DOWN];

    PVOID returnValue = nullptr;
    if (!CallEnclave(Global::TickRoutine, &data, true, &returnValue))
    {
        char buffer[256];
        sprintf_s(buffer, "Failed to call enclave routine: %d", GetLastError());
        MessageBoxA(nullptr, buffer, "Error", MB_OK | MB_ICONERROR);
        return;
    }

    SDL_SetRenderDrawColor(m_Renderer, 255, 255, 255, 255);

    const SDL_Rect leftPaddle =
    {
        static_cast<int>(data.LeftPaddle.X),
        static_cast<int>(data.LeftPaddle.Y),
        static_cast<int>(data.LeftPaddle.Width),
        static_cast<int>(data.LeftPaddle.Height)
    };
    SDL_RenderFillRect(m_Renderer, &leftPaddle);

    const SDL_Rect rightPaddle =
    {
        static_cast<int>(data.RightPaddle.X),
        static_cast<int>(data.RightPaddle.Y),
        static_cast<int>(data.RightPaddle.Width),
        static_cast<int>(data.RightPaddle.Height)
    };
    SDL_RenderFillRect(m_Renderer, &rightPaddle);

    const SDL_Rect ball =
    {
        static_cast<int>(data.Ball.X),
        static_cast<int>(data.Ball.Y),
        static_cast<int>(data.Ball.Width),
        static_cast<int>(data.Ball.Height)
    };
    SDL_RenderFillRect(m_Renderer, &ball);

    char scoreText[32];
    sprintf_s(scoreText, "%d - %d", data.LeftScore, data.RightScore);
    RenderText(scoreText, WINDOW_WIDTH / 2 - 40, 20);
}

And that’s it, now let’s go test it out! Full source code available here.

Testing

When you start the game, nothing will seem out of the ordinary (apart from the fact that it won’t run without VBS enabled).

Let’s try to mess with it. Trying to change the score values using Cheat Engine won’t work. The score isn’t in the host process memory at all (or it’s there only for a very brief moment when it’s rendered on screen, but changing it won’t affect the actual score counter).

Ok, so what about trying to edit the code directly? When we look at the loaded modules of the process, we can actually see the loaded enclave DLL.

Does that mean we can just patch the module? Let’s open SecureCore.dll in IDA and copy over the first bytes of the GameTick() function.

Then we can scan for the function using Cheat Engine.

Let’s try to patch it by putting a return (0xC3) at the start of the function.

Aaaaand nothing. So what’s going on? Well, first of all, let’s check the memory protection.

It’s actually just read-only. No execution permissions. That’s because this is just a dummy image (most likely to prevent memory address conflicts). There’s really no way we could mess around with the code or data in the enclave with anything we launch from within the OS.

Well, is there anything we can do then? Yes, obviously. Anything that’s outside of the enclave is easily accessible. We can hook into the host process and edit the data returned by or sent to the enclave. We can also just inject Cheat Engine’s speedhack DLL (which just hooks performance counters) and that will work too, since all the time calculations are done in the host process.

Conclusion

Due to the limitations mentioned above, it would take incredible effort to implement VBS enclaves into an actual game engine in a way that would be meaningful and not completely obliterate the game’s performance. As such, I don’t really see any game developers using them, not even accounting for the system requirements (Windows 11+, VBS enabled) since gamers might not be willing to reconfigure their systems just to play some game.

On top of that, while it would prevent any attempt to manipulate the game from programs or drivers loaded in the OS, experienced developers would have no issues getting around these restrictions by writing firmware apps that would manipulate the entire Windows bootchain.

There are two things that Microsoft could do that would instantly eliminate the vast majority of game cheating:

1. Work with OEMs to enforce strict boot environment code signing policies. Secure Boot is not sufficient (1, 2). The system would have to verify everything from the moment it’s turned on until it’s turned off. If it allows loading any user-created firmware code, it’s over. However, being this strict would essentially mean locking the system down to Windows only, or at least making it very difficult to install alternative OSes (Linux), which no sane person can support.
2. While this would require enormous effort, they could introduce whole “process enclaves” where an entire process could run in a separate virtualized environment while still having access to standard NT APIs. I’ve read several security-related blog posts from them and I feel this sort of containerization is something they’re aiming for, so we’ll see.

Thanks for reading and have a nice day.

If you switch to Linux today, you’ll probably be surprised by how many games run out of the box just fine (mostly due to the Windows compatibility layer Proton built right into Steam), except for basically all competitive multiplayer games that utilize any sort of anti-cheat technology.

Just to name a few, here is a list sorted by concurrent player count from ProtonDB:

• PUBG: BATTLEGROUNDS - uses a combination of BattlEye and in-house AC, won’t launch at all.
• Call of Duty - uses RICOCHET AC, won’t launch at all.
• Rust - uses Easy Anti-Cheat, will launch, but you won’t be able to connect to any EAC-protected server (so basically any server except self-hosted ones).
• Tom Clancy’s Rainbow Six Siege - uses BattlEye, won’t launch at all.
• EA SPORTS FC 24 - uses EAAC, won’t launch at all.
• Destiny 2 - uses BattlEye, won’t launch at all.

Those are just games on Steam. Then there’s also Valorant and League of Legends, which both now use Vanguard, so they also won’t launch at all. While you can play Counter-Strike 2 on VAC-secured servers natively on Linux, anyone trying to play more seriously will likely be playing on FACEIT or ESEA, which both also won’t work.

Now I can finally get to the point of the article… Why am I writing this? As someone who uses Linux daily, I would love to see these games support it, but I just don’t see that happening any time soon. Many people in the Linux community are frustrated by the fact that these anti-cheat solutions are stopping them from playing their favorite games. It also doesn’t help that some are fear-mongering about kernel-level anti-cheat solutions and spreading misinformation.

In this article, I want to give you a high-level overview of how modern anti-cheat solutions work (which will hopefully be understandable even for non-technical people) and then explain why anti-cheat solutions in their current state just cannot work on Linux, as well as what the alternatives are.

The basics

What is a videogame cheat? We could talk for hours about whether all sorts of macros and exploits should be considered cheats, but the main thing that comes to people’s minds when talking about multiplayer games is an external program that somehow manipulates the game or reads information from the game to provide you with an advantage over others. A prime example of this would be a wallhack or aimbot.

There are generally two ways you can go about this:

1. (External) Have a completely separate process that copies memory between itself and the game.
2. (Internal) Force the game to load a DLL file (a shared library file containing code) directly into the game, executing custom code from within the game.

Unless you find some very niche way to load a DLL into the game, in both cases you will need the ability to read (and write) the game’s process memory.

Little detour

If you are not a programmer (or you are a JavaScript developer), you most likely don’t really know how memory management works on modern systems. Let’s imagine this situation: two programs are loaded in memory. What is stopping one program from directly accessing the memory of the other program?

Virtual address space in Windows (source).

While in the past it would have been perfectly possible to read (almost) any of the physical memory installed in the computer, nowadays OSes use virtual address spaces. I don’t want to go into the details of how this is handled, but all you need to know is that each program is isolated in its own address space and cannot access other programs’ memory unless it uses functions provided by the operating system itself, like ReadProcessMemory and WriteProcessMemory.

In order to use those two functions, you will need to open a handle to the process you want to read or write memory from. This handle will be specific to your process and represent the access rights that you have relative to the object it represents (in this case, the game process). Remember this for later, as it will be important.

Anti-cheat

Modern anti-cheat solutions have three main goals:

1. Block other processes from accessing the game’s memory whenever possible.
2. Detect and ban anyone who tries to get around the blocking mentioned above.
3. Once someone is banned, ensure that they cannot simply create a new game account and continue playing (HWID bans).

This is usually achieved by multiple components working together. Let’s take a look at Easy Anti-Cheat as an example:

• Loader (usually Game_EAC.exe or start_protected_game.exe)
• Game library (EasyAntiCheat_x64.dll and “invisible” module)
• Service (EasyAntiCheat.exe)
• Kernel-mode driver (EasyAntiCheat.sys)

Without a kernel-mode driver, there is no way to effectively block memory access into the game. With the kernel-mode driver, though, it’s incredibly simple. All that the driver needs to do is register a callback for handle creation, filter out requests to open such handles to the game process, check the requested permissions, and if they allow memory access, either deny the request or lower the permissions. That way, no usermode process can now read or write the games memory. Same can be applied to module loading and file system access.

Using open-source Cheat Engine to try to read protected game’s memory (all reads fail).

So how can anyone get around it? They also somehow need to get their code into the kernel, which will open many ways for them to access the game memory.

Notice how I highlighted “somehow”? That’s because Windows is a closed system where Microsoft has the control to decide who should get access to the kernel. All official kernel components are signed with Microsoft code signing certificates, so it’s trivial to verify their authenticity. All 3rd party drivers need to be signed with an EV code signing certificate (which can only be bought by companies) and then go through the Hardware Developer Center certification so they can even be loaded. I am not saying this is perfect; in fact, I will most likely be writing an article about how bad actors are still getting their stuff certified. However, when they do, it usually gets quickly revoked, and it’s so costly and complicated that most don’t even bother trying.

There is, of course, a way to get around it by using all sorts of exploits or by using vulnerable drivers (drivers that expose a programming interface to user-mode processes without any checks in place, which allows them to escalate their privileges and possibly even manipulate kernel components). This is where the second goal defined above comes in. The anti-cheat has to actively scan the system and try to find code that is not associated with any legitimate module (a module that was loaded properly, with all certs in place) and other modifications or patches that would otherwise not be there.

While most gamers are going to say that those anti-cheats are useless and that they see cheaters left and right, the truth is that they add a huge skill check, so not everyone is able to write a cheat and then not get banned. In fact, if done properly, the cheating problem can be basically eliminated this way (I’ll get to this later).

Another reason to run in the kernel is HWID (hardware identifier) banning (the 3rd point mentioned above). If a player is banned and creates a new account, playing on the same hardware will result in an immediate ban. Since the anti-cheat has a kernel component, it can directly talk to the hardware and read its serials that way. If it was running only as a user-mode process, it would be trivial to fake the serial reads. I am not personally a big fan of this since, as you can imagine, it can result in all sorts of unintended issues (people buying used hardware), but in reality, it’s not really a problem since those HWID bans usually expire after a few months (the game devs won’t tell you this though 😉).

Doing it properly

If I had to pick a game which handles cheating the best, then as of now in my humble opinion it would be Valorant by Riot Games. Keep in mind the stuff that you’ve just read and let me explain:

• The anti-cheat is loaded on boot. While scary for some, this allows them to block/detect the previously mentioned vulnerable drivers and exploits. This raises the skill required to write a cheat for the game even higher (usually, people resort to bootkits).
• The kernel driver then doesn’t do anything apart from logging (locally). When the game is actually started, it goes through those logs and figures out if the game launch should be allowed or not and does all the kernel protection stuff mentioned above.
• More advanced methods to obtain HWID are used, such as reading TPM EK, which is very hard to spoof properly.

But that’s not all. If that was all there was to it, other anti-cheats would be just as effective. The anti-cheat team closely works with the game development team as well. How? The anti-cheat introduces extra protection for certain memory regions of the game. Some game data are encrypted, and the encryption keys change with every (even small) game update, making it really annoying for cheat developers. On top of all that, the team is very active in the cheating communities to get intel about what they are up to.

I have played Valorant quite extensively, all the way from Silver to Ascendant, and I have yet to meet a cheater.

Concerns

There are two main concerns that people have with those kernel-mode anti-cheats:

1. They are in the kernel doing in-depth scans; therefore, they must be vulnerable and a security issue.
2. They are so deep in the system (and some start on system boot) that they can spy on us without us noticing.

Security

Let me ask you a question. How many vulnerable drivers (yes, those that can be abused by bad actors to gain kernel access) do you think the average gamer has on their Windows install? I’ll start with my own system. This is what I can immediately think of:

• MSI Afterburner - RTCore64.sys driver (yes, even in the latest version) has a vulnerability that allows any usermode process to read and write any kernel memory it wishes
• CPU-Z - cpuz142_x64.sys driver has (again) kernel memory read/write vulnerability and MSR register read/write

If I looked hard enough, I would most likely find more.

It would be really stupid of me to just point to random crap you could have on your computer and say “you have so much exploitable stuff, don’t even bother with security,” and that’s not what I am trying to say. Or maybe it is, but just a little bit… What I am trying to say is that there are many ways a malicious actor could do bad stuff with your system, but anti-cheat is very unlikely to have anything to do with it. In fact, I personally trust those anti-cheat developers much more than random vendors, since they are going to be very well aware of the possible abuse.

Furthermore, if you are using any commercial anti-malware solution, it’s definitely running its own kernel-mode driver (sometimes even multiple of them), and it’s most likely doing much more sketchy stuff to your system.

Overall, the Windows driver ecosystem is a mess, but unfortunately, that is not going to change any time soon.

Spying

As someone who is very well versed in Windows internals, I can tell you one thing, it doesn’t make sense. If you give the program administrative permissions (at least once), it can spy on you in the same way a kernel-mode driver could. There is absolutely no difference and it’s significantly easier to just write a standalone program. There are people who don’t want to play games because of their connection to Tencent (for example), but if it wasn’t for the kernel-mode anti-cheat, they would have no problem with it. Isn’t it a bit hypocritical? If the game company wanted to spy on you, they could have done so from the game process or the service they have most likely installed for DRM purposes.

Oh and just by the way, the vast majority of the data networked by those previously mentioned anti-cheats to their respective servers comes from their usermode component. The only thing that’s sent “by the kernel component” (in quotes since the usermode service requests the data from the driver and then networks it, drivers cannot directly network data) is the HWID mentioned multiple times above and then detections (something that’s out of the ordinary). There is really not some magic data grabbing happening that’s only possible in the kernel.

Another thing that is sometimes mentioned is that since it’s in the kernel, it would be harder for security researchers to debug and assess the possible spying. While technically true that it’s harder, it’s definitely not impossible or problematic for an experienced person, so trust me, security researchers and especially the entire cheating community keep a close eye on it, in the same way they do on the usermode components.

Linux

Congratulations, you have successfully made it. You have read all of the stuff and now we can finally get to the Linux part of this post 🎉.

As you can probably already tell by the extensive rant above, I don’t have much good news. Linux is an open system. There is no central authority like on Windows that would tell you what you can and what you cannot do in the kernel. This obviously has countless advantages and it’s why so many people (and big corporations) love it, but is also the reason why anti-cheats cannot really function like they do on Windows.

There is no way for them to block or detect memory access into the game. Anything you could think of would just not work. Kernel module? Just recompile the kernel and change the functions it uses to hide the possible cheat and bypass all checks. Mandatory kernel patch? Same thing. What about usermode detections? Just run the game in a fakeroot environment while the cheat runs with real root privileges, being hidden from the game completely… Mandatory custom kernel build? Entire Linux system dedicated to the anti-cheat? I mean… that could work, but at that point, you can just install Windows.

There have been attempts to get anti-cheat to work on Linux. Easy Anti-Cheat is the most prominent one. Developers can choose whether they want to allow it to run on Linux or not. Linux gamers look at this and use it as an argument that anti-cheat on Linux does not face any issues, but the truth is that apart from the most basic sanity checks, EAC does absolutely nothing on Linux. It’s just a simple module that facilitates the server connection and data encryption/decryption for the game.

One of the games that allowed EAC to run under Wine/Proton is Apex Legends. I won’t be putting any links here, but if you search GitHub for cheats for this game, you will find many that work on Linux and there is absolutely no anti-cheat bypass required. It just works.

All hope lost?

As mentioned above, if you want to achieve the best results, you need to utilize both the active and passive measures. Active being the kernel component on Windows blocking memory access and trying to find possible discrepancies. Passive being the code virtualization, obfuscation, game data encryption as well as proper game networking and server-sided checks.

An example of how not to utilize kernel-mode anti-cheat would be Fall Guys (yes, that’s the game that one friend made you buy just so you could play it for 30 minutes and then never open again). This game is very specific. There would be no gain in having some sort of wallhack, there would be no gain in having any sort of aimbot (you don’t aim at stuff). All that people did was speedhacking and modifying the game in a way that allowed them to jump higher and generally change their movement. This game is a prime example of why you should write your network code properly. If the game had proper networking and server checks in place (tick-based system, actions performed on both the client and server, if there is a mismatch, the server is the authority and resets the player - that’s how CS:GO did it, and that’s why people were not flying over the map in that game or speedhacking, it had other issues though), there would be no need for anti-cheat. Not even a usermode one. Instead, they fixed absolutely nothing from their side and slapped Easy Anti-Cheat on top of their game.

While it’s not really possible to do any of the previously mentioned active measures, there is nothing stopping you from utilizing the passive ones. So, if you are a game developer and want to limit cheating in your game on Linux:

• Write proper networking code, verify data sent by the client so your game server does not blindly accept mach 8 as a walking speed.
• Use code obfuscation and virtualization as much as possible (be aware of the performance penalty, be smart about what parts of the code you protect), try to change it a bit with every update (commercial bin2bin obfuscators like VMProtect or Themida will produce different results on each run).
• If you have control over the game engine itself, try to keep sensitive information on the stack as much as possible.
• Do not ship debug symbols with your game, make sure the Linux binaries are stripped.

Thanks for reading.

In 2019, though, a nuclear bomb was dropped into the scene. That nuclear bomb was a project called kdmapper.

If you have ever worked on anything remotely close to Windows internals, game hacking, or malware reversing, you most likely already know this project. Instead of using some vulnerable driver (a driver that exposes kernel memory r/w to user mode) to bypass DSE, it directly allocated memory in the kernel, copied the PE image into it, resolved its imports, and then called the entry point.

For the first few months (at least it felt like that at the time), it was a free-for-all game. People had been mapping random crap into the kernel without even understanding how any of it worked, and because most of the anticheat software at the time was not doing proper checks, they were getting away with it. After some time, though, anticheats started catching up, first by checking the most obvious things like IOCTL dispatch overwrites (they should always point to legitimate drivers’ memory regions), hooks by pointer swaps, running system threads with stack traces out of legitimate memory regions, etc. Later on, they started sending APCs or registering NMI callbacks, but most importantly, they also started proactively searching for those drivers in memory, and that’s what this article is about.

Where do we start?

If we want to scan the entire system, we pretty much have two options:

1. Walk page tables to find all valid executable pages.
2. Search all valid physical memory ranges.

I picked the second option for my demonstration since it was quicker to write.

Here is the code that I will be using:

const PPHYSICAL_MEMORY_RANGE physicalMemoryRanges = MmGetPhysicalMemoryRanges();
if (!physicalMemoryRanges)
{
    Log("Failed to get physical memory ranges!");
    return;
}

Log("Starting memory scan (this can take a while)...");
constexpr SIZE_T CHUNK_SIZE = PAGE_SIZE;
for (int i = 0; physicalMemoryRanges[i].BaseAddress.QuadPart || physicalMemoryRanges[i].NumberOfBytes.QuadPart; i++)
{
    const PHYSICAL_ADDRESS start = physicalMemoryRanges[i].BaseAddress;
    const SIZE_T totalSize = static_cast<SIZE_T>(physicalMemoryRanges[i].NumberOfBytes.QuadPart);

    for (SIZE_T offset = 0; offset < totalSize; offset += CHUNK_SIZE)
    {
        PHYSICAL_ADDRESS chunkStart;
        chunkStart.QuadPart = start.QuadPart + offset;
        const SIZE_T chunkSize = min(CHUNK_SIZE, totalSize - offset);

        MM_COPY_ADDRESS address;
        address.PhysicalAddress = chunkStart;

        SIZE_T bytesRead;
        status = MmCopyMemory(CheckBuffer, address, chunkSize, MM_COPY_MEMORY_PHYSICAL, &bytesRead);

        if (!NT_SUCCESS(status) || bytesRead != chunkSize)
            continue;

        // TODO
    }
}

Cool, now what?

Now we have access to (almost) the entire memory and we can perform some heuristic scans on it, but what do we do? The first thing that probably comes to your mind is the DOS and NT headers that each PE executable has. Unfortunately (for us), though, literally every manual mapper ever in existence either zeroes them or does not copy them to the kernel at all. So, what do we search for then?

If the driver was compiled using MSVC with all sorts of exploit mitigations enabled, like Control Flow Guard, Buffer Security Check/Security Cookie, and Spectre mitigations, there will be compiler-generated code that is always going to be the same across any compiled image that we could search for.

__GSHandlerCheckCommon - Security check handler

There are even some standard library functions that will always be statically linked into the driver.

_cpu_features_init - memset uses it to check if SSE or AVX is enabled

memset - Standard library function

This looks like the optimal choice: create patterns out of them and search the memory. If you find the pattern outside of any legitimate module region, you have most likely found a manually mapped driver. The problem?

1. Each compiler version is going to produce different output, so you will need to check for lots of patterns to get actual matches.
2. False flags are very likely due to UEFI firmware (memset, for example). You could filter out firmware entries, but that’s out of the scope of my little experiment.
3. Certain compiler settings might change the output.

I wanted something incredibly simple that would still have a high detection rate and a low false positive rate. I am going to assume that most of the drivers are compiled using MSVC. There is one thing about it specifically that we can use:

Do you see it already?

Even when you change all sorts of possible compiler options, it will always generate those wrapper functions around certain imports.

I’ve checked many drivers that I have made myself in the past and even ones that I was reversing, and to my surprise, all of them had those import wrappers. The only one that had none was (ironically) kdmapper’s HelloWorld driver (since it has only one import, it was just inlined).

The actual detection

Now that we have figured out what we are going to be searching for, we could finally go ahead and implement the search algorithm.

1. Find all absolute indirect jump instructions (FF 25).
2. Check whether the instruction is within some kernel module address.
3. If not, resolve the (assumed) import address.
4. Read the import and check whether it points to the kernel (ntoskrnl.exe).

If all those conditions are met, we have most likely found a manually mapped driver.

I heard good blog articles need fancy visual representations, so here is one.

Here is the code:

bool Detector::IsValidKernel(ULONG64 address)
{
    const PRTL_PROCESS_MODULE_INFORMATION ntoskrnl = &SystemModules->Modules[0];
    const ULONG64 ntoskrnlStart = reinterpret_cast<ULONG64>(ntoskrnl->ImageBase);
    const ULONG64 ntoskrnlEnd = ntoskrnlStart + ntoskrnl->ImageSize;

    if (address >= ntoskrnlStart && address < ntoskrnlEnd)
        return true;

    return false;
}

bool Detector::IsValidAny(ULONG64 address)
{
    for (ULONG_PTR i = 0; i < SystemModules->NumberOfModules; i++)
    {
        const PRTL_PROCESS_MODULE_INFORMATION current = &SystemModules->Modules[i];
        const ULONG64 moduleStart = reinterpret_cast<ULONG64>(current->ImageBase);
        const ULONG64 moduleEnd = moduleStart + current->ImageSize;
        if (address >= moduleStart && address < moduleEnd)
            return true;
    }

    return false;
}

// In the previous loop
bool foundGadget = false;
for (SIZE_T j = 0; j < chunkSize - 1; j++)
{
    if (CheckBuffer[j] == 0xFF && CheckBuffer[j + 1] == 0x25)
    {
        ULONG64 physicalFound = chunkStart.QuadPart + j;
        ULONG64 virtualFound = Utils::PhysicalToVirtual(physicalFound);

        // FF 25 XX XX XX XX
        int instructionOffset;
        Utils::ReadVirtualMemory(virtualFound + 2, instructionOffset);

        ULONG64 resolved;
        Utils::ReadVirtualMemory(virtualFound + instructionOffset + 6, resolved);

        if (!resolved)
            continue;

        if (!IsValidKernel(resolved))
            continue;

        if (IsValidAny(virtualFound))
            continue;

        TotalGadgets++;
        foundGadget = true;

        Log("Found at 0x%llx (0x%llx)", virtualFound, physicalFound);
    }
}

Now, let’s try to run the code on a system without any manually mapped drivers.

[MD] Starting main thread...
[MD] Initializing...
[MD] Caching system modules...
[MD] Starting memory scan (this can take a while)...
[MD] -> Gadgets: 0
[MD] -> Pages: 0
[MD] Finished
[MD] Unloading...

Now, lets try to map some random driver.

[MD] Starting main thread...
[MD] Initializing...
[MD] Caching system modules...
[MD] Starting memory scan (this can take a while)...
[MD] Found at 0xffffa97951701280 (0x23886b280)
[MD] -> Gadgets: 1
[MD] -> Pages: 1
[MD] Finished

As you can see, it has found the import wrapper in a region that is not associated with any loaded module. I have also tried this with several other drivers of mine and a few binaries that I have found around the internet.

What’s the point though?

I am writing this article because there are still some people who believe they can just map their driver, swap some random pointer, and they are good to go. This is not true with practically any modern anticheat. As you could see in the example above, even I could, in a few hours, figure out how to (somewhat) reliably detect the presence of those drivers. Now imagine what modern anticheats do. Most of them will find the mapped driver, dump it, and send it to their servers for further analysis. If that driver then ever becomes flagged as a cheat, everyone who ever had it loaded will get banned retrospectively.

I would not be surprised if, in the future, anticheats decide to do some more crazy stuff, like making the page non-executable, then waiting for an exception to be thrown and utilizing HAL exception hooking to check the stack trace.

Kernel Patch Protection, PatchGuard?

If we were to just write something into the code section of the Windows kernel, the system would crash with bug check code CRITICAL_STRUCTURE_CORRUPTION. The kernel continuously checks for changes in protected memory regions (read-only code sections) and certain structures. If it finds something it’s not expecting, the system crashes.

I don’t really want to go into details on how it works, because all you need to know for this article to make sense (somewhat) is that its initialization happens when the kernel is started and it uses for its checks the state of the kernel image that is currently in memory. In other words, if you do any modification to the kernel code from within the boot sequence, when it’s already loaded in memory, but KPP is not yet initialized, the KPP will just take the modified code as the correct one.

But… it’s different from the disk!

Let’s say that we have a bootkit. It patches the kernel before KPP is initialized and therefore the system runs just fine. How about anticheats? Surely they do check the kernel code against the files on the disk. After all, when the PE image is loaded into the memory, the individual code sections (usually .text, kernel does not allow RWX sections) should always correspond 1:1 to the ones on the disk. If they don’t, modifications were made.

Except there is a plot twist. They don’t.

Since Windows 10, version 1809, Microsoft has implemented mitigations against the Spectre vulnerability. How does it work? It runtime patches kernel-mode drivers and parts of the kernel itself.

As you can imagine, this is extremely abusable. Now those code sections are not the same as those in the file on disk. Writing huge shellcode or mapping a whole driver over those sections, though, would still be pretty easy to spot. Only imports are being replaced, which means that only a few bytes are modified at a time and the rest remains the same.

What can we do?

If we assume that anticheat software does not perform in-depth checks on those code sections, we can freely replace a few bytes without triggering a detection. Here is an example:

EFI_STATUS HookedExitBootServices(EFI_HANDLE imageHandle, UINTN mapKey)
{
	PROTECT_ULTRA();
	gBS->ExitBootServices = OriginalExitBootServices;

	UINT64 returnAddress = (UINT64)_ReturnAddress();
	while (CompareMem((VOID*)returnAddress, "This program cannot be run in DOS mode", 38) != 0)
	{
		returnAddress--;
	}

	UINT64 moduleBase = returnAddress - 0x4E;

	UINT64 loaderBlockScan = ScanForLoaderBlock((VOID*)moduleBase);
	if (!loaderBlockScan)
	{
		Print(EW(L"Failed to find OslExecuteTransition!\n"));
		INFINITE_LOOP();
	}

	UINT64 resolvedAddress = *(UINT64*)((loaderBlockScan + 7) + *(int*)(loaderBlockScan + 3));

	BlpArchSwitchContext = (BlpArchSwitchContext_t)Utils::FindPatternImage((VOID*)moduleBase, EC("40 53 48 83 EC 20 48 8B 15"));
	if (!BlpArchSwitchContext)
	{
		Print(EW(L"Failed to find BlpArchSwitchContext!\n"));
		INFINITE_LOOP();
	}

	BlpArchSwitchContext(ApplicationContext);

	PLOADER_PARAMETER_BLOCK loaderBlock = (PLOADER_PARAMETER_BLOCK)resolvedAddress;

	KLDR_DATA_TABLE_ENTRY kernelModule = Utils::GetModule(&loaderBlock->LoadOrderListHead, EW(L"ntoskrnl.exe"));
	if (!kernelModule.DllBase)
	{
		ContextPrint(EW(L"Failed to find ntoskrnl.exe in OslLoaderBlock!\n"));
		INFINITE_LOOP();
	}

	UINT64 functionScan = ScanForPatch1(kernelModule.DllBase);
	if (!functionScan)
	{
		ContextPrint(EW(L"Failed to find target function (1)!\n"));
		INFINITE_LOOP();
	}

	// mov r11, [rsp+64]
	// jmp r11
	UINT8 code[] = { 0x4C, 0x8B, 0x5C, 0x24, 0x40, 0x41, 0xFF, 0xE3 };
	Utils::CopyMemory((VOID*)functionScan, code, sizeof(code));

	BlpArchSwitchContext(FirmwareContext);

	// mapKey can change if we call certain functions with internal allocations
	// for this reason we can either resolve the key manually, but that does not seem to work
	// on certain systems (gBS->GetMemoryMap fails) so we will just use the key
	// that was passed to this function but make sure there are no internal allocation
	// (no logo or extensive framebuffer printing)

	PROTECT_END();
	return OriginalExitBootServices(imageHandle, mapKey);
}

Since the function has 8 arguments, arguments 5-8 are pushed onto the stack. rsp+64 is then the location of the last argument. That allows us to call any kernel function while still having 7 arguments.

inline uint64_t call_backdoor(uint64_t function_address, uint64_t param1 = 0, uint64_t param2 = 0, uint64_t param3 = 0, uint64_t param4 = 0, uint64_t param5 = 0, uint64_t param6 = 0, uint64_t param7 = 0)
{
    if (!data::ntdll_handle)
    {
        data::ntdll_handle = GetModuleHandleA("ntdll.dll");
        if (!data::ntdll_handle)
            throw std::exception("ntdll.dll handle could not be obtained");
    }

    if (!data::function_address)
    {
        data::function_address = reinterpret_cast<uint64_t>(GetProcAddress(data::ntdll_handle, "NtExerciseForTheReader"));
        if (!data::function_address)
            throw std::exception("NtExerciseForTheReader export not located");
    }

    typedef uint64_t(_stdcall* function_t)(uint64_t first, uint64_t second, uint64_t third, uint64_t fourth, uint64_t fifth, uint64_t sixth, uint64_t seventh, uint64_t target_function);
    const auto target_function = reinterpret_cast<function_t>(data::function_address);
    return target_function(param1, param2, param3, param4, param5, param6, param7, function_address);
}