ScatterBrain: Unmasking the Shadow of PoisonPlug's Obfuscator
Written by: Nino Isakovic
IntroductionSince 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.
OverviewIn 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 IntroductionScatterBrain 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 OperationA 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.
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:ExitProcessFigure 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 0C1hFigure 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
CompleteThe 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 HeaderlessThis 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
-
Metadata is protected via hash-like integrity checks.
-
The metadata is utilized by the loader as part of its initialization sequence.
-
Import protection will require relocation adjustments.
-
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.
Figure 4: Deobfuscated loader entry
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.
Figure 5: Memory scan to identify the loader's metadata inside the .data section
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
Figure 6: Loader's metadata
Core Protection Components Instruction DispatcherThe 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.
Figure 7: Illustration of the control flow instruction dispatchers induce
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.
Figure 8: Example of an instruction dispatcher and all of its components
The core logic for any dispatcher can be categorized into the following four phases:
- 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.
- 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.
- 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.
- 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:
Figure 9: Instruction dispatcher template
Opaque PredicatesScatterBrain 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 OPThis 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_46806Figure 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:
Sequence
Condition Description
test <reg>, 0; jo
OF is always cleared
test <reg>, 0; jnae/jc/jb
CF is always cleared
test <reg>, 0; js
Resulting value will always be zero; therefore, SF can never be set
test <reg>, 0; jnp/jpo
The number of bits in zero is always zero, which is an even number; therefore, PF can never be set
test <reg>, 0; jne/jnz
Resulting value will always be zero; therefore, ZF will always be set
Table 1: Test opaque predicate understanding
jcc OPThe 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_4C227Figure 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 OPThe 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_180009FDAFigure 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 ProtectionThe 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.
Figure 13: Illustration of all the components involved in the import protection
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
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 importFigure 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 raxFigure 15: Obfuscated import dispatcher stub
Resolver Logicobf_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:
Figure 17: Fully decompiled import resolver routine
Import Encryption LogicThe 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:
Xn + 1 = (a • Xn + c) mod 232
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
-
mod 232 confines the sequence values to a 32-bit range
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.
Figure 18: Complete Python implementation of the import string decryption routine
Import Fixup TableThe 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
Figure 19: Illustration of the import fixup table
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.
Figure 20: Loader metadata that shows the Import fixup table entries and metadata used to find it
RecoveryEffective 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:
-
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
-
Import Recovery
-
Original Import Table: The goal is to reconstruct the original import table, ensuring that all necessary library and function references are accurately restored.
-
Binary Rewriting
-
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.pyFigure 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 RecoveryThe 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 DispatchersEliminating 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:
-
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.
-
Implementation of a Fingerprint Routine
-
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.
-
Emulation of Targets to Recover Destinations
-
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.
-
Identification of Dispatch Targets via ret Instructions
-
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.
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.
Figure 22: Python implementation of the brute-force scanner
Fingerprinting DispatchersThe 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.
-
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.
-
Absence of Subsequent call Instructions
-
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.
-
Absence of Privileged Instructions and Indirect Control Transfers
-
Similarly to call instructions, the dispatcher cannot include privileged instructions or indirect unconditional jmps. Any presence of any such instructions invalidates the call location.
-
Detection of pushfq and popfq Guard Sequences
-
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:
Figure 23: The dispatch fingerprint routine
Emulating Dispatchers to Resolve Destination TargetsAfter filtering potential dispatchers using the fingerprinting routine, the next step is to emulate them in order to recover their destination targets.
Figure 24: Emulation sequence used to recover dispatcher 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.
- 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.
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.
Figure 25: Patching sequence to transform instruction dispatcher calls to unconditional jmps to their destination targets
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.
Figure 26: Linearized instruction dispatcher control flow
Function Identification and RecoveryBy 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.
Figure 27: RecoveredInstr type definition
Figure 28: RecoveredFunc type definition
DFS Rule-Guided Stepping IntroductionWe 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.
Figure 29: CFGResult type definition
Figure 30: CFGStepState type definition
Figure 31: RuleHandler type definition
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:
Figure 32: RuleHandler example that identifies patched instruction dispatchers and differentiates them from standard jmp instructions
DFS Rule-Guided Stepping ImplementationThe 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:
Figure 33: Flow chart of our DFS rule-guided stepping algorithm
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.
Figure 34: DFS rule-guided stepping algorithm Python implementation
Normalizing the FlowWith 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.
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 BoundariesConsider 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.
Figure 35: Example of a raw recovery that does not end with a natural function boundary instruction
To address this, we introduce a synthetic jump whenever the last recovered instruction is not a natural function boundary (e.g., ret, jmp, int3).
Figure 36: Simple Python routine that identifies function boundary instructions
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":
Figure 37: Python routine that implements walking the obfuscator's backbone logic
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.
Figure 38: Example of adding a synthetic boundary jmp to create a natural function boundary
Updating Branch TargetsAfter 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.
Figure 39: Python routine responsible for updating all branch targets
Putting It All TogetherPutting 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:
-
Iterate Over All Recovered Instructions
-
Traverse all recovered instructions produced from our DFS-based stepping approach.
-
Add Instruction to Normalized Cache
-
For each instruction, add it to the normalized cache, which captures the results of the normalization pass.
-
Identify Boundary Instructions
-
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).
-
Calculate Expected Fallthrough Instruction
-
Determine the expected fallthrough instruction by identifying the sequential instruction that follows the current one in memory.
-
Verify Fallthrough Instruction
-
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.
-
If the fallthrough instruction matches the next instruction in the recovered cache:
-
Do nothing, as the recovered instruction already correctly points to the fallthrough. Proceed to Step 6.
-
Handle Final Instruction
-
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.
-
If it is not the final instruction:
-
Continue iteration as normal (return to Step 1).
Figure 40: Flow chart of our normalization algorithm
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:
Figure 41: Python implementation of our normalization algorithm
Observing the ResultsAfter 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.
Figure 42: Original obfuscated shadow::PluginProtocolCreateAndConfigure routine
Figure 43: Completely deobfuscated and functional shadow::PluginProtocolCreateAndConfigure routine
Import RecoveryRecovering 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:
Figure 44: RecoveredImport type definition
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 SitesEach protected import location will be reflected as either an indirect near call (FF/2) or an indirect near jmp (FF/4):
Figure 45: Disassembly of import calls and jmps representation
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:
-
FF: group opcode.
-
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.
-
Reg (bits 3-5): 010
-
Identifies the call operation for the group
-
R/M (bits 0-2): 101
-
In 64-bit mode with Mod 00 and R/M 101, this indicates RIP-relative addressing.
-
<32-bit displacement>: added to RIP to compute the absolute address.
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.
Figure 46: Brute-force scanner to locate all possible import locations
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 TableWe 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.
Figure 47: Example of a jmp import instruction including its entry in the import fixup table and the associated dispatcher stub
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_ImpTblFigure 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.
Figure 49: Python re-implementation of the algorithm used to resolve the import fixup table
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 ImportHaving 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:
- 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.
- 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.
- 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.
- 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.
Figure 50: Loop that recovers each protected import
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:
Figure 51: Routines that retrieve the stub RVA based on the protection mode
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:
Figure 52: Routines that decrypt the DLL and API blobs based 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:
Figure 53: Output of the d.imports dictionary after a successful recovery
Figure 54: Output of the d.imp_dict_builder dictionary after a successful recovery
Observing the Final ResultsThis 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.
Figure 55: Display of completely restored import table for a binary protected in HEADERLESS mode
Building Relocations in Deobfuscated BinariesNow 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:
-
Building the Output Image Template
-
Building Relocations
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.
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 ProcessRebuilding 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 RelocationInstruction 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:
Figure 56: Illustration of two instructions that require relocation
-
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.
-
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.
Figure 57: Updated illustration demonstration of what relocation would look like
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.
Figure 58: ZydisInfo output for the lea instruction
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.
Figure 59: ZydisInfo output for the mov instruction storing an immediate operand
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.
Figure 60: ZydisInfo output for the jnz instruction with an immediate operand as the displacement
Steps in the Relocation ProcessFor rebuilding relocations we take the following approach:
-
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.
-
Applying fixupsAfter rebuilding the code section and establishing the relocation map, we proceed to modify the instructions so that their memory references point to the correct locations in the deobfuscated binary. This restores the binary's complete functionality and is achieved by adjusting memory references to code or data an instruction may have.
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:
-
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.
-
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.
-
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.
Figure 61: Illustration of how the new code segment and relocation map are generated
The following Python code implements the logic outlined in Figure 61. Error handling and logging code has been stripped for brevity.
Figure 62: Python logic that implements the building of the code segment and generation of the relocation map
- 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. - 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.- Handle the function start address first
-
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.
- 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.
-
- 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.- Set instruction's relocated address: Assign the current offset to r.reloc_ea, indicating where this instruction will reside in the new image buffer.
- Update global relocation map: Add an entry to d.global_relocs for the instruction, mapping its original address to the relocated address.
- 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).
- 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.
- Handle the function start address first
- 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 FixupsAfter 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.
-
Import Relocations: These involve calls and jumps to recovered imports.
-
Control Flow Relocations: All standard control flow branching branching instructions.
-
Data Flow Relocations: Instructions that reference static memory locations.
Using these three categorizations, the core logic boils down to the following two phases:
- 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.
- 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.
Figure 63: Helper routines that aid in applying fixups
- 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.
- Import and data flow relocations
- 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.
Figure 64: The three core loops that address each relocation category
- 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 ResultsTo 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:
Figure 65: The first half of the Python code in example_deobfuscator.py
Figure 66: The second half of the Python code in example_deobfuscator.py
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.
Figure 67: The three core loops that address each relocation category
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.
Figure 68: Observing the obfuscated headerless backdoor in IDA Pro
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.
Figure 69: Observing the deobfuscated headerless backdoor in IDA Pro
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.
Figure 70: Debugging the deobfuscated headerless backdoor in everyone’s favorite debugger
ConclusionIn 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 CompromiseA Google Threat Intelligence Collection featuring indicators of compromise (IOCs) related to the activity described in this post is now available.
Host-Based IOCsMD5
Associated Malware Family
5C62CDF97B2CAA60448619E36A5EB0B6
POISONPLUG.SHADOW
0009F4B9972660EEB23FF3A9DCCD8D86
POISONPLUG.SHADOW
EB42EF53761B118EFBC75C4D70906FE4
POISONPLUG.SHADOW
4BF608E852CB279E61136A895A6912A9
POISONPLUG.SHADOW
1F1361A67CE4396C3B9DBC198207EF52
POISONPLUG.SHADOW
79313BE39679F84F4FCB151A3394B8B3
POISONPLUG.SHADOW
704FB67DFFE4D1DCE8F22E56096893BE
POISONPLUG.SHADOW
AcknowledgementsSpecial 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.