Tibor Kiss

Written by: Nino Isakovic

Introduction

Since 2022, Google Threat Intelligence Group (GTIG) has been tracking multiple cyber espionage operations conducted by China-nexus actors utilizing POISONPLUG.SHADOW. These operations employ a custom obfuscating compiler that we refer to as “ScatterBrain,” facilitating attacks against various entities across Europe and the Asia Pacific (APAC) region. ScatterBrain appears to be a substantial evolution of ScatterBee, an obfuscating compiler previously analyzed by PWC.

GTIG assesses that POISONPLUG is an advanced modular backdoor used by multiple distinct, but likely related threat groups based in the PRC, however we assess that POISONPLUG.SHADOW usage appears to be further restricted to clusters associated with APT41.

GTIG currently tracks three known POISONPLUG variants:

• POISONPLUG
• POISONPLUG.DEED
• POISONPLUG.SHADOW

POISONPLUG.SHADOW—often referred to as “Shadowpad,” a malware family name first introduced by Kaspersky—stands out due to its use of a custom obfuscating compiler specifically designed to evade detection and analysis. Its complexity is compounded by not only the extensive obfuscation mechanisms employed but also by the attackers’ highly sophisticated threat tactics. These elements collectively make analysis exceptionally challenging and complicate efforts to identify, understand, and mitigate the associated threats it poses.

In addressing these challenges, GTIG collaborates closely with the FLARE team to dissect and analyze POISONPLUG.SHADOW. This partnership utilizes state-of-the-art reverse engineering techniques and comprehensive threat intelligence capabilities required to mitigate the sophisticated threats posed by this threat actor. We remain dedicated to advancing methodologies and fostering innovation to adapt to and counteract the ever-evolving tactics of threat actors, ensuring the security of Google and our customers against sophisticated cyber espionage operations.

Overview

In this blog post, we present our in-depth analysis of the ScatterBrain obfuscator, which has led to the development of a complete stand-alone static deobfuscator library independent of any binary analysis frameworks. Our analysis is based solely on the obfuscated samples we have successfully recovered, as we do not possess the obfuscating compiler itself. Despite this limitation, we have been able to comprehensively infer every aspect of the obfuscator and the necessary requirements to break it. Our analysis further reveals that ScatterBrain is continuously evolving, with incremental changes identified over time, highlighting its ongoing development.

This publication begins by exploring the fundamental primitives of ScatterBrain, outlining all its components and the challenges they present for analysis. We then detail the steps required to subvert and remove each protection mechanism, culminating in our deobfuscator. Our library takes protected binaries generated by ScatterBrain as input and produces fully functional deobfuscated binaries as output.

By detailing the inner workings of ScatterBrain and sharing our deobfuscator, we hope to provide valuable insights into developing effective countermeasures. Our blog post is intentionally exhaustive, drawing from our experience in dealing with obfuscation for clients, where we observed a significant lack of clarity in understanding modern obfuscation techniques. Similarly, analysts often struggle with understanding even relatively simplistic obfuscation methods primarily because standard binary analysis tooling is not designed to account for them. Therefore, our goal is to alleviate this burden and help enhance the collective understanding against commonly seen protection mechanisms.

For general questions about obfuscating compilers, we refer to our previous work on the topic, which provides an introduction and overview.

ScatterBrain Obfuscator

Introduction

ScatterBrain is a sophisticated obfuscating compiler that integrates multiple operational modes and protection components to significantly complicate the analysis of the binaries it generates. Designed to render modern binary analysis frameworks and defender tools ineffective, ScatterBrain disrupts both static and dynamic analyses.

• Protection Modes: ScatterBrain operates in three distinct modes, each determining the overall structure and intensity of the applied protections. These modes allow the compiler to adapt its obfuscation strategies based on the specific requirements of the attack.
• Protection Components: The compiler employs key protection components that include the following:
  • Selective or Full Control Flow Graph (CFG) Obfuscation: This technique restructures the program’s control flow, making it very difficult to analyze and create detection rules for.
  • Instruction Mutations: ScatterBrain alters instructions to obscure their true functionality without changing the program’s behavior.
  • Complete Import Protection: ScatterBrain employs a complete protection of a binary’s import table, making it extremely difficult to understand how the binary interacts with the underlying operating system.

These protection mechanisms collectively make it extremely challenging for analysts to deconstruct and understand the functionality of the obfuscated binaries. As a result, ScatterBrain poses a formidable obstacle for cybersecurity professionals attempting to dissect and mitigate the threats it generates.

Modes of Operation

A mode refers to how ScatterBrain will transform a given binary into its obfuscated representation. It is distinct from the actual core obfuscation mechanisms themselves and is more about the overall strategy of applying protections. Our analysis further revealed a consistent pattern in applying various protection modes at specific stages of an attack chain:

• Selective: A group of individually selected functions are protected, leaving the remainder of the binary in its original state. Any import references within the selected functions are also obfuscated. This mode was observed to be used strictly for dropper samples of an attack chain.
• Complete: The entirety of the code section and all imports are protected. This mode was applied solely to the plugins embedded within the main backdoor payload.
• Complete “headerless”: This is an extension of the Complete mode with added data protections and the removal of the PE header. This mode was exclusively reserved for the final backdoor payload.

Selective

The selective mode of protection allows users of the obfuscator to selectively target individual functions within the binary for protection. Protecting an individual function involves keeping the function at its original starting address (produced by the original compiler and linker) and substituting the first instruction with a jump to the obfuscated code. The generated obfuscations are stored linearly from this starting point up to a designated “end marker” that signifies the ending boundary of the applied protection. This entire range constitutes a protected function.

The disassembly of a call site to a protected function can take the following from:

.text:180001000 sub     rsp, 28h
.text:180001004 mov     rcx, cs:g_Imagebase
.text:18000100B call    PROTECTED_FUNCTION ; call to protected func
.text:180001010 mov     ecx, eax 
.text:180001012 call    cs:ExitProcess

Figure 1: Disassembly of a call to a protected function

The start of the protected function:

.text:180001039 PROTECTED_FUNCTION 
.text:180001039   jmp     loc_18000DF97 ; jmp into obfuscated code
.text:180001039 sub_180001039 endp
.text:000000018000103E db  48h ; H.     ; garbage data
.text:000000018000103F db 0FFh
.text:0000000180001040 db 0C1h

Figure 2: Disassembly inside of a protected function

The “end marker” consists of two sets of padding instructions, an int3 instruction and a single multi-nop instruction:

END_MARKER:
.text:18001A95C   CC CC CC CC CC CC CC CC CC CC 66 
66 0F 1F 84 00 00 00 00 00
.text:18001A95C int     3
.text:18001A95D int     3
.text:18001A95E int     3
.text:18001A95F int     3
.text:18001A960 int     3
.text:18001A961 int     3
.text:18001A962 int     3
.text:18001A963 int     3
.text:18001A964 int     3
.text:18001A965 int     3
.text:18001A966 db      66h, 66h   ; @NOTE: IDA doesn't disassemble properly
.text:18001A966 nop     word ptr [rax+rax+00000000h]
; -------------------------------------------------------------------------
; next, original function
.text:18001A970 ; [0000001F BYTES: COLLAPSED FUNCTION 
__security_check_cookie. PRESS CTRL-NUMPAD+ TO EXPAND]

Figure 3: Disassembly listing of an end marker

Complete

The complete mode protects every function within the .text section of the binary, with all protections integrated directly into a single code section. There are no end markers to signify protected regions; instead, every function is uniformly protected, ensuring comprehensive coverage without additional sectioning.

This mode forces the need for some kind of deobfuscation tooling. Whereas selective mode only protects the selected functions and leaves everything else in its original state, this mode makes the output binary extremely difficult to analyze without accounting for the obfuscation.

Complete Headerless

This complete mode extends the complete approach to add further data obfuscations alongside the code protections. It is the most comprehensive mode of protection and was observed to be exclusively limited to the final payloads of an attack chain. It incorporates the following properties:

• Full PE header of the protected binary is removed.

• Custom loading logic (a loader) is introduced.

• Becomes the entry point of the protected binary

• Responsible of ensuring the protected binary is functional

• Includes the option of mapping the final payload within a separate memory region distinct from the initial memory region it was loaded in

• The metadata is utilized by the loader as part of its initialization sequence.

• Done through an “import fixup table”

The loader’s entry routine crudely merges with the original entry of the binary by inserting multiple jmp instructions to bridge the two together. The following is what the entry point looks like after running our deobfuscator against a binary protected in headerless mode.

The loader’s metadata is stored in the .data section of the protected binary. It is found via a memory scan that applies bitwise XOR operations against predefined constants. The use of these not only locates the metadata but also serves a dual purpose of verifying its integrity. By checking that the data matches expected patterns when XORed with these constants, the loader ensures that the metadata has not been altered or tampered with.

The metadata contains the following (in order):

• Import fixup table (fully explained in the Import Protection section)

• Integrity-hash constants

• Relative virtual address (RVA) of the .data section

• Offset to the import fixup table from the start of the .data section

• Size, in bytes, of the fixup table

• Global pointer to the memory address that the backdoor is at

• Encrypted and compressed data specific to the backdoor

• Backdoor config and plugins

Core Protection Components

Instruction Dispatcher

The instruction dispatcher is the central protection component that transforms the natural control flow of a binary (or individual function) into scattered basic blocks that end with a unique dispatcher routine that dynamically guides the execution of the protected binary.

Each call to a dispatcher is immediately followed by a 32-bit encoded displacement positioned at what would normally be the return address for the call. The dispatcher decodes this displacement to calculate the destination target for the next group of instructions to execute. A protected binary can easily contain thousands or even tens of thousands of these dispatchers making manual analysis of them practically infeasible. Additionally, the dynamic dispatching and decoding logic employed by each dispatcher effectively disrupts CFG reconstruction methods used by all binary analysis frameworks.

The decoding logic is unique for each dispatcher and is carried out using a combination of add, sub, xor, and, or, and lea instructions. The decoded offset value is then either subtracted from or added to the expected return address of the dispatcher call to determine the final destination address. This calculated address directs execution to the next block of instructions, which will similarly end with a dispatcher that uniquely decodes and jumps to subsequent instruction blocks, continuing this process iteratively to control the program flow.

The following screenshot illustrates what a dispatcher instance looks like when constructed in IDA Pro. Notice the scattered addresses present even within instruction dispatchers, which result from the obfuscator transforming fallthrough instructions—instructions that naturally follow the preceding instruction—into pairs of conditional branches that use opposite conditions. This ensures that one branch is always taken, effectively creating an unconditional jump. Additionally, a mov instruction that functions as a no-op is inserted to split these branches, further obscuring the control flow.

The core logic for any dispatcher can be categorized into the following four phases:

1. Preservation of Execution Context
   • Each dispatcher selects a single working register (e.g., RSI as depicted in the screenshot) during the obfuscation process. This register is used in conjunction with the stack to carry out the intended decoding operations and dispatch. 
   • The RFLAGS register in turn is safeguarded by employing pushfq and popfq instructions before carrying out the decoding sequence.
2. Retrieval of Encoded Displacement
   • Each dispatcher retrieves a 32-bit encoded displacement located at the return address of its corresponding call instruction. This encoded displacement serves as the basis for determining the next destination address.
3. Decoding Sequence
   • Each dispatcher employs a unique decoding sequence composed of the following arithmetic and logical instructions: xor, sub, add, mul, imul, div, idiv, and, or, and not. This variability ensures that no two dispatchers operate identically, significantly increasing the complexity of the control flow.
4. Termination and Dispatch
   • The ret instruction is strategically used to simultaneously signal the end of the dispatcher function and redirect the program’s control flow to the previously calculated destination address.

It is reasonable to infer that the obfuscator utilizes a template similar to the one illustrated in Figure 9 when applying its transformations to the original binary:

Opaque Predicates

ScatterBrain uses a series of seemingly trivial opaque predicates (OP) that appear straightforward to analysts but significantly challenge contemporary binary analysis frameworks, especially when used collectively. These opaque predicates effectively disrupt static CFG recovery techniques not specifically designed to counter their logic. Additionally, they complicate symbolic execution approaches as well by inducing path explosions and hindering path prioritization. In the following sections, we will showcase a few examples produced by ScatterBrain.

test OP

This opaque predicate is constructed around the behavior of the test instruction when paired with an immediate zero value. Given that the test instruction effectively performs a bitwise AND operation, the obfuscator exploits the fact that any value bitwise AND-ed with zero always invariably results in zero.

Here are some abstracted examples we can find in a protected binary—abstracted in the sense that all instructions are not guaranteed to follow one another directly; other forms of mutations can be between them as can instruction dispatchers.

test    bl, 0
jnp     loc_56C96             ; we never satisfy these conditions
------------------------------
test    r8, 0
jo      near ptr loc_3CBC8
------------------------------
test    r13, 0
jnp     near ptr loc_1A834
------------------------------
test    eax, 0
jnz     near ptr loc_46806

Figure 10: Test opaque predicate examples

To grasp the implementation logic of this opaque predicate, the semantics of the test instruction and its effects on the processor’s flags register are required. The instruction can affect six different flags in the following manner:

• Overflow Flag (OF): Always cleared

• Carry Flag (CF): Always cleared

• Sign Flag (SF): Set if the most significant bit (MSB) of the result is set; otherwise cleared

• Zero Flag (ZF): Set if the result is 0; otherwise cleared

• Parity Flag (PF): Set if the number of set bits in the least significant byte (LSB) of the result is even; otherwise cleared

• Auxiliary Carry Flag (AF): Undefined

Applying this understanding to the sequences produced by ScatterBrain, it is evident that the generated conditions can never be logically satisfied:

Table 1: Test opaque predicate understanding

jcc OP

The opaque predicate is designed to statically obscure the original immediate branch targets for conditional branch (jcc) instructions. Consider the following examples:

test    eax, eax
ja      loc_3BF9C
ja      loc_2D154 

test    r13, r13
jns     loc_3EA84
jns     loc_53AD9

test    eax, eax
jnz     loc_99C5
jnz     loc_121EC

cmp     eax, FFFFFFFF
jz      loc_273EE
jz      loc_4C227

Figure 11: jcc opaque predicate examples

The implementation is straightforward: each original jcc instruction is duplicated with a bogus branch target. Since both jcc instructions are functionally identical except for their respective branch destinations, we can determine with certainty that the first jcc in each pair is the original instruction. This original jcc dictates the correct branch target to follow when the respective condition is met, while the duplicated jcc serves to confuse analysis tools by introducing misleading branch paths.

Stack-Based OP

The stack-based opaque predicate is designed to check whether the current stack pointer (rsp) is below a predetermined immediate threshold—a condition that can never be true. It is consistently implemented by pairing the cmp rsp instruction with a jb (jump if below) condition immediately afterward.

cmp rsp, 0x8d6e
jb      near ptr unk_180009FDA

Figure 12: Stack-based opaque predicate example

This technique inserts conditions that are always false, causing CFG algorithms to follow both branches and thereby disrupt their ability to accurately reconstruct the control flow.

Import Protection

The obfuscator implements a sophisticated import protection layer. This mechanism conceals the binary ‘s dependencies by transforming each original call or jmp instruction directed at an import through a unique stub dispatcher routine that knows how to dynamically resolve and invoke the import in question.

It consists of the following components:

• Import-specific encrypted data: Each protected import is represented by a unique dispatcher stub and a scattered data structure that stores RVAs to both the encrypted dynamic-link library (DLL) and application programming interface (API) names. We refer to this structure as obf_imp_t. Each dispatcher stub is hardcoded with a reference to its respective obf_imp_t.

• Dispatcher stub: This is an obfuscated stub that dynamically resolves and invokes the intended import. While every stub shares an identical template, each contains a unique hardcoded RVA that identifies and locates its corresponding obf_imp_t.

• Resolver routine: Called from the dispatcher stub, this obfuscated routine resolves the import and returns it to the dispatcher, which facilitates the final call to the intended import. It begins by locating the encrypted DLL and API names based on the information in obf_imp_t. After decrypting these names, the routine uses them to resolve the memory address of the API.

• Import decryption routine: Called from the resolver routine, this obfuscated routine is responsible for decrypting the DLL and API name blobs through a custom stream cipher implementation. It uses a hardcoded 32-bit salt that is unique per protected sample.

• Fixup Table: Present only in headerless mode, this is a relocation fixup table that the loader in headerless mode uses to correct all memory displacements to the following import protection components:

• Encrypted DLL names

• Encrypted API names

• Import dispatcher references

Dispatcher Stub

The core of the import protection mechanism is the dispatcher stub. Each stub is tailored to an individual import and consistently employs a lea instruction to access its respective obf_imp_t, which it passes as the only input to the resolver routine.

push rcx                  ; save RCX
lea rcx, [rip+obf_imp_t]  ; fetch import-specific obf_imp_t
push    rdx               ; save all other registers the stub uses
push    r8
push    r9
sub     rsp, 28h
call    ObfImportResolver ; resolve the import and return it in RAX
add     rsp, 28h
pop     r9                ; restore all saved registers
pop     r8
pop     rdx
pop     rcx
jmp     rax               ; invoke resolved import

Figure 14: Deobfuscated import dispatcher stub

Each stub is obfuscated through the mutation mechanisms outlined earlier. This applies to the resolver and import decryption routines as well. The following is what the execution flow of a stub can look like. Note the scattered addresses that while presented sequentially are actually jumping all around the code segment due to the instruction dispatchers.

0x01123a   call InstructionDispatcher_TargetTo_11552 
0x011552   push rcx
0x011553   call InstructionDispatcher_TargetTo_5618
0x005618   lea rcx, [rip+0x33b5b]                    ; fetch obf_imp_t
0x00561f   call InstructionDispatcher_TargetTo_f00c
0x00f00c   call InstructionDispatcher_TargetTo_191b5
0x0191b5   call InstructionDispatcher_TargetTo_1705a
0x01705a   push rdx
0x01705b   call InstructionDispatcher_TargetTo_05b4
0x0105b4   push r8
0x0105b6   call InstructionDispatcher_TargetTo_f027
0x00f027   push r9
0x00f029   call InstructionDispatcher_TargetTo_18294
0x018294   test eax, 0
0x01829a   jo 0xf33c
0x00f77b   call InstructionDispatcher_TargetTo_e817
0x00e817   sub rsp, 0x28
0x00e81b   call InstructionDispatcher_TargetTo_a556
0x00a556   call 0x6afa (ObfImportResolver)
0x00a55b   call InstructionDispatcher_TargetTo_19592
0x019592   test ah, 0
0x019595   call InstructionDispatcher_TargetTo_a739
0x00a739   js 0x1935
0x00a73b   call InstructionDispatcher_TargetTo_6eaa
0x006eaa   add rsp, 0x28
0x006eae   call InstructionDispatcher_TargetTo_6257
0x006257   pop r9
0x006259   call InstructionDispatcher_TargetTo_66d6
0x0066d6   pop r8
0x0066d8   call InstructionDispatcher_TargetTo_1a3cb
0x01a3cb   pop rdx
0x01a3cc   call InstructionDispatcher_TargetTo_67ab
0x0067ab   pop rcx
0x0067ac   call InstructionDispatcher_TargetTo_6911
0x006911   jmp rax

Figure 15: Obfuscated import dispatcher stub

Resolver Logic

obf_imp_t is the central data structure that contains the relevant information to resolve each import. It has the following form:

struct obf_imp_t {    // sizeof=0x18
    uint32_t CryptDllNameRVA;    // NOTE: will be 64-bits, due to padding
    uint32_t CryptAPINameRVA;    // NOTE: will be 64-bits, due to padding
    uint64_t ResolvedImportAPI;  // Where the resolved address is stored
};

Figure 16: obf_imp_t in its original C struct source form

It is processed by the resolver routine, which uses the embedded RVAs to locate the encrypted DLL and API names, decrypting each in turn. After decrypting each name blob, it uses LoadLibraryA to ensure the DLL dependency is loaded in memory and leverages GetProcAddress to retrieve the address of the import.

Fully decompiled ObfImportResolver:

Import Encryption Logic

The import decryption logic is implemented using a Linear Congruential Generator (LCG) algorithm to generate a pseudo-random key stream, which is then used in a XOR-based stream cipher for decryption. It operates on the following formula:

X_n + 1 = (a • X_n + c) mod 2³²

where:

• a is always hardcoded to 17 and functions as the multiplier

• c is a unique 32-bit constant determined by the encryption context and is unique per-protected sample

• We refer to it as the imp_decrypt_const

The decryption logic initializes with a value from the encrypted data and iteratively generates new values using the outlined LCG formula. Each iteration produces a byte derived from the calculated value, which is then XOR’ed with the corresponding encrypted byte. This process continues byte-by-byte until it reaches a termination condition.

A fully recovered Python implementation for the decryption logic is provided in Figure 18.

Import Fixup Table

The import relocation fixup table is a fixed-size array composed of two 32-bit RVA entries. The first RVA represents the memory displacement of where the data is referenced from. The second RVA points to the actual data in question. The entries in the fixup table can be categorized into three distinct types, each corresponding to a specific import component:

• Encrypted DLL names

• Encrypted API names

• Import dispatcher references

The location of the fixup table is determined by the loader’s metadata, which specifies an offset from the start of the .data section to the start of the table. During initialization, the loader is responsible for applying the relocation fixups for each entry in the table.

Recovery

Effective recovery from an obfuscated binary necessitates a thorough understanding of the protection mechanisms employed. While deobfuscation often benefits from working with an intermediate representation (IR) rather than the raw disassembly—an IR provides more granular control in undoing transformations—this obfuscator preserves the original compiled code, merely enveloping it with additional protection layers. Given this context, our deobfuscation strategy focuses on stripping away the obfuscator’s transformations from the disassembly to reveal the original instructions and data. This is achieved through a series of hierarchical phases, where each subsequent phase builds upon the previous one to ensure comprehensive deobfuscation.

We categorize this approach into three distinct categories that we eventually integrate:

1. CFG Recovery

• Restoring the natural control flow by removing obfuscation artifacts at the instruction and  basic block levels. This involves two phases:

• Accounting for instruction dispatchers: Addressing the core of control flow protection that obscure the execution flow

• Function identification and recovery: Cataloging scattered instructions and reassembling them into their original function counterparts

• Original Import Table: The goal is to reconstruct the original import table, ensuring that all necessary library and function references are accurately restored.

• Generating Deobfuscated Executables: This process entails creating a new, deobfuscated executable that maintains the original functionality while removing ScatterBrain’s modifications.

Given the complexity of each category, we concentrate on the core aspects necessary to break the obfuscator by providing a guided walkthrough of our deobfuscator’s source code and highlighting the essential logic required to reverse these transformations. This step-by-step examination demonstrates how each obfuscation technique is methodically undone, ultimately restoring the binary’s original structure.

Our directory structure reflects this organized approach:

+---helpers
|   |    emu64.py
|   |    pefile_utils.py
|   |--- x86disasm.py
|
---recover
    |    recover_cfg.py
    |    recover_core.py
    |    recover_dispatchers.py
    |    recover_functions.py
    |    recover_imports.py
    |--- recover_output64.py

Figure 21: Directory structure of our deobfuscator library

This comprehensive recovery process not only restores the binaries to their original state but also equips analysts with the tools and knowledge necessary to combat similar obfuscation techniques in the future.

CFG Recovery

The primary obstacle disrupting the natural control flow graph is the use of instruction dispatchers. Eliminating these dispatchers is our first priority in obtaining the CFG. Afterward, we need to reorganize the scattered instructions back into their original function representations—a problem known as function identification, which is notoriously difficult to generalize. Therefore, we approach it using our specific knowledge about the obfuscator.

Linearizing the Scattered CFG

Our initial step in recovering the original CFG is to eliminate the scattering effect induced by instruction dispatchers. We will transform all dispatcher call instructions into direct branches to their resolved targets. This transformation linearizes the execution flow, making it straightforward to statically pursue the second phase of our CFG recovery. This will be implemented via brute-force scanning, static parsing, emulation, and instruction patching.

Function Identification and Recovery

We leverage a recursive descent algorithm that employs a depth-first search (DFS) strategy applied to known entry points of code, attempting to exhaust all code paths by “single-stepping” one instruction at a time. We add additional logic to the processing of each instruction in the form of “mutation rules” that stipulate how each individual instruction needs to be processed. These rules aid in stripping away the obfuscator’s code from the original.

Removing Instruction Dispatchers

Eliminating instruction dispatchers involves identifying each dispatcher location and its corresponding dispatch target. Recall that the target is a uniquely encoded 32-bit displacement located at the return address of the dispatcher call. To remove instruction dispatchers, it is essential to first understand how to accurately identify them. We begin by categorizing the defining properties of individual instruction dispatchers:

• Target of a Near Call
  • Dispatchers are always the destination of a near call instruction, represented by the E8 opcode followed by a 32-bit displacement.
• References Encoded 32-Bit Displacement at Return Address
  • Dispatchers reference the encoded 32-bit displacement located at the return address on the stack by performing a 32-bit read from the stack pointer. This displacement is essential for determining the next execution target.
• Pairing of pushfq and popfq Instructions to Safeguard Decoding
  • Dispatchers use a pair of pushfq and popfq instructions to preserve the state of the RFLAGS register during the decoding process. This ensures that the dispatcher does not alter the original execution context, maintaining the integrity of register contents.
• End with a ret Instruction
  • Each dispatcher concludes with a ret instruction, which not only ends the dispatcher function but also redirects control to the next set of instructions, effectively continuing the execution flow.

Leveraging the aforementioned categorizations, we implement the following approach to identify and remove instruction dispatchers:

1. Brute-Force Scanner for Near Call Locations

• Develop a scanner that searches for all near call instructions within the code section of the protected binary. This scanner generates a huge array of potential call locations that may serve as dispatchers.

• The brute-force scan yields a large number of false positives, requiring an efficient method to filter them. While emulation can filter out false positives, it is computationally expensive to do it for the brute-force results.

• Introduce a shallow fingerprinting routine that traverses the disassembly of each candidate to identify key dispatcher characteristics, such as the presence of pushfq and popfq sequences. This significantly improves performance by eliminating most false positives before concretely verifying them through emulation.

• Emulate execution starting from each verified call site to accurately recover the actual dispatch targets. Emulating from the call site ensures that the emulator processes the encoded offset data at the return address, abstracting away the specific decoding logic employed by each dispatcher.

• A successful emulation also serves as the final verification step to confirm that we have identified a dispatcher.

• Utilize the terminating ret instruction to accurately identify the dispatch target within the binary.

• The ret instruction is a definitive marker indicating the end of a dispatcher function and the point at which control is redirected, making it a reliable indicator for target identification.

Brute-Force Scanner

The following Python code implements the brute-force scanner, which performs a comprehensive byte signature scan within the code segment of a protected binary. The scanner systematically identifies all potential call instruction locations by scanning for the 0xE8 opcode associated with near call instructions. The identified addresses are then stored for subsequent analysis and verification.

Fingerprinting Dispatchers

The fingerprinting routine leverages the unique characteristics of instruction dispatchers, as detailed in the Instruction Dispatchers section, to statically identify potential dispatcher locations within a protected binary. This identification process utilizes the results from the prior brute-force scan. For each address in this array, the routine disassembles the code and examines the resulting disassembly listing to determine if it matches known dispatcher signatures.

This method is not intended to guarantee 100% accuracy, but rather serve as a cost-effective approach to identifying call locations with a high likelihood of being instruction dispatchers. Subsequent emulation will be employed to confirm these identifications.

1. Successful Decoding of a call Instruction

• The identified location must successfully decode to a call instruction. Dispatchers are always invoked via a call instruction. Additionally, dispatchers utilize the return address from the call site to locate their encoded 32-bit displacement.

• Dispatchers must not contain any call instructions within their disassembly listing. The presence of any call instructions within a presumed dispatcher range immediately disqualifies the call location as a dispatcher candidate.

• Similarly to call instructions, the dispatcher cannot include privileged instructions or indirect unconditional jmps. Any presence of any such instructions invalidates the call location.

• The dispatcher must contain pushfq and popfq instructions to safeguard the RFLAGS register during decoding. These sequences are unique to dispatchers and suffice for a generic identification without worrying about the differences that arise between how the decoding takes place.

Figure 23 is the fingerprint verification routine that incorporates all the aforementioned characteristics and validation checks given a potential call location:

Emulating Dispatchers to Resolve Destination Targets

After filtering potential dispatchers using the fingerprinting routine, the next step is to emulate them in order to recover their destination targets.

The Python code in Figure 24 performs this logic and operates as follows:

• Initialization of the Emulator
  • Creates the core engine for simulating execution (EmulateIntel64), maps the protected binary image (imgbuffer) into the emulator’s memory space, maps the Thread Environment Block (TEB) as well to simulate a realistic Windows execution environment, and creates an initial snapshot to facilitate fast resets before each emulation run without needing to reinitialize the entire emulator each time.
  • MAX_DISPATCHER_RANGE specifies the maximum number of instructions to emulate for each dispatcher. The value 45 is chosen arbitrarily, sufficient given the limited instruction count in dispatchers even with the added mutations.
  • A try/except block is used to handle any exceptions during emulation. It is assumed that exceptions result from false positives among the potential dispatchers identified earlier and can be safely ignored.
• Emulating Each Potential Dispatcher
  • For each potential dispatcher address (call_dispatch_ea), the emulator’s context is restored to the initial snapshot. The program counter (emu.pc) is set to the address of each dispatcher. emu.stepi() executes one instruction at the current program counter, after which the instruction is analyzed to determine whether we have finished.
    • If the instruction is a ret, the emulation has reached the dispatch point.
    • The dispatch target address is read from the stack using emu.parse_u64(emu.rsp).
  • The results are captured by d.dispatchers_to_target, which maps the dispatcher address to the dispatch target. The dispatcher address is additionally stored in the d.dispatcher_locs lookup cache.
    • The break statement exits the inner loop, proceeding to the next dispatcher.

Patching and Linearization

After collecting and verifying every captured instruction dispatcher, the final step is to replace each call location with a direct branch to its respective destination target. Since both near call and jmp instructions occupy 5 bytes in size, this replacement can be seamlessly performed by merely patching the jmp instruction over the call.

We utilize the dispatchers_to_target map, established in the previous section, which associates each dispatcher call location with its corresponding destination target. By iterating through this map, we identify each dispatcher call location and replace the original call instruction with a jmp. This substitution redirects the execution flow directly to the intended target addresses.

This removal is pivotal to our deobfuscation strategy as it removes the intended dynamic dispatch element that instruction dispatchers were designed to provide. Although the code is still scattered throughout the code segment, the execution flow is now statically deterministic, making it immediately apparent which instruction leads to the next one.

When we compare these results to the initial screenshot from the Instruction Dispatcher section, the blocks still appear scattered. However, their execution flow has been linearized. This progress allows us to move forward to the second phase of our CFG recovery.

Function Identification and Recovery

By eliminating the effects of instruction dispatchers, we have linearized the execution flow. The next step involves assimilating the dispersed code and leveraging the linearized control flow to reconstruct the original functions that comprised the unprotected binary. This recovery phase involves several stages, including raw instruction recovery, normalization, and the construction of the final CFG.

Function identification and recovery is encapsulated in the following two abstractions:

• Recovered instruction (RecoveredInstr): The fundamental unit for representing individual instructions recovered from an obfuscated binary. Each instance encapsulates not only the raw instruction data but also metadata essential for relocation, normalization, and analysis within the CFG recovery process.

• Recovered function (RecoveredFunc): The end result of successfully recovering an individual function from an obfuscated binary. It aggregates multiple RecoveredInstr instances, representing the sequence of instructions that constitute the unprotected function. The complete CFG recovery process results in an array of RecoveredFunc instances, each corresponding to a distinct function within the binary. We will utilize these results in the final Building Relocations in Deobfuscated Binaries section to produce fully deobfuscated binaries.

We do not utilize a basic block abstraction for our recovery approach given the following reasons. Properly abstracting basic blocks presupposes complete CFG recovery, which introduces unnecessary complexity and overhead for our purposes. Instead, it is simpler and more efficient to conceptualize a function as an aggregation of individual instructions rather than a collection of basic blocks in this particular deobfuscation context.

DFS Rule-Guided Stepping Introduction

We opted for a recursive-depth algorithm given the following reasons:

• Natural fit for code traversal: DFS allows us to infer function boundaries based solely on the flow of execution. It mirrors the way functions call other functions, making it intuitive to implement and reason about when reconstructing function boundaries. It also simplifies following the flow of loops and conditional branches.
• Guaranteed execution paths: We concentrate on code that is definitely executed. Given we have at least one known entry point into the obfuscated code, we know execution must pass through it in order to reach other parts of the code. While other parts of the code may be more indirectly invoked, this entry point serves as a foundational starting point.
  • By recursively exploring from this known entry, we will almost certainly encounter and identify virtually all code paths and functions during our traversal.
• Adapts to instruction mutations: We tailor the logic of the traversal with callbacks or “rules” that stipulate how we process each individual instruction. This helps us account for known instruction mutations and aids in stripping away the obfuscator’s code.

The core data structures involved in this process are the following: CFGResult, CFGStepState, and RuleHandler:

• CFGResult: Container for the results of the CFG recovery process. It aggregates all pertinent information required to represent the CFG of a function within the binary, which it primarily consumes from CFGStepState.
• CFGStepState: Maintains the state throughout the CFG recovery process, particularly during the controlled-step traversal. It encapsulates all necessary information to manage the traversal state, track progress, and store intermediate results.
  • Recovered cache: Stores instructions that have been recovered for a protected function without any additional cleanup or verification. This initial collection is essential for preserving the raw state of the instructions as they exist within the obfuscated binary before any normalization or validation processes are applied after. It is always the first pass of recovery.
  • Normalized cache: The final pass in the CFG recovery process. It transforms the raw instructions stored in the recovered cache into a fully normalized CFG by removing all obfuscator-introduced instructions and ensuring the creation of valid, coherent functions.
  • Exploration stack: Manages the set of instruction addresses that are pending exploration during the DFS traversal for a protected function. It determines the order in which instructions are processed and utilizes a visited set to ensure that each instruction is processed only once.
  • Obfuscator backbone: A mapping to preserve essential control flow links introduced by the obfuscator
• RuleHandler: Mutation rules are merely callbacks that adhere to a specific function signature and are invoked during each instruction step of the CFG recovery process. They take as input the current protected binary, CFGStepState, and the current step-in instruction. Each rule contains specific logic designed to detect particular types of instruction characteristics introduced by the obfuscator. Based on the detection of these characteristics, the rules determine how the traversal should proceed. For instance, a rule might decide to continue traversal, skip certain instructions, or halt the process based on the nature of the mutation.

The following figure is an example of a rule that is used to detect the patched instruction dispatchers we introduced in the previous section and differentiating them from standard jmp instructions:

DFS Rule-Guided Stepping Implementation

The remaining component is a routine that orchestrates the CFG recovery process for a given function address within the protected binary. It leverages the CFGStepState to manage the DFS traversal and applies mutation rules to decode and recover instructions systematically. The result will be an aggregate of RecoveredInstr instances that constitute the first pass of raw recovery:

The following Python code directly implements the algorithm outlined in Figure 33. It initializes the CFG stepping state and commences a DFS traversal starting from the function’s entry address. During each step of the traversal, the current instruction address is retrieved from the to_explore exploration stack and checked against the visited set to prevent redundant processing. The instruction at the current address is then decoded, and a series of mutation rules are applied to handle any obfuscator-induced instruction modifications. Based on the outcomes of these rules, the traversal may continue, skip certain instructions, or halt entirely.

Recovered instructions are appended to the recovered cache, and their corresponding mappings are updated within the CFGStepState. The to_explore stack is subsequently updated with the address of the next sequential instruction to ensure systematic traversal. This iterative process continues until all relevant instructions have been explored, culminating in a CFGResult that encapsulates the fully recovered CFG.

Normalizing the Flow

With the raw instructions successfully recovered, the next step is to normalize the control flow. While the raw recovery process ensures that all original instructions are captured, these instructions alone do not form a cohesive and orderly function. To achieve a streamlined control flow, we must filter and refine the recovered instructions—a process we refer to as normalization. This stage involves several key tasks:

• Updating branch targets: Once all of the obfuscator-introduced code (instruction dispatchers and mutations) are fully removed, all branch instructions must be redirected to their correct destinations. The scattering effect introduced by obfuscation often leaves branches pointing to unrelated code segments.

• Merging overlapping basic blocks: Contrary to the idea of a basic block as a strictly single-entry, single-exit structure, compilers can produce code in which one basic block begins within another. This overlapping of basic blocks commonly appears in loop structures. As a result, these overlaps must be resolved to ensure a coherent CFG.

• Proper function boundary instruction: Each function must begin and end at well-defined boundaries within the binary’s memory space. Correctly identifying and enforcing these boundaries is essential for accurate CFG representation and subsequent analysis.

Simplifying with Synthetic Boundary Jumps

Rather than relying on traditional basic block abstractions—which can impose unnecessary overhead—we employ synthetic boundary jumps to simplify CFG normalization. These artificial jmp instructions link otherwise disjointed instructions, allowing us to avoid splitting overlapping blocks and ensuring that each function concludes at a proper boundary instruction. This approach also streamlines our binary rewriting process when reconstructing the recovered functions into the final deobfuscated output binary.

Merging overlapping basic blocks and ensuring functions have proper boundary instructions amount to the same problem—determining which scattered instructions should be linked together. To illustrate this, we will examine how synthetic jumps effectively resolve this issue by ensuring that functions conclude with the correct boundary instructions. The exact same approach applies to merging basic blocks together.

Synthetic Boundary Jumps to Ensure Function Boundaries

Consider an example where we have successfully recovered a function using our DFS-based rule-guided approach. Inspecting the recovered instructions in the CFGState reveals a mov instruction as the final operation. If we were to reconstruct this function in memory as-is, the absence of a subsequent fallthrough instruction would compromise the function’s logic.

To address this, we introduce a synthetic jump whenever the last recovered instruction is not a natural function boundary (e.g., ret, jmp, int3).

We determine the fallthrough address, and if it points to an obfuscator-introduced instruction, we continue forward until reaching the first regular instruction. We call this traversal “walking the obfuscator’s backbone”:

We then link these points with a synthetic jump. The synthetic jump inherits the original address as metadata, effectively indicating which instruction it is logically connected to.

Updating Branch Targets

After normalizing the control flow, adjusting branch targets becomes a straightforward process. Each branch instruction in the recovered code may still point to obfuscator-introduced instructions rather than the intended destinations. By iterating through the normalized_flow cache (generated in the next section), we identify branching instructions and verify their targets using the walk_backbone routine. 

This ensures that all branch targets are redirected away from the obfuscator’s artifacts and correctly aligned with the intended execution paths. Notice we can ignore call instructions given that any non-dispatcher call instruction is guaranteed to always be legitimate and never part of the obfuscator’s protection. These will, however, need to be updated during the final relocation phase outlined in the Building Relocations in Deobfuscated Binaries section. 

Once recalculated, we reassemble and decode the instructions with updated displacements, preserving both correctness and consistency.

Putting It All Together

Putting it all together, we developed the following algorithm that builds upon the previously recovered instructions, ensuring that each instruction, branch, and block is properly connected, resulting in a completely recovered and deobfuscated CFG for an entire protected binary. We utilize the recovered cache to construct a new, normalized cache. The algorithm employs the following steps:

1. Iterate Over All Recovered Instructions

• Traverse all recovered instructions produced from our DFS-based stepping approach.

• For each instruction, add it to the normalized cache, which captures the results of the normalization pass.

• Determine whether the current instruction is a boundary instruction.

• If it is a boundary instruction, skip further processing of this instruction and continue to the next one (return to Step 1).

• Determine the expected fallthrough instruction by identifying the sequential instruction that follows the current one in memory.

• Compare the calculated fallthrough instruction with the next instruction in the recovered cache.

• If the fallthrough instruction is not the next sequential instruction in memory, check whether it’s a recovered instruction we already normalized:

• If it is, add a synthetic jump to link the two together in the normalized cache.

• If it is not, obtain the connecting fallthrough instruction from the recovery cache and append it to the normalized cache.

• Do nothing, as the recovered instruction already correctly points to the fallthrough. Proceed to Step 6.

• Check if the current instruction is the final instruction in the recovered cache.

• If it is the final instruction:

• Add a final synthetic boundary jump, because if we reach this stage, we failed the check in Step 3.

• Continue iteration, which will cause the loop to exit.

• Continue iteration as normal (return to Step 1).

The Python code in Figure 41 directly implements these normalization steps. It iterates over the recovered instructions and adds them to a normalized cache (normalized_flow), creates a linear mapping, and identifies where synthetic jumps are required. When a branch target points to obfuscator-injected code, it walks the backbone (walk_backbone) to find the next legitimate instruction. If the end of a function is reached without a natural boundary, a synthetic jump is created to maintain proper continuity. After the completion of the iteration, every branch target is updated (update_branch_targets), as illustrated in the previous section, to ensure that each instruction is correctly linked, resulting in a fully normalized CFG:

Observing the Results

After applying our two primary passes, we have nearly eliminated all of the protection mechanisms. Although import protection remains to be addressed, our approach effectively transforms an incomprehensible mess into a perfectly recovered CFG.

For example, Figure 42 and Figure 43 illustrate the before and after of a critical function within the backdoor payload, which is a component of its plugin manager system. Through additional analysis of the output, we can identify functionalities that would have been impossible to delineate, much less in such detail, without our deobfuscation process.

Import Recovery

Recovering and restoring the original import table revolves around identifying which import location is associated with which import dispatcher stub. From the stub dispatcher, we can parse the respective obf_imp_t reference in order to determine the protected import that it represents.

We pursue the following logic:

• Identify each valid call/jmp location associated to an import
  • The memory displacement for these will point to the respective dispatcher stub.
  • For HEADERLESS mode, we need to first resolve the fixup table to ensure the displacement points to a valid dispatcher stub.
• For each valid location traverse the dispatcher stub to extract the obf_imp_t
  • The obf_imp_t contains the RVAs to the encrypted DLL and API names.
• Implement the string decryption logic
  • We need to reimplement the decryption logic in order to recover the DLL and API names.
  • This was already done in the initial Import Protection section.

We encapsulate the recovery of imports with the following RecoveredImport data structure:

RecoveredImport serves as the result produced for each import that we recover. It contains all the relevant data that we will use to rebuild the original import table when producing the deobfuscated image.

Locate Protected Import CALL and JMP Sites

Each protected import location will be reflected as either an indirect near call (FF/2) or an indirect near jmp (FF/4):

Indirect near calls and jmps fall under the FF group opcode where the Reg field within the ModR/M byte identifies the specific operation for the group:

• /2: corresponds to CALL r/m64

• /4: corresponds to JMP r/m64

Taking an indirect near call as an example and breaking it down looks like the following:

1. FF: group opcode.

2. 15: ModR/M byte specifying CALL r/m64 with RIP-relative addressing.

• 15 is encoded in binary as 00010101

• Mod (bits 6-7):  00

• Indicates either a direct RIP-relative displacement or memory addressing with no displacement.

• Identifies the call operation for the group

• In 64-bit mode with Mod 00 and R/M 101, this indicates RIP-relative addressing.

To find each protected import location and their associated dispatcher stubs we implement a trivial brute force scanner that locates all potential indirect near call/jmps via their first two opcodes.

The provided code scans the code section of a protected binary to identify and record all locations with opcode patterns associated with indirect call and jmp instructions. This is the first step we take, upon which we apply additional verifications to guarantee it is a valid import site.

Resolving the Import Fixup Table

We have to resolve the fixup table when we recover imports for the HEADERLESS protection in order to identify which import location is associated with which dispatcher. The memory displacement at the protected import site will be paired with its resolved location inside the table. We use this displacement as a lookup into the table to find its resolved location.

Let’s take a jmp instruction to a particular import as an example.

The jmp instruction’s displacement references the memory location 0x63A88, which points to garbage data. When we inspect the entry for this import in the fixup table using the memory displacement, we can identify the location of the dispatcher stub associated with this import at 0x295E1. The loader will update the referenced data at 0x63A88 with 0x295E1, so that when the jmp instruction is invoked, execution is appropriately redirected to the dispatcher stub. 

Figure 48 is the deobfuscated code in the loader responsible for resolving the fixup table. We need to mimic this behavior in order to associate which import location targets which dispatcher.

$_Loop_Resolve_ImpFixupTbl:
 mov     ecx, [rdx+4]             ; fixup , either DLL, API, or ImpStub
 mov     eax, [rdx]               ; target ref loc that needs to be "fixed up"
 inc     ebp                      ; update the counter
 add     rcx, r13                 ; calculate fixup fully (r13 is imgbase)
 add     rdx, 8                   ; next pair entry
 mov     [r13+rax+0], rcx         ; update the target ref loc w/ full fixup
 movsxd  rax, dword ptr [rsi+18h] ; fetch imptbl total size, in bytes
 shr     rax, 3                   ; account for size as a pair-entry
 cmp     ebp, eax                 ; check if done processing all entries
 jl      $_Loop_Resolve_ImpTbl

Figure 48: Deobfuscated disassembly of the algorithm used to resolve the import fixup table

Resolving the import fixup table requires us to have first identified the data section within the protected binary and the metadata that identifies the import table (IMPTBL_OFFSET, IMPTBL_SIZE). The offset to the fixup table is from the start of the data section.

Having the start of the fixup table, we simply iterate one entry at a time and identify which import displacement (location) is associated with which dispatcher stub (fixup).

Recovering the Import

Having obtained all potential import locations from the brute-force scan and accounted for relocations in HEADERLESS mode, we can proceed with the final verifications to recover each protected import. The recovery process is conducted as follows:

1. Decode the location into a valid call or jmp instruction
   • Any failure in decoding indicates that the location does not contain a valid instruction and can be safely ignored.
2. Use the memory displacement to locate the stub for the import
   • In HEADERLESS mode, each displacement serves as a lookup key into the fixup table for the respective dispatcher.
3. Extract the obf_imp_t structure within the dispatcher
   • This is achieved by statically traversing a dispatcher’s disassembly listing.
   • The first lea instruction encountered will contain the reference to the obf_imp_t.
4. Process the obf_imp_t to decrypt both the DLL and API names
   • Utilize the two RVAs contained within the structure to locate the encrypted blobs for the DLL and API names.
   • Decrypt the blobs using the outlined import decryption routine.

The Python code iterates through every potential import location (potential_stubs) and attempts to decode each presumed call or jmp instruction to an import. A try/except block is employed to handle any failures, such as instruction decoding errors or other exceptions that may arise. The assumption is that any error invalidates our understanding of the recovery process and can be safely ignored. In the full code, these errors are logged and tracked for further analysis should they arise.

Next, the code invokes a GET_STUB_DISPLACEMENT helper function that obtains the RVA to the dispatcher associated with the import. Depending on the mode of protection, one of the following routines is used:

The recover_import_stub function is utilized to reconstruct the control flow graph (CFG) of the import stub, while _extract_lea_ref examines the instructions in the CFG to locate the lea reference to the obf_imp_t. The GET_DLL_API_NAMES function operates similarly to GET_STUB_DISPLACEMENT, accounting for slight differences depending on the protection mode:

After obtaining the decrypted DLL and API names, the code possesses all the necessary information to reveal the import that the protection conceals. The final individual output of each import entry is captured in a RecoveredImport object and two dictionaries:

• d.imports
  • This dictionary maps the address of each protected import to its recovered state. It allows for the association of the complete recovery details with the specific location in the binary where the import occurs.
• d.imp_dict_builder
  • This dictionary maps each DLL name to a set of its corresponding API names. It is used to reconstruct the import table, ensuring a unique set of DLLs and the APIs utilized by the binary.

This systematic collection and organization prepare the necessary data to facilitate the restoration of the original functionality in the deobfuscated output. In Figure 53 and Figure 54, we can observe these two containers to showcase their structure after a successful recovery:

Observing the Final Results

This final step—rebuilding the import table using this data—is performed by the build_import_table function in the pefile_utils.py source file. This part is omitted from the blog post due to its unavoidable length and the numerous tedious steps involved. However, the code is well-commented and structured to thoroughly address and showcase all aspects necessary for reconstructing the import table.

Nonetheless, the following figure illustrates how we generate a fully functional binary from a headerless-protected input. Recall that a headerless-protected input is a raw, headerless PE binary, almost analogous to a shellcode blob. From this blob we produce an entirely new, functioning binary with the entirety of its import protection completely restored. And we can do the same for all protection modes.

Building Relocations in Deobfuscated Binaries

Now that we can fully recover the CFG of protected binaries and provide complete restoration of the original import tables, the final phase of the deobfuscator involves merging these elements to produce a functional deobfuscated binary. The code responsible for this process is encapsulated within the recover_output64.py and the pefile_utils.py Python files.

The rebuild process comprises two primary steps:

1. Building the Output Image Template

2. Building Relocations

1. Building the Output Image Template

Creating an output image template is essential for generating the deobfuscated binary. This involves two key tasks:

• Template PE Image: A Portable Executable (PE) template that serves as the container for the output binary that incorporates the restoration of all obfuscated components. We also need to be cognizant of all the different characteristics between in-memory PE executables and on-file PE executables.

• Handling Different Protection Modes: Different protection modes and input stipulate different requirements.

• Headerless variants have their file headers stripped. We must account for these variations to accurately reconstruct a functioning binary.

• Selective protection preserves the original imports to maintain functionality as well as includes a specific import protection for all the imports leveraged within the selected functions. 

2. Building Relocations

Building relocations is a critical and intricate part of the deobfuscation process. This step ensures that all address references within the deobfuscated binary are correctly adjusted to maintain functionality. It generally revolves around the following two phases:

• Calculating Relocatable Displacements: Identifying all memory references within the binary that require relocation. This involves calculating the new addresses where these references will point to. The technique we will use is generating a lookup table that maps original memory references to their new relocatable addresses.

• Apply Fixups: Modifies the binary’s code to reflect the new relocatable addresses. This utilizes the aforementioned lookup table to apply necessary fixups to all instruction displacements that reference memory. This ensures that all memory references within the binary correctly point to their intended locations.

We intentionally omit the details of showcasing the rebuilding of the output binary image because, while essential to the deobfuscation process, it is straightforward enough and just overly tedious to be worthwhile examining in any depth. Instead, we focus exclusively on relocations, as they are more nuanced and reveal important characteristics that are not as apparent but must be understood when rewriting binaries.

Overview of the Relocation Process

Rebuilding relocations is a critical step in restoring a deobfuscated binary to an executable state. This process involves adjusting memory references within the code so that all references point to the correct locations after the code has been moved or modified. On the x86-64 architecture, this primarily concerns instructions that use RIP-relative addressing, a mode where memory references are relative to the instruction pointer.

Relocation is necessary when the layout of a binary changes, such as when code is inserted, removed, or shifted during deobfuscation. Given our deobfuscation approach extracts the original instructions from the obfuscator, we are required to relocate each recovered instruction appropriately into a new code segment. This ensures that the deobfuscated state preserves the validity of all memory references and that the accuracy of the original control and data flow is sustained.

Understanding Instruction Relocation

Instruction relocation revolves around the following:

• Instruction’s memory address: the location in memory where an instruction resides.
• Instruction’s memory memory references: references to memory locations used by the instruction’s operands.

Consider the following two instructions as illustrations:

1. Unconditional jmp instructionThis instruction is located at memory address 0x1000. It references its branch target at address 0x4E22. The displacement encoded within the instruction is 0x3E1D, which is used to calculate the branch target relative to the instruction’s position. Since it employs RIP-relative addressing, the destination is calculated by adding the displacement to the length of the instruction and its memory address.

2. lea instructionThis is the branch target for the jmp instruction located at 0x4E22. It also contains a memory reference to the data segment, with an encoded displacement of 0x157.

When relocating these instructions, we must address both of the following aspects:

• Changing the instruction’s address: When we move an instruction to a new memory location during the relocation process, we inherently change its memory address. For example, if we relocate this instruction from 0x1000 to 0x2000, the instruction’s address becomes 0x2000.

• Adjusting memory displacements: The displacement within the instruction (0x3E1D for the jmp, 0x157 for the lea) is calculated based on the instruction’s original location and the location of its reference. If the instruction moves, the displacement no longer points to the correct target address. Therefore, we must recalculate the displacement to reflect the instruction’s new position.

When relocating instructions during the deobfuscation process, we must ensure accurate control flow and data access. This requires us to adjust both the instruction’s memory address and any displacements that reference other memory locations. Failing to update these values invalidates the recovered CFG.

What Is RIP-Relative Addressing?

RIP-relative addressing is a mode where the instruction references memory at an offset relative to the RIP (instruction pointer) register, which points to the next instruction to be executed. Instead of using absolute addresses, the instruction encapsulates the referenced address via a signed 32-bit displacement from the current instruction pointer.

Addressing relative to the instruction pointer exists on x86 as well, but only for control-transfer instructions that support a relative displacement (e.g., JCC conditional instructions, near CALLs, and near JMPs). The x64 ISA extended this to account for almost all memory references being RIP-relative. For example, most data references in x64 Windows binaries are RIP-relative.

An excellent tool to visualize the intricacies of a decoded Intel x64 instruction is ZydisInfo. Here we use it to illustrate how a LEA instruction (encoded as 488D151B510600) references RIP-relative memory at 0x6511b.

For most instructions, the displacement is encoded in the final four bytes of the instruction. When an immediate value is stored at a memory location, the immediate follows the displacement. Immediate values are restricted to a maximum of 32 bits, meaning 64-bit immediates cannot be used following a displacement. However, 8-bit and 16-bit immediate values are supported within this encoding scheme.

Displacements for control-transfer instructions are encoded as immediate operands, with the RIP register implicitly acting as the base. This is evident when decoding a jnz instruction, where the displacement is directly embedded within the instruction and calculated relative to the current RIP.

Steps in the Relocation Process

For rebuilding relocations we take the following approach:

1. Rebuilding the code section and creating a relocation mapWith the recovered CFG and imports, we commit the changes to a new code section that contains the fully deobfuscated code. We do this by:

• Function-by-function processing: rebuild each function one at a time. This allows us to manage the relocation of each instruction within its respective function.

• Tracking instruction locations: As we rebuild each function, we track the new memory locations of each instruction. This involves maintaining a global relocation dictionary that maps original instruction addresses to their new addresses in the deobfuscated binary. This dictionary is crucial for accurately updating references during the fixup phase.

Rebuilding the Code Section and Creating a Relocation Map

To construct the new deobfuscated code segment, we iterate over each recovered function and copy all instructions sequentially, starting from a fixed offset—for example, 0x1000. During this process, we build a global relocation dictionary (global_relocs) that maps each instruction to its relocated address. This mapping is essential for adjusting memory references during the fixup phase.

The global_relocs dictionary uses a tuple as the key for lookups, and each key is associated with the relocated address of the instruction it represents. The tuple consists of the following three components:

1. Original starting address of the function: The address where the function begins in the protected binary. It identifies the function to which the instruction belongs.

2. Original instruction address within the function: The address of the instruction in the protected binary. For the first instruction in a function, this will be the function’s starting address.

3. Synthetic boundary JMP flag: A boolean value indicating whether the instruction is a synthetic boundary jump introduced during normalization. These synthetic instructions were not present in the original obfuscated binary, and we need to account for them specifically during relocation because they have no original address.

The following Python code implements the logic outlined in Figure 61. Error handling and logging code has been stripped for brevity.

1. Initialize current offset
   Set the starting point in the new image buffer where the code section will be placed. The variable curr_off is initialized to starting_off, which is typically 0x1000. This represents the conventional start address of the .text section in PE files. For SELECTIVE mode, this will be the offset to the start of the protected function.
2. Iterate over recovered functions
   Loop through each recovered function in the deobfuscated control flow graph (d.cfg). func_ea is the original function entry address, and rfn is a RecoveredFunc object encapsulating the recovered function’s instructions and metadata.
   1. Handle the function start address first

      1. Set function’s relocated start address: Assign the current offset to rfn.reloc_ea, marking where this function will begin in the new image buffer.

      2. Update global relocation map: Add an entry to the global relocation map d.global_relocs to map the original function address to its new location.
   2. Iterate over each recovered instruction
      Loop through the normalized flow of instructions within the function. We use the normalized_flow as it allows us to iterate over each instruction linearly as we apply it to the new image.
      1. Set instruction’s relocated address: Assign the current offset to r.reloc_ea, indicating where this instruction will reside in the new image buffer.
      2. Update global relocation map: Add an entry to d.global_relocs for the instruction, mapping its original address to the relocated address.
      3. Update the output image: Write the instruction bytes to the new image buffer d.newimgbuffer at the current offset. If the instruction was modified during deobfuscation (r.updated_bytes), use those bytes; otherwise, use the original bytes (r.instr.bytes).
      4. Advance the offset: Increment curr_off by the size of the instruction to point to the next free position in the buffer and move on to the next instruction until the remainder are exhausted.
3. Align current offset to 16-byte boundaryAfter processing all instructions in a function, align curr_off to the next 16-byte boundary. We use 8 bytes as an arbitrary pointer-sized value from the last instruction to pad so that the next function won’t conflict with the last instruction of the previous function. This further ensures proper memory alignment for the next function, which is essential for performance and correctness on x86-64 architectures. Then repeat the process from step 2 until all functions have been exhausted.

This step-by-step process accurately rebuilds the deobfuscated binary’s executable code section. By relocating each instruction, the code prepares the output template for the subsequent fixup phase, where references are adjusted to point to their correct locations.

Applying Fixups

After building the deobfuscated code section and relocating each recovered function in full, we apply fixups to correct addresses within the recovered code. This process adjusts the instruction bytes in the new output image so that all references point to the correct locations. It is the final step in reconstructing a functional deobfuscated binary.

We categorize fixups into three distinct categories, based primarily on whether they apply to control flow or data flow instructions. We further distinguish between two types of control flow instructions: standard branching instructions and those introduced by the obfuscator through the import protection. Each type has specific nuances that require tailored handling, allowing us to apply precise logic to each category.

1. Import Relocations: These involve calls and jumps to recovered imports.

2. Control Flow Relocations: All standard control flow branching branching instructions.

3. Data Flow Relocations: Instructions that reference static memory locations.

Using these three categorizations, the core logic boils down to the following two phases:

1. Resolving displacement fixups
   • Differentiate between displacements encoded as immediate operands (branching instructions) and those in memory operands (data accesses and import calls).
   • Calculate the correct fixup values for these displacements using the d.global_relocs map generated prior.
2. Update the output image buffer
   • Once the displacements have been resolved, write the updated instruction bytes into the new code segment to reflect the changes permanently.

To achieve this, we utilize several helper functions and lambda expressions. The following is a step-by-step explanation of the code responsible for calculating the fixups and updating the instruction bytes.

• Define lambda helper expressions
  • PACK_FIXUP: packs a 32-bit fixup value into a little-endian byte array.
  • CALC_FIXUP: calculates the fixup value by computing the difference between the destination address (dest) and the end of the current instruction (r.reloc_ea + size), ensuring it fits within 32 bits.
  • IS_IN_DATA: checks if a given address is within the data section of the binary. We exclude relocating these addresses, as we preserve the data section at its original location.
• Resolve fixups for each instruction
  • Import and data flow relocations
    • Utilize the resolve_disp_fixup_and_apply helper function as both encode the displacement within a memory operand.
  • Control flow relocations
    • Use the resolve_imm_fixup_and_apply helper as the displacement is encoded in an immediate operand.
    • During our CFG recovery, we transformed each jmp and jcc instruction to its near jump equivalent (from 2 bytes to 6 bytes) to avoid the shortcomings of 1-byte short branches.
      • We force a 32-bit displacement for each branch to guarantee a sufficient range for every fixup.
• Update the output image buffer
  • Decode the updated instruction bytes to have it reflect within the RecoveredInstr that represents it.
  • Write the updated bytes to the new image buffer
    • updated_bytes reflects the final opcodes for a fully relocated instruction.

With the helpers in place, the following Python code implements the final processing for each relocation type.

• Import Relocations: The first for loop handles fixups for import relocations, utilizing data generated during the Import Recovery phase. It iterates over every recovered instruction r within the rfn.relocs_imports cache and does the following:
  • Prepare updated instruction bytes: initialize r.updated_bytes with a mutable copy of the original instruction bytes to prepare it for modification.
  • Retrieve import entry and displacement: obtain the import entry from the imports dictionary d.imports and retrieve the new RVA from d.import_to_rva_map using the import’s API name.
  • Apply fixup: use the resolve_disp_fixup_and_apply helper to calculate and apply the fixup for the new RVA. This adjusts the instruction’s displacement to correctly reference the imported function.
  • Update image buffer: write r.updated_bytes back into the new image using update_reloc_in_img. This finalizes the fixup for the instruction in the output image.
• Control Flow Relocations: The second for loop handles fixups for control flow branching relocations (call, jmp, jcc). Iterating over each entry in rfn.relocs_ctrlflow, it does the following:
  • Retrieve destination: extract the original branch destination target from the immediate operand.
  • Get relocated address: reference the relocation dictionary d.global_relocs to obtain the branch target’s relocated address. If it’s a call target, then we specifically look up the relocated address for the start of the called function.
  • Apply fixup: use resolve_imm_fixup_and_apply to adjust the branch target to its relocated address.
  • Update buffer: finalize the fixup by writing r.updated_bytes back into the new image using update_reloc_in_img.
• Data Flow Relocations: The final loop handles the resolution of all static memory references stored within rfn.relocs_dataflow. First, we establish a list of KNOWN instructions that require data reference relocations. Given the extensive variety of such instructions, this categorization simplifies our approach and ensures a comprehensive understanding of all possible instructions present in the protected binaries. Following this, the logic mirrors that of the import and control flow relocations, systematically processing each relevant instruction to accurately adjust their memory references. 

After reconstructing the code section and establishing the relocation map, we proceeded to adjust each instruction categorized for relocation within the deobfuscated binary. This was the final step in restoring the output binary’s full functionality, as it ensures that each instruction accurately references the intended code or data segments.

Observing the Results

To demonstrate our deobfuscation library for ScatterBrain, we conduct a test study showcasing its functionality. For this test study, we select three samples: a POISONPLUG.SHADOW headerless backdoor and two embedded plugins.

We develop a Python script, example_deobfuscator.py, that consumes from our library and implements all of the recovery techniques outlined earlier. Figure 65 and Figure 66 showcase the code within our example deobfuscator:

Running example_deobfuscator.py we can see the following. Note, it takes a bit given we have to emulate more than 16,000 instruction dispatchers that were found within the headerless backdoor.

Focusing on the headerless backdoor both for brevity and also because it is the most involved in deobfuscating, we first observe its initial state inside the IDA Pro disassembler before we inspect the output results from our deobfuscator. We can see that it is virtually impenetrable to analysis.

After running our example deobfuscator and producing a brand new deobfuscated binary, we can see the drastic difference in output. All the original control flow has been recovered, all of the protected imports have been restored, and all required relocations have been applied. We also account for the deliberately removed PE header of the headerless backdoor that ScatterBrain removes.

Given we produce functional binaries as part of the output, the subsequent deobfuscated binary can be either run directly or debugged within your favorite debugger of choice.

Conclusion

In this blog post, we delved into the sophisticated ScatterBrain obfuscator used by POISONPLUG.SHADOW, an advanced modular backdoor leveraged by specific China-nexus threat actors GTIG has been tracking since 2022. Our exploration of ScatterBrain highlighted the intricate challenges it poses for defenders. By systematically outlining and addressing each protection mechanism, we demonstrated the significant effort required to create an effective deobfuscation solution.

Ultimately, we hope that our work provides valuable insights and practical tools for analysts and cybersecurity professionals. Our dedication to advancing methodologies and fostering collaborative innovation ensures that we remain at the forefront of combating sophisticated threats like POISONPLUG.SHADOW. Through this exhaustive examination and the introduction of our deobfuscator, we contribute to the ongoing efforts to mitigate the risks posed by highly obfuscated malware, reinforcing the resilience of cybersecurity defenses against evolving adversarial tactics.

Indicators of Compromise

A Google Threat Intelligence Collection featuring indicators of compromise (IOCs) related to the activity described in this post is now available.

Host-Based IOCs

Acknowledgements

Special thanks to Conor Quigley and Luke Jenkins from the Google Threat Intelligence Group for their contributions to both Mandiant and Google’s efforts in understanding and combating the POISONPLUG threat. We also appreciate the ongoing support and dedication of the teams at Google, whose combined efforts have been crucial in enhancing our cybersecurity defenses against sophisticated adversaries.

Google Kubernetes Engine (GKE) provides users with a lot of options when it comes to configuring their cluster networks. But with today’s highly dynamic environments, GKE platform operators tell us that they want more flexibility when it comes to changing up their configurations. To help, today we are excited to announce a set of features and capabilities designed to make GKE cluster and control-plane networking more flexible and easier to configure. 

Specifically, we’ve decoupled GKE control-plane access from node-pool IP configuration, providing you with granular control over each aspect. Furthermore, we’ve introduced enhancements to each sub-component, including:

• Cluster control-plane access

• Added a DNS-based approach to accessing the control plane. In addition, you can now enable or disable IP-based or DNS-based access to control-plane endpoints at any time. 

• With IP-based access control, you can now lock down the private IP endpoint to selected RFC-1918 addresses (via authorized networks) for both VPC Peering-based and Private Service Connect-based clusters.

• Each node-pool now has its own configuration, and you can now detach or attach a public IP for each node-pool independently at any time during the node-pool’s lifecycle.

• You can now change a cluster’s default configuration of attaching a public IP on the newly provisioned node pools at any time. This configuration change doesn’t require you to re-create your cluster.

Regardless of how you configure a cluster’s control-plane access, or attach and detach a public IP from a node pool, the traffic between nodes to the cluster’s control plane always remains private, no matter what.

With these new changes, going forward:

1. GKE platform admins and operators can now easily switch between less restrictive networking configurations (e.g., control plane and/or nodes accessible from the internet) and the most restrictive configurations, where only authorized users can access the control plane, and nodes are not exposed to the internet. The decision to make a cluster public or private is no longer immutable, giving customers more flexibility without having to make upfront decisions.

2. There are more ways to connect to the GKE control plane. In addition to IP-based access, we now introduce DNS-based access to the control plane. You can use IAM and authentication-based policies to add policy-based, dynamic security to access the GKE control plane.

Previous challenges

Due to the complexities and varieties of customers’ workloads and use cases, it is important to provide a simple and flexible way for customers to configure and operate the connectivity to GKE control plane and GKE nodes.

Control-plane connectivity and node-pool configuration are a key part of configuring GKE. We’ve continuously enhanced GKE’s networking capabilities to address customer concerns, providing more options for secure and flexible connectivity, including capabilities such as private clusters, VPC Peering-based connectivity, Private Service Connect-based connectivity, and private/public node pools.

While there have been a lot of improvements in configuration, usability and secure connectivity, there were still certain configuration challenges when it comes to complexity, usability and scale, such as:

• Inflexible GKE control plane and node access configuration: GKE customers need to make an upfront one-way decision whether to create a private or public cluster during the cluster creation process. This configuration could not be changed unless the cluster is re-created. 

• The node pool network IP/ type configuration could not be changed once a cluster was created. 

• Confusing terms such as Public / Private clusters, creating confusion as to whether the configuration is for control-plane access or node-pool configuration.

Benefits of the new features

With these changes to GKE networking, we hope you will see benefits in the following areas.

Flexibility:

• Clusters now have unified and flexible configuration. Clusters with or without external endpoints all share the same architecture and support the same functionality. You can secure access to clusters based on controls and best practices that meet your needs. All communication between the nodes in your cluster and the control plane use a private internal IP address.

• You can change the control plane access and cluster node configuration settings at any time without having to re-create the cluster.

Security:

• DNS-based endpoints with VPC Service Controls provide a multi-layer security model that protects your cluster against unauthorized networks as well as from unauthorized identities accessing the control plane. VPC Service Controls integrate with Cloud Audit Logs to monitor access to the control plane.

• Private nodes and the workloads running on them are not directly accessible from the public internet, significantly reducing the potential for external attacks targeting your workloads.

• You can block control plane access from Google Cloud external IP addresses or from external IP addresses to fully isolate the cluster control plane and reduce exposure to potential security threats.

Compliance: If you work in an industry with strict data-access and storage regulations, private nodes help ensure that sensitive data remains within your private network.

Control: Private nodes give you granular control over how traffic flows in and out of your cluster. You can configure firewall rules and network policies to allow only authorized communication. If you operate across a multi-cloud environment, private nodes can help you establish secure and controlled communication between different environments.

Getting started

Accessing the cluster control plane

There are now several ways to access a cluster’s control plane: via traditional public or private IP-based endpoints, and the new DNS-based endpoint. Whereas IP-based endpoints entail tedious IP address configuration (including static authorized network configuration, allowing private accessing from any regions, etc.), DNS-based endpoints offer a simplified, IAM policy-based, dynamic, flexible and more secure way to access a cluster’s control plane.

With these changes, you can now configure the cluster’s control plane to be reachable by all three endpoints (DNS-based, public or private IP-based) at same time, locking the cluster down to the granularity of a single endpoint in any permutation that you would like. You can apply your desired configuration at cluster creation time or adjust it later.

Examples:

Enable DNS-based endpoint only (preferable):

Enable access over all three endpoints:

Enable access over the DNS-based endpoint and Private IP with restricted access from small ranges of RFC1918 address :

Node-pools

Here’s how to configure access for GKE node-pools.

GKE Standard Mode:
In GKE Standard mode of operation, a private IP is always attached to every node no matter what. This private IP is used for private connectivity to the cluster’s control plane.

You can add or remove a public IP to all nodes in a node-pool at node-pool creation time. This configuration can be performed on each node-pool independently.

You can also add or remove a public IP after the node-pool has been created:

Each cluster has a default behavior flag that’s used at node-pool creation time if the flag is not explicitly set beforehand during node-pool creation time.

Note: Mutating a cluster’s default state does not change behavior of existing node pools. The new state is used only when a new node-pool is being created.

GKE Autopilot mode of operation:
All workloads running on nodes with or without a public IP are based on the cluster’s default behavior. You can override the cluster’s default behavior on each workload independently by adding the following nodeSelector to your Pod specification:

However, overriding a cluster’s default behavior causes all workloads for which behavior hasn’t been explicitly set to be rescheduled), to run on nodes that match the cluster’s default behavior.

Conclusion

Given the complexity and variety of workloads that run on GKE, it’s important to have a simple and flexible way to configure and operate the connectivity to the GKE control plane and nodes. We hope these enhancements to GKE control-plane connectivity and node-pool configuration will bring new levels of flexibility and simplicity to GKE operations. For further details and documentation, please see:

• Cluster isolation concepts

• Cluster isolation how-to

More and more customers deploy their workloads on Google Cloud. But what if your workloads are sitting in another cloud? Planning, designing, and implementing a migration of your workloads, data, and processes is not an easy task. It gets even harder if you have to meet requirements that have an impact on the migration, such as avoiding downtime (also known as a zero-downtime migration). Moreover, some migrations require a certain amount of refactoring, for example, adapting your workloads to a new environment. This opens up a series of challenges, especially if you’re dealing with third-party or legacy software. You might also need to adapt your deployment and operational processes to work with your new environment.

And what if you don’t want to migrate all your workloads? Even if you’re not moving everything to Google Cloud, adopting a multicloud approach is still a migration. Many organizations choose to keep some workloads in their current cloud provider while moving others to Google Cloud. 

Although managing workloads across multiple clouds has its own challenges, particularly when it comes to workload distribution and inter-cloud connectivity, a well-executed multicloud strategy lets you maintain flexibility, avoid vendor lock-in, and improve system resilience.

To help you in your migration journey, we published a series of reference guides about migrating from Amazon Web Services (AWS) to Google Cloud. This series aims to help you design, plan, and implement a migration process from AWS to Google Cloud. It can also help decision makers who are evaluating migration opportunities and want to explore what it looks like to migrate. For example, the series includes guides that cover migration journeys, such as:

From AWS compute services to Google Cloud

• Migrate from Amazon EC2 to Compute Engine

• Migrate VMware VMs to your Google Cloud VMware Engine private cloud

• Migrate from Amazon Elastic Kubernetes Service (Amazon EKS) to Google Kubernetes Engine

• Migrate from AWS Lambda to Cloud Run

From AWS data storage services to Google Cloud

• Migrate from Amazon S3 to Cloud Storage

From AWS database services to Google Cloud

• Migrate from Amazon RDS and Amazon Aurora for MySQL to Cloud SQL for MySQL

• Migrate from Amazon RDS and Amazon Aurora for PostgreSQL to Cloud SQL for PostgreSQL and AlloyDB for PostgreSQL

• Migrate from Amazon RDS for SQL Server to Cloud SQL for SQL Server

From AWS data analytics services to Google Cloud

• Migrate from Amazon RedShift to BigQuery

From AWS integration services to Google Cloud

• Migrate from AWS Step Functions to Workflows

These guides follow the phases of the Google Cloud migration framework (assess, plan, migrate, optimize) in the context of specific AWS to Google Cloud migration use cases.

This approach helps to avoid big-bang, risky migrations, when working on each migration plan task. For details about completing each task of this migration plan, see the AWS to Google Cloud migration guides. 

What’s next

• Learn how to get started with your migration from AWS to Google Cloud today!

• In case you need any help, Google Cloud offers several resources to help you migrate your workloads, data, and processes at scale.

• Need a more visual guide? Download our new migration guide & checklist. 

Ready to get started?

Ready to learn more? Learn more about migrating to Google Cloud and discover how Google Cloud Consulting can help you learn, build, operate and succeed.

^{Acknowledgements: Alex Cârciu, Cloud Solutions Architect, Xiang Shen, Cloud Solutions Architect}

Organizations are increasingly using Confidential Computing to help protect their sensitive data in use as part of their data protection efforts. Today, we are excited to highlight new Confidential Computing capabilities that make it easier for organizations of all sizes to adopt this important privacy-preserving technology.

1. Confidential GKE Nodes on the general-purpose C3D machine series for GKE Standard mode, generally available 

Confidential GKE Nodes enforce data encryption in-use in your Google Kubernetes Engine (GKE) nodes and workloads. Confidential GKE Nodes are built on top of Compute Engine Confidential VMs using AMD Secure Encryption Virtualization (AMD SEV), which encrypts the memory contents of VMs in-use. 

Previously, Confidential GKE Nodes were only available on two machine series powered by the 2nd and 3rd Gen AMD EPYC™ processors: the general-purpose N2D machine series and the compute-optimized C2D machine series. Today, Confidential GKE Nodes are also generally available on the newer, more performant C3D machine series with AMD SEV in GKE Standard mode. 

The general-purpose C3D machine series is powered by 4th Gen AMD EPYC™ (Genoa) processors to deliver optimal, reliable, and consistent performance. Customers often use Confidential GKE Nodes to address potential concerns about cloud provider risk, especially since no code changes are required to enable it.

2. Confidential GKE Nodes on GKE Autopilot mode, generally available

Google Kubernetes Engine (GKE) offers two modes of operation: Standard and Autopilot. In Standard mode, you manage the underlying infrastructure, including configuring the individual nodes. In Autopilot mode, GKE manages the underlying infrastructure such as node configuration, autoscaling, auto-upgrades, baseline security configurations, and baseline networking configuration. 

Previously, Confidential GKE Nodes were only offered on GKE Standard mode. Today, Confidential GKE Nodes are generally available on GKE Autopilot mode with the general purpose N2D machine series running with AMD Secure Encryption Virtualization (AMD SEV). This means that you can now use Confidential GKE Nodes to protect your data in use without having to manage the underlying infrastructure. 

Confidential GKE Nodes can be enabled on new GKE Autopilot clusters with no code changes. Simply add the command --enable-confidential-nodes during new cluster creation. Additional pricing does apply and this new offering is available in all regions that offer the N2D machine series. Go here to get started today.

3. Confidential Space with Intel TDX-based Confidential VMs, in preview 

Confidential Space allows multiple parties to securely collaborate on computations using their combined data without revealing their individual datasets to each other or to the operator enabling this collaboration. This is achieved by isolating data within a Trusted Execution Environment (TEE). 

We are seeing adoption and need for these capabilities that are putting sensitive data to use in a private and compliant manner in financial services, Web3, and other industries.

Confidential Space is built on Confidential VMs. Previously, Confidential Space was only available on Confidential VMs with AMD Secure Encryption Virtualization (AMD SEV) enabled. Today, Confidential Space is also available on Confidential VMs with Intel Trust Domain Extensions (Intel TDX) enabled in preview. 

Confidential Space with Intel TDX enabled offers data confidentiality, data integrity, and hardware-rooted attestation, further enhancing security. Confidential Space with Intel TDX runs on the general purpose C3 machine series, which are powered by 4th Gen Intel Xeon Scalable CPUs. 

These performant C3 VMs also have Intel Advanced Matrix Extensions (Intel AMX), a new built-in accelerator that helps improve the performance of deep-learning training and inference on the CPU, on by default. Confidential Space supporting the additional confidential computing type provides users greater flexibility in selecting the right CPU platform based on performance, cost, and security requirements. Learn more about Confidential Space or check out this new Youtube video about Intel TDX.

4. Confidential VMs with NVIDIA H100 GPUs, in preview

We expanded our capabilities for secure computation last year when we unveiled Confidential VMs on the accelerator-optimized A3 machine series with NVIDIA H100 GPUs. This offering extends hardware-based data protection from the CPU to GPUs, helping to ensure the confidentiality and integrity of artificial intelligence (AI), machine learning (ML), and scientific simulation workloads leveraging GPUs can be protected while data is in use. 

Today, these confidential GPUs are available in preview. Confidential VMs on the A3 machine series protects data and code in use, so that means sensitive training data or data labels, proprietary models or model weights, and top secret queries remain protected even during compute-intensive operations, like training, fine tuning, or serving. 

This groundbreaking technology combines the power of Confidential Computing and accelerated computing to enable customers to harness the potential of AI while helping to maintain high levels of data security and IP protection, which can open new possibilities for innovation in regulated industries and collaborative AI development. 

You can sign up here to try Confidential VMs with NVIDIA H100 GPUs. To learn more, check out our previous announcements on this offering here and here.

What’s coming in 2025

Google Cloud is committed to expanding Confidential Computing to more products and services because we want customers to have easy access to the latest in security innovation. Whether that’s adding Confidential Computing support to newer hardware or on accelerators or to services like GKE Autopilot, we aim to provide our customers with a comprehensive set of Confidential Computing solutions. 

Confidential Computing is an essential technology for protecting sensitive data in the cloud, and we look forward to innovating with you in this space. You can explore the Confidential Computing products here.