Design of x86 Emulator for Generic Unpacking

Chandra Prakash Sunbelt Software, USA chandrap@sunbelt-software.com Abstract CPU emulation techniques have been leveraged for various objectives. These include supporting re-targetable applications, controlled execution of un-trusted applications, dynamic behavioral analysis of malware and packed malware detection via generic unpacking. Generic unpacking via emulation obviates the need for writing custom detections for each packer and its variants and provides the ability to detect a broad class of packed malware. The malware is allowed to run in the emulators virtual environment until one of many stop conditions are reached, when the dynamic virtual memory state of the unpacked malware can be examined. This paper presents a general architecture of the emulator for x86 platforms intended for packed malware detection via generic unpacking. It describes layout and interplay of various structural components that comprise this architecture. Specifically, the structural components include: CPU, PE loader, virtual memory manager, heap, stack, process, process environment block (PEB), thread, thread information block (TIB), structured exception handling (SEH), interrupt handling, function hooks for spoofing execution references into system dll(s). It also describes several unique characteristics exhibited by packed malware and the challenges imposed by them that ultimately shape the overall design of the emulator. Acknowledgements I would like to extend special thanks to my team members at Sunbelt: Eric Sites, Casey Sheehan, Nick Suan and Tom Robinson, for their valuable support in my contribution towards understanding the emulator. 1. Introduction CPU emulation has been used over the years for a multitude of objectives. It allows an application compiled for a specific target platform to be run on a host platform with a completely different or overlapping architecture set. There are different levels at which emulation can be implemented; full and application only. Full emulation involves emulating a large part of the hardware, e.g., VirtualPC and VMWare. Application-only emulation deals with emulating application level instruction set and the system call interface. An example of an emulating system call interface is FreeBSDs ability to run Linux i386 binaries. Another example is Wow64 (Win32 emulation on 64 bit Windows). Over the past two decades, malware has evolved with consumer-based operating systems and applications. The main techniques for detecting malware have

been mostly signature-based. This is true today to a large extent. Packed malware defeats the traditional signature-based detection schemes by encrypting the malware code. But packed malware can be detected by writing custom packing routines and techniques such as X-ray. X-ray [3] involves finding the decryption key(s) using a function that describes a relationship between the encrypted code, decrypted code and the decryptor code itself. These methods perform very well if the number of packers is limited and they do not have recursive layers of packing. These methods can very quickly become quite un-manageable since there are a fairly large number of packers and each one has many variations. As an example, the most prevalent packer, UPX, has numerous versions (1.x to 3.x). FSG has versions in the range of 1.x to 2.x. Generic unpacking helps solve the above issues. The malware is allowed to execute in a controlled and secure environment until one of many stop conditions are reached. Once the execution has stopped, the virtual memory state of the malware can be examined for signatures or heuristics. This paper discusses the design of an application-only x86 emulator 1 that implements a generic unpacking solution.

Section 2 describes the major components of the emulator. Section 3 presents examples of a few sample malware characteristics that shape its overall design. In Section 4, we discuss efficiency optimizations of the emulator, e.g. dynamic binary translation. 2. Emulator Components The emulator consists of a software implementation of the subset of hardware, operating system and application environment needed for running an application. The hardware components include the CPU, registers and interrupt vector table. The operating system components include the PE loader, virtual memory manager, structured exception handling (SEH). The application environment includes input parameter and environmental variable support, heap, stack, process environment block (PEB), thread information block (TIB), function hooks for spoofing execution references into system dll(s). The structural relationship among these components is shown in the class diagram of figure 1. 2.1. PE Loader

The PE loader [11] creates a ready-torun memory-mapped image of the target executable. The memory-mapped image is created according to the Windows PE specifications [14]. In general terms the loading process consists of following steps: a. Calculating virtual mapped size of the image based on the size of PE

Unless stated otherwise, in the remaining part of this paper, emulator will refer to x86 application only emulator for Windows NT family of operating systems in regard to generic unpacking. Also, all OS specific structures are taken from Windows XP-SP2.

b.

c.

d.

e.

headers and sum of virtual sizes of all the sections. Allocating a contiguous buffer based on virtual mapped size of the target image calculated in step a. Copying PE headers and sections at appropriate locations in the virtual mapped buffer. Section boundaries should be aligned as per the section alignment field in the optional header. Each section may have its own protection (see section 2.5) characteristics, e.g., read, write, execute etc., as indicated by the section header. Fixing up the import address table (IAT) [13] of the primary module. In this step the virtual address of imported symbols in the primary module are resolved from exports of the dependent modules [11]. The dependent modules need not be explicitly loaded like the primary module. Only a list of exported symbols from dependent modules with their name (or ordinal) and address mapping need to be maintained. Fixing up the relocations in the primary module.

environment and at the very least it is desirable to support instructions that use these registers. It is an added benefit to provide support for FPU instructions and extensions to x86 architecture, such as MMX, SSE, SSE2, SSE3[10] and 3DNow! instructions. 2.3. CPU

Typically the task of the emulator CPU can be summarized in the following steps: a. Fetch instruction as pointed by EIP. b. Decode the instruction and (depending on the instruction) fetch all needed operands. The operands can be fetched from some other register or may require a fetch from the virtual memory address in the address space of the target image. c. Once all operands are obtained, a function is executed corresponding to the instruction type and results obtained for it. d. Store the results at the location specified by the output operands. e. Increment the EIP to point to the beginning of next instruction. If the previous instruction was a branch instruction it may set EIP to some other location on its own. These steps are repeated until one of many stop conditions are reached (see Section 2.12). At the onset of execution, just after the primary module is successfully loaded, EIP is set to the entry point of the module. 2.4. Interrupt Handling

Once the primary module is loaded successfully, its entry point is earmarked for later execution. 2.2. Registers

These represent an abstraction of the real CPU registers. There are eight 32-bit general purpose registers (EAX, EBX, ECX, EDX, EBP, ESP, ESI, EDI), six 16-bit segment registers (CS, SS, DS, ES, FS, GS), hardware debug registers DR0-DR3, DR6, DR7, as well as EFLAGS and EIP registers. These registers provide the basic execution

From user mode, Windows allows only a subset of interrupt instructions to be executed.

2.5. Execution of disallowed interrupt instructions from user mode results in generation of access violation exceptions. Table 1 summarizes the behavior that was noted for INT N instructions on XP-SP2, when called from a user mode application. N is the interrupt number ranging from 0-255. The interrupt vector table in a usermode-application-only emulator generates the corresponding exception in the application

2.5.

Virtual Memory Manager

The virtual memory [15] manager maintains descriptors for various memory regions used by

SEHHandler System +initiailize() +loadPEImage() +createProcess()

X86CPU +fetch() +executeOneInstruction() HookList +addHook() +findHook() 1 1 Process

struct X86Registers

MemoryManager +readByte() +writeByte() +virtualAlloc() +virtualFree() +virtualProtect()

struct PEB_LDR_DATA

PELoader +run() +parseImage() +loadImage() * MemoryRegion -base -size +readByte() +writeByte() Heap 1 +heapCreate() +heapDestroy() * * MemoryBlockDescriptor 1 -allocationType -protectionType -startPage -pageCount +readByte() +writeByte() +generateAccessViolationException() 1

structPEB 1 1 1

Thread

1 1 structTIB

* Stack -top -bottom +resize()

Figure 1

the target module. A memory region consists of contiguous list of pages. Each page can have its allocation (committed, reserved, free) or protection (read, write, execute etc.) characteristics. A reserved memory region consists of a contiguous sequence of pages for which physical memory has not been committed. A memory region reserved initially can be committed later by the application or it can be reserved and committed simultaneously in the very first VirtualAlloc call. Any memory reference in the primary or a dependent module, heap, stack and dynamic virtual memory related calls (e.g., VirtualAlloc, VirtualFree) during targets execution results in a corresponding descriptor lookup in the memory manager. The descriptor list is maintained in a fast lookup data structure. If the memory reference is not compatible with the allocation type and protection assigned to the region, an access violation exception is generated. Interrupt Number (N) 3, 2d 4 2a, 2b, 2c, 2e All others Exception thrown Breakpoint Integer Overflow None 2 Exception Violation

2.6.

SEH Handling

Structured Exception Handling (SEH) handling [12] is most commonly used to obfuscate execution path by much malware. Usually an exception handler is registered first containing code for unpacking the stub and then an exception is deliberately generated. In some cases, once the unpacking stub gets control, it may further register a new exception handler and throw a nested exception and so forth. The commonly used exceptions are generated by single step (INT1) and break point (INT3) instructions, arithmetic divide or integer overflow exceptions that are generated by DIV/IDIV instructions or INTO instruction. 2.7. Stack

The stack is a contiguous memory region that serves among other things as a memory work area for parameters passed in function calls and SEH chain. There is one stack for each thread. They are implemented in an inverted manner so they grow in the direction of decreasing memory address. The stack parameters, (e.g., base, limit, address of top level exception handler frame) should be appropriately set in TIB (see section 2.9). 2.8. Heap

Table 1

This behavior is seen when no other registers are configured before the interrupt instruction is executed. For example, INT 2E is used by system calls, where EAX contains system call number and EDX contains parameter(s) address in the stack. This was not done in the tests for results in Table 1.

The heap enables efficient memory allocations of much lower granularity as opposed to page granular allocations of VirtualAlloc call. To support Win32 heap-related calls made by the target (e.g., HeapAlloc, HeapFree, etc.), a simulation must be provided. The heap is implemented as a wrapper around page granular memory allocation calls.

2.9.

Thread Information Block

the sort key is denoted by respective list name. 2.11. Function Hooks

For each thread there is a thread information block (TIB) structure stored at the address indicated by FS:[18h] in each thread. The layout of TIB is shown in structure A.S1 in Appendix A. The first field ExceptionList in the TIB contains the address of the top level exception handler frame represented by EXCEPTION_REGISTRATION_RECOR D structure. This address also can be obtained from the value of expression FS:[0]. StackBase and StackLimit, which contains the lower bound and upper bound of the threads stack. Once the address of TIB is obtained, the address of the process environment block can be obtained at offset 30h from the beginning of TIB. 2.10. Process Environment Block

Since there is no kernel component in the application-only emulator, any system call made by malware in a dependent system module like kernel32.dll is intercepted and its corresponding spoofed implementation provided. Some of the functions include: LoadLibraryA/W, GetProcAddresss, GetModuleHandleA/W, VirtualAlloc, VirtualFree, HeapAlloc, HeapFree and GetVersionExA/W. Also a default unemulated function hook should also be provided that gets called when an unimplemented import function is encountered. 2.12. Stop Conditions

For each user mode process there is one process environment block (PEB). The layout of PEB is shown below in structure A.S3 in Appendix A. Some of the important fields accessed by malware are: BeingDebugged, ImageBaseAddress, InLoadOrderModuleList, InMemoryOrderModuleList and InInitializationOrderModuleList of PEB_LDR_DATA. The IsDebuggerPresent Win32 API simply returns value in BeingDebugged field of PEB. This is used by malware to detect a debuggers presence as one of the anti-debugging tricks (see Example 3.7). The sorted list of modules is maintained in three different LIST_ENTRY type data structures where

The ideal condition to stop a targets emulation is when it is finished unpacking and is about to execute the original entry point (OEP). But, developing a generic solution to determine exactly when OEP is reached is not a trivial task. In most cases the emulation is stopped when an unemulated function call in a dependent system module is encountered. The emulator can stop the targets execution for various reasons. Typical conditions other than the target-initiated explicit termination are described below: a. Encountering an un-emulated system call in a dependent module. b. Encountering an unhandled exception for which no SEH handler was found. Some of these exceptions include invalid memory read, write,

c. d. e. f. g. h.

execute, divide by zero or integer overflow. Encountering an un-emulated or illegal instruction. Reaching configured timeout. Reaching the maximum number of instructions. Encountering an attempt to load a dll that could not be located. The target loading too many dlls in an explicit load module. Encountering a very large nested call depth of the SEH call chain.

Example 3.1 0041C25A CALL 0041C25F 0041C25F PUSH EBP 0041C260 MOV EBX,DWORD PTR SS:[ESP+8] 0041C264 MOV EBP,DWORD PTR SS:[ESP+4] 0041C268 SUB DWORD PTR SS:[ESP+4],1A4AF Example 3.1 shows a snippet of code near entry point 0041C25A of a piece of malware when the program has just started. At address 0041C260, the MOV instruction references an address ([ESP+8]) at the top of initial stack. This address is the return address after the CALL instruction in kernel32.dll that calls the malware entry point. The return address actually ends up calling ExitProcess. Hence, it is desirable to mimic the Windows program initial stack values. For an executable, initial stack values are set in the first fifteen stack locations starting from the bottom of the stack. Example 3.2 004A1584 MOV EBX,DWORD PTR SS:[ESP+24] ; EBX=77E8141A 004A1588 AND EBX,FFE00000 ; EBX=77E00000 . . 004A16C4 ADD EBX,10000 004A16CA JE SHORT 004A16F7 004A16CC CMP WORD PTR DS:[EBX],5A4D 004A16D1 JNZ SHORT 004A16C4 Example 3.2 shows a scenario where malware follows an execution path using the alignment of load address of a dependent system module (kernel32.dll).

3. Malware with unique characteristics An ideal emulator would be the one that implements every detail of the supported platform to near perfection so that malware behavior is correctly captured. But practical constraints due to performance optimizations and undocumented features would allow only limited implementation of the emulator. As a result, once the core emulator system is ready, developing a robust emulator is an iterative process driven by minor fine tuning for unique characteristics of supported packers and symptoms exhibited by the malware testbed. Below are some of the cases experienced with malware samples that led to the improvement of our emulator. The cases described in these examples are not complete and are just a small sample of the possible ways that malware can exhibit execution flow that affects the emulator.

At 004A16C4 EBX value is incremented by system allocation granularity. At 004A16CC it compares the content of the value located at the address in EBX with WORD type 5A4D (ascii MZ), which is the startup marker for a PE image. If the address of the startup marker is found in the address pointed by EBX, execution follows to location 004A16C4. Example 3.3 31428200 PUSH ED01C390 31428205 MOV EAX,ESP 31428207 CALL EAX 0012FFC0 NOP 0012FFC1 RETN 31428209 XCHG EAX,EBX ; EAX=7FFDF000, EBX=0012FFC0 3142820A POP EBX Example 3.3 shows code starting at the entry point of the program at the onset of program execution, which demonstrates use of initial value in the registers. At 31428209 EBX is referenced whose value is equal to the PEB address of the program. Initial value of other general purpose and segment registers should be set similarly to the way as they are set in Windows. Example 3.4 For the correct emulation of a dll, before the entry point function DllMain gets called, its input parameters must be set in the stack as in Windows. These input parameters include a module handle (base address), reason for call and a reserved parameter as below. BOOL WINAPI DllMain( HINSTANCE hinstDLL, DWORD fdwReason,

LPVOID lpvReserved ); Example 3.5 0048C075 MOV EAX, 0048C093 0048C07A PUSH EBP 0048C07B PUSH EAX 0048C07C PUSH DWORD PTR FS:[0] 0048C082 MOV DWORD PTR FS:[0],ESP 0048C088 MOV EBP,4243484B 0048C08D MOV EAX,4 0048C092 INT3 0048C093 CMP AL,4 0048C095 JNZ SHORT 0048C09B 0048C097 NOP 0048C098 NOP 0048C099 RETN Example 3.5 shows a case of setting the proper values of registers just before a SEH handler is executed. Instruction sequence range 0048C075-0048C082 set up a new SEH handler to 0048C093. When the exception is generated due to INT3 instruction, the SEH handlers second instruction at 0048C095 has a conditional jump instruction depending on whether AL is zero or not. It is seen in real Windows, EAX is set to zero just before SEH handler gets control. Therefore, just before the SEH handler gets control, other registers should be set up as they are set in Windows. Example 3.6 004141EF SUB EDX,EDX 004141F1 MOV EAX,DWORD PTR FS:[EDX] 004141F4 MOV ESP,DWORD PTR DS:[EAX] 004141F6 POP DWORD PTR FS:[EDX] 004141F9 POP EAX

004141FA POP EBP 004141FB RETN Example 3.6 shows an exception handler as another case of use of Windows SEH to exhibit a twisted execution flow. At 00414F4 it skips over the top level SEH handler and positions ESP to the SEH frame for this handler. This is possible because when the application handler gets control after an exception, Windows also registers another handler on top before application handler gets control. At 004141F6 the two top SEH handlers are torn down and after 00414FB execution resumes at location specified by ESP, that was last updated at 00414DFA. Actually, in this case before the SEH handler was invoked by Windows, the malware had already configured a return address on the stack that gets executed after RETN at 004141FB. Example 3.7 3142821B MOV EAX, DWORD PTR FS:[18] 31428220 MOV EAX, DWORD PTR DS:[EAX+30] 31428223 MOVZX EAX, BYTE PTR DS:[EAX+2] 31428227 CMP EAX, 0 3142822A JNZ SHORT 3142826E 3142822C CALL 31428231 31428231 POP EBP Example 3.7 shows a case where the malware is checking for the presence of a debugger. At 3142821B the address of TIB is obtained and used to get the address of PEB at 31428220. At 31428223 BeingDebugged field of PEB (structure A.S3 in Appendix A) is

checked to evaluate the condition of the branch instruction at 3142822A. Example 3.8 0044D0A5 MOV EAX,DWORD PTR FS:[30] 0044D0AB TEST EAX,EAX 0044D0AD JS SHORT 0044D0BB 0044D0AF MOV EAX,DWORD PTR DS:[EAX+C] 0044D0B2 MOV ESI,DWORD PTR DS:[EAX+1C] 0044D0B5 LODS DWORD PTR DS:[ESI] Example 3.8 shows a case where PEB is referenced at 0044DA05. At 0044D0AF, 0044D0B2 and 0044D0B5, PEB_LDR_DATA, InInitializationOrderModuleList and InInitializationOrderModuleList.Flink respectively are referenced. The malware happens to be referencing the kernel32.dll load information in its dependent module list sorted on initialization order. Example 3.9 004033FA MOV EAX,DWORD PTR DS:[4503D4] 00403400 TEST CL,CL 00403402 JNZ SHORT 0040341A 00403404 MOV EDX,DWORD PTR FS:[2C] 0040340B MOV EAX,DWORD PTR DS:[EDX+EAX*4] 0040340E RETN Example 3.9 shows a case of use of Thread Local Storage(TLS) in a malware. At 00403404 the beginning of the thread local storage pointer array value in FS:[2Ch] is copied over in EDX. The next instruction at 0040340B

returns in EAX value of a TLS pointer as indexed by previous value in EAX.

4. Conclusion The prevalent use of emulation based technologies by present AV security vendors speaks for itself about its relevance and merit. Plain emulation is hundreds of times slower [3] than native execution speeds and may not suffice when large numbers of packed malware samples, each with several hundred millions of instructions need to be processed. Dynamic binary translation [3][5][6][16] provides very good speed efficiency improvements over plain emulation by translating frequent loops in the target into harmless instructions and executing them at native speed. The code to be translated is partitioned into a sequence of basic blocks. There is a performance hit at the time of translation, but the translation is done only once and for subsequent execution of the same block, the translated instructions are used. It is estimated that dynamic binary translation is only about ten times slower [16] than native execution. There are also implementations of pagefault-handler-based unpacking systems where all memory writes from a packed program are monitored from kernel until an execute is issued in the modified monitored memory regions [9]. The page-fault-handler-based unpacking system yields maximum speed improvements since the malware is allowed to run natively on the host machine and in that sense does not require any kind of emulation. But, its implementation is discouraged since it requires un-conventional ways of modifying the page fault interrupt handler in the kernel and may not even work on 64-bit Vista because of patch guard protection.

Example 3.10 All Win32 PE executables are expected to follow the PE format specifications[14] in the strictest sense. Yet, it is seen that many malware samples do not conform to these formal guidelines and are still allowed to run by the Windows loader.

Structure Dos Header Optional Header Optional Header Optional Header Section Header

Field e_lfanew SizeOfCode SizeOfInitiali zedData AddressOfEnt ryPoint PointerToRaw Data

Value 0x10 0x4c454e 52 0x442e3 233 0x11a4 0x10

Table 2.

Table 2 shows an example of an interesting case of values in the PE header of a malware sample, which is loaded with no complaints by Windows loader. The file header that starts after the PE signature indicated by offset e_lfanew, begins right in the middle of DOS header. SizeOfCode and SizeOfInitializedData values are completely random and PointerToRawData offset for a section also begins right where file header starts! In general a piece of malware should be loaded by the emulator as long as the Windows loader accepts it by relaxing constraints on these kinds of aberrations.

10

Appendix A
+0x000 ExceptionList : Ptr32 _EXCEPTION_REGISTRATION_RECORD +0x004 StackBase : Ptr32 Void +0x008 StackLimit : Ptr32 Void +0x00c SubSystemTib : Ptr32 Void +0x010 FiberData : Ptr32 Void +0x010 Version : Uint4B +0x014 ArbitraryUserPointer : Ptr32 Void +0x018 Self : Ptr32 _NT_TIB

Structure A.S1. NT_TIB

+0x000 Next +0x004 Handler : Ptr32 _EXCEPTION_REGISTRATION_RECORD : Ptr32

Structure A.S2. EXCEPTION_REGISTRATION_RECORD

+0x000 InheritedAddressSpace : UChar +0x001 ReadImageFileExecOptions : UChar +0x002 BeingDebugged : UChar +0x003 SpareBool : UChar +0x004 Mutant : Ptr32 Void +0x008 ImageBaseAddress : Ptr32 Void +0x00c Ldr : Ptr32 _PEB_LDR_DATA +0x010 ProcessParameters : Ptr32 _RTL_USER_PROCESS_PARAMETERS +0x014 SubSystemData : Ptr32 Void +0x018 ProcessHeap : Ptr32 Void +0x01c FastPebLock : Ptr32 _RTL_CRITICAL_SECTION +0x020 FastPebLockRoutine : Ptr32 Void +0x024 FastPebUnlockRoutine : Ptr32 Void +0x028 EnvironmentUpdateCount : Uint4B +0x02c KernelCallbackTable : Ptr32 Void +0x030 SystemReserved : [1] Uint4B +0x034 ExecuteOptions : Pos 0, 2 Bits +0x034 SpareBits : Pos 2, 30 Bits +0x038 FreeList : Ptr32 _PEB_FREE_BLOCK +0x03c TlsExpansionCounter : Uint4B +0x040 TlsBitmap : Ptr32 Void +0x044 TlsBitmapBits : [2] Uint4B +0x04c ReadOnlySharedMemoryBase : Ptr32 Void +0x050 ReadOnlySharedMemoryHeap : Ptr32 Void +0x054 ReadOnlyStaticServerData : Ptr32 Ptr32 Void +0x058 AnsiCodePageData : Ptr32 Void +0x05c OemCodePageData : Ptr32 Void +0x060 UnicodeCaseTableData : Ptr32 Void +0x064 NumberOfProcessors : Uint4B +0x068 NtGlobalFlag : Uint4B +0x070 CriticalSectionTimeout : _LARGE_INTEGER +0x078 HeapSegmentReserve : Uint4B +0x07c HeapSegmentCommit : Uint4B +0x080 HeapDeCommitTotalFreeThreshold : Uint4B +0x084 HeapDeCommitFreeBlockThreshold : Uint4B +0x088 NumberOfHeaps : Uint4B +0x08c MaximumNumberOfHeaps : Uint4B +0x090 ProcessHeaps : Ptr32 Ptr32 Void +0x094 GdiSharedHandleTable : Ptr32 Void +0x098 ProcessStarterHelper : Ptr32 Void +0x09c GdiDCAttributeList : Uint4B +0x0a0 LoaderLock : Ptr32 Void +0x0a4 OSMajorVersion : Uint4B +0x0a8 OSMinorVersion : Uint4B +0x0ac OSBuildNumber : Uint2B +0x0ae OSCSDVersion : Uint2B +0x0b0 OSPlatformId : Uint4B

11

+0x0b4 ImageSubsystem : Uint4B +0x0b8 ImageSubsystemMajorVersion : Uint4B +0x0bc ImageSubsystemMinorVersion : Uint4B +0x0c0 ImageProcessAffinityMask : Uint4B +0x0c4 GdiHandleBuffer : [34] Uint4B +0x14c PostProcessInitRoutine : Ptr32 +0x150 TlsExpansionBitmap : Ptr32 Void +0x154 TlsExpansionBitmapBits : [32] Uint4B +0x1d4 SessionId : Uint4B +0x1d8 AppCompatFlags : _ULARGE_INTEGER +0x1e0 AppCompatFlagsUser : _ULARGE_INTEGER +0x1e8 pShimData : Ptr32 Void +0x1ec AppCompatInfo : Ptr32 Void +0x1f0 CSDVersion : _UNICODE_STRING +0x1f8 ActivationContextData : Ptr32 Void +0x1fc ProcessAssemblyStorageMap : Ptr32 Void +0x200 SystemDefaultActivationContextData : Ptr32 Void +0x204 SystemAssemblyStorageMap : Ptr32 Void +0x208 MinimumStackCommit : Uint4B

Structure A.S3. PEB

+0x000 Length : Uint4B +0x004 Initialized : UChar +0x008 SsHandle : Ptr32 Void +0x00c InLoadOrderModuleList : _LIST_ENTRY +0x014 InMemoryOrderModuleList : _LIST_ENTRY +0x01c InInitializationOrderModuleList : _LIST_ENTRY +0x024 EntryInProgress : Ptr32 Void

Structure A.S4. PEB_LDR_DATA

References 1. Alex Shipp, Unpacking Strategies, Proceedings of the 14th Virus Bulletin International Conference, 2004. Maksym Schipka, Tracing Execution Paths, Proceedings of the 15th Virus Bulletin International Conference 2005. Adrian E. Stephan, Defeating Polymorphism: Beyond Emulation, Proceedings of the 15th Virus Bulletin International Conference 2005. Tobias Graf, Generic Unpacking - How to Handle Modified or Unknown PE Compression Engines, Proceedings of the 15th Virus Bulletin International Conference 2005. Mark Probst, Fast Machine-Adaptable Dynamic binary Translation, Workshop on Binary Translation 2001. Fabrice Bellard, QEMU: A fast and portable dynamic translator, http://fabrice.bellard.free.fr/qemu/. Bochs emulator, http://bochs.sourceforge.net/. Chris Eagle, Attacking Obfuscated Code with IDA Pro, Black Hat Briefings 2004, http://www.blackhat.com/presentations/bhusa-04/bh-us-04-eagle.pdf. 9. Danny Quist & Valsmith, Covert Debugging: Circumventing Software Armoring Techniques, Black Hat Briefings 2007, https://www.blackhat.com/presentations/bhusa07/Quist_and_Valsmith/Presentation/bhusa-07-quist_and_valsmith.pdf. 10. Intel64 and IA-32 Architectures Software Developer's Manuals, http://www.intel.com/products/processor/ma nuals/index.htm. 11. Russ Osterlund, What Goes On Inside Windows 2000: Solving the Mysteries of the Loader, MSDN Magazine, March 2002, http://msdn.microsoft.com/msdnmag/issues/ 02/03/Loader/. 12. Matt Pietrek, A Crash Course on the Depths of Win32 Structured Exception Handling, MSDN Magazine, January 1997, http://www.microsoft.com/msj/0197/excepti on/exception.aspx.

2.

3.

4.

5.

6.

7. 8.

12

13. Matt Pietrek, Under The Hood, An In-Depth Look into the Win32 Portable Executable File Format, MSDN Magazine, April 2002, http://msdn.microsoft.com/msdnmag/issues/ 02/02/PE/. 14. Microsoft Portable Executable and Common Object File Format Specification, http://www.microsoft.com/whdc/system/plat form/firmware/PECOFF.mspx. 15. Jeffrey Richter, Programming Applications for Microsoft Windows, Fourth Edition, Microsoft Press. 16. Ji Yan Wu, Full Potential of Dynamic Binary Translation for AV Emulation Engine, Proceedings of the 16th Virus Bulletin International Conference 2006.

13