Your SlideShare is downloading. ×
Binary translation
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Binary translation


Published on

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 …

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.

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Design of x86 Emulator for Generic Unpacking Chandra Prakash Sunbelt Software, USA AbstractCPU emulation techniques have been leveraged for various objectives. These includesupporting re-targetable applications, controlled execution of un-trusted applications,dynamic behavioral analysis of malware and packed malware detection via genericunpacking. Generic unpacking via emulation obviates the need for writing customdetections for each packer and its variants and provides the ability to detect a broadclass of packed malware. The malware is allowed to run in the emulator’s virtualenvironment until one of many stop conditions are reached, when the dynamic virtualmemory state of the unpacked malware can be examined.This paper presents a general architecture of the emulator for x86 platforms intended forpacked malware detection via generic unpacking. It describes layout and interplay ofvarious structural components that comprise this architecture. Specifically, the structuralcomponents include: CPU, PE loader, virtual memory manager, heap, stack, process,process environment block (PEB), thread, thread information block (TIB), structuredexception handling (SEH), interrupt handling, function hooks for spoofing executionreferences into system dll(s). It also describes several unique characteristics exhibited bypacked malware and the challenges imposed by them that ultimately shape the overalldesign of the emulator. There are different levels at whichAcknowledgements emulation can be implemented; full and application only. Full emulationI would like to extend special thanks to involves emulating a large part of themy team members at Sunbelt: Eric Sites, hardware, e.g., VirtualPC and VMWare.Casey Sheehan, Nick Suan and Tom Application-only emulation deals withRobinson, for their valuable support in emulating application level instructionmy contribution towards understanding set and the system call interface.the emulator. An example of an emulating system call1. Introduction interface is FreeBSD’s ability to run Linux i386 binaries. Another example isCPU emulation has been used over the Wow64 (Win32 emulation on 64 bityears for a multitude of objectives. It Windows).allows an application compiled for aspecific target platform to be run on a Over the past two decades, malware hashost platform with a completely different evolved with consumer-based operatingor overlapping architecture set. systems and applications. The main techniques for detecting malware have 1
  • 2. been mostly signature-based. This is true Section 2 describes the majortoday to a large extent. components of the emulator.Packed malware defeats the traditional Section 3 presents examples of a fewsignature-based detection schemes by sample malware characteristics thatencrypting the malware code. But shape its overall design.packed malware can be detected bywriting custom packing routines and In Section 4, we discuss efficiencytechniques such as X-ray. X-ray [3] optimizations of the emulator, e.g.involves finding the decryption key(s) dynamic binary translation.using a function that describes arelationship between the encrypted code, 2. Emulator Componentsdecrypted code and the decryptor codeitself. The emulator consists of a software implementation of the subset ofThese methods perform very well if the hardware, operating system andnumber of packers is limited and they do application environment needed fornot have recursive layers of packing. running an application. The hardware components include the CPU, registersThese methods can very quickly become and interrupt vector table. The operatingquite un-manageable since there are a system components include the PEfairly large number of packers and each loader, virtual memory manager,one has many variations. As an example, structured exception handling (SEH).the most prevalent packer, UPX, has The application environment includesnumerous versions (1.x to 3.x). FSG has input parameter and environmentalversions in the range of 1.x to 2.x. variable support, heap, stack, process environment block (PEB), threadGeneric unpacking helps solve the above information block (TIB), function hooksissues. The malware is allowed to for spoofing execution references intoexecute in a controlled and secure system dll(s). The structural relationshipenvironment until one of many stop among these components is shown in theconditions are reached. Once the class diagram of figure 1.execution has stopped, the virtualmemory state of the malware can be 2.1. PE Loaderexamined for signatures or heuristics. The PE loader [11] creates a ready-to-This paper discusses the design of an run memory-mapped image of the targetapplication-only x86 emulator 1 that executable. The memory-mapped imageimplements a generic unpacking is created according to the Windows PEsolution. specifications [14]. In general terms the loading process consists of following steps:1 Unless stated otherwise, in the remaining part of this paper, a. Calculating virtual mapped size ofemulator will refer to x86 application only emulator for the image based on the size of PEWindows NT family of operating systems in regard togeneric unpacking. Also, all OS specific structures are takenfrom Windows XP-SP2. 2
  • 3. headers and sum of virtual sizes of environment and at the very least it is all the sections. desirable to support instructions that useb. Allocating a contiguous buffer these registers. It is an added benefit to based on virtual mapped size of the provide support for FPU instructions and target image calculated in step a. extensions to x86 architecture, such asc. Copying PE headers and sections at MMX, SSE, SSE2, SSE3[10] and appropriate locations in the virtual 3DNow! instructions. mapped buffer. Section boundaries should be aligned as per the section 2.3. CPU alignment field in the optional header. Each section may have its Typically the task of the emulator CPU own protection (see section 2.5) can be summarized in the following characteristics, e.g., read, write, steps: execute etc., as indicated by the section header. a. Fetch instruction as pointed by EIP.d. Fixing up the import address table b. Decode the instruction and (IAT) [13] of the primary module. In (depending on the instruction) fetch this step the virtual address of all needed operands. The operands imported symbols in the primary can be fetched from some other module are resolved from exports of register or may require a fetch from the dependent modules [11]. The the virtual memory address in the dependent modules need not be address space of the target image. explicitly loaded like the primary c. Once all operands are obtained, a module. Only a list of exported function is executed corresponding symbols from dependent modules to the instruction type and results with their name (or ordinal) and obtained for it. address mapping need to be d. Store the results at the location maintained. specified by the output operands.e. Fixing up the relocations in the e. Increment the EIP to point to the primary module. beginning of next instruction. If the previous instruction was a branchOnce the primary module is loaded instruction it may set EIP to somesuccessfully, its entry point is earmarked other location on its own.for later execution. These steps are repeated until one of2.2. Registers many stop conditions are reached (see Section 2.12). At the onset of execution,These represent an abstraction of the real just after the primary module isCPU registers. There are eight 32-bit successfully loaded, EIP is set to thegeneral purpose registers (EAX, EBX, entry point of the module.ECX, EDX, EBP, ESP, ESI, EDI), six16-bit segment registers (CS, SS, DS, 2.4. Interrupt HandlingES, FS, GS), hardware debug registersDR0-DR3, DR6, DR7, as well as From user mode, Windows allows only aEFLAGS and EIP registers. These subset of interrupt instructions to beregisters provide the basic execution executed. 3
  • 4. 2.5. Execution of disallowed interruptinstructions from user mode results in 2.5. Virtual Memory Managergeneration of access violationexceptions. Table 1 summarizes the The virtual memory [15] managerbehavior that was noted for INT N maintains descriptors for variousinstructions on XP-SP2, when called memory regions used byfrom a user mode application. N is theinterrupt number ranging from 0-255.The interrupt vector table in a user-mode-application-only emulatorgenerates the corresponding exception inthe application SEHHandler System +initiailize() +loadPEImage() «struct» +createProcess() X86CPU X86Registers +fetch() MemoryManager +executeOneInstruction() +readByte() HookList +writeByte() «struct» +virtualAlloc() PEB_LDR_DATA +addHook() +virtualFree() +findHook() +virtualProtect() 1 1 Process «struct»PEB PELoader 1 +run() 1 Heap+parseImage() 1 1+loadImage() 1 +heapCreate() * +heapDestroy() Thread * MemoryRegion * -base MemoryBlockDescriptor -size -allocationType +readByte() 1 1 -protectionType +writeByte() -startPage 1 -pageCount * +readByte() «struct»TIB +writeByte() Stack +generateAccessViolationException() -top -bottom +resize() Figure 1 4
  • 5. the target module. A memory region 2.6. SEH Handlingconsists of contiguous list of pages. Eachpage can have its allocation (committed, Structured Exception Handling (SEH)reserved, free) or protection (read, write, handling [12] is most commonly used toexecute etc.) characteristics. obfuscate execution path by much malware. Usually an exception handlerA reserved memory region consists of a is registered first – containing code forcontiguous sequence of pages for which unpacking the stub – and then anphysical memory has not been exception is deliberately generated. Incommitted. A memory region reserved some cases, once the unpacking stubinitially can be committed later by the gets control, it may further register aapplication or it can be reserved and new exception handler and throw acommitted simultaneously in the very nested exception and so forth. Thefirst VirtualAlloc call. Any memory commonly used exceptions are generatedreference in the primary or a dependent by single step (INT1) and break pointmodule, heap, stack and dynamic virtual (INT3) instructions, arithmetic divide ormemory related calls (e.g., VirtualAlloc, integer overflow exceptions that areVirtualFree) during target’s execution generated by DIV/IDIV instructions orresults in a corresponding descriptor INTO instruction.lookup in the memory manager. 2.7. StackThe descriptor list is maintained in a fastlookup data structure. If the memory The stack is a contiguous memory regionreference is not compatible with the that serves among other things as aallocation type and protection assigned memory work area for parametersto the region, an access violation passed in function calls and SEH chain.exception is generated. There is one stack for each thread. They are implemented in an inverted manner so they grow in the direction ofInterrupt Exception decreasing memory address. The stackNumber (N) thrown parameters, (e.g., base, limit, address of3, 2d Breakpoint top level exception handler frame)4 Integer should be appropriately set in TIB (see Overflow section 2.9).2a, 2b, 2c, 2e None 2 2.8. HeapAll others Exception Violation The heap enables efficient memory allocations of much lower granularity as Table 1 opposed to page granular allocations of VirtualAlloc call. To support Win32 heap-related calls made by the target2 (e.g., HeapAlloc, HeapFree, etc.), a This behavior is seen when no other registers areconfigured before the interrupt instruction is executed. For simulation must be provided. The heapexample, INT 2E is used by system calls, where EAX is implemented as a wrapper aroundcontains system call number and EDX contains parameter(s)address in the stack. This was not done in the tests for results page granular memory allocation Table 1. 5
  • 6. 2.9. Thread Information Block the sort key is denoted by respective list name.For each thread there is a threadinformation block (TIB) structure stored 2.11. Function Hooksat the address indicated by FS:[18h] ineach thread. The layout of TIB is shown Since there is no kernel component inin structure A.S1 in Appendix A. The the application-only emulator, anyfirst field ExceptionList in the TIB system call made by malware in acontains the address of the top level dependent system module likeexception handler frame represented by kernel32.dll is intercepted and itsEXCEPTION_REGISTRATION_RECOR corresponding spoofed implementationD structure. provided. Some of the functions include: LoadLibraryA/W, GetProcAddresss,This address also can be obtained from GetModuleHandleA/W, VirtualAlloc,the value of expression FS:[0]. VirtualFree, HeapAlloc, HeapFree andStackBase and StackLimit, which GetVersionExA/W. Also a default un-contains the lower bound and upper emulated function hook should also bebound of the thread’s stack. Once the provided that gets called when an un-address of TIB is obtained, the address implemented import function isof the process environment block can be encountered.obtained at offset 30h from thebeginning of TIB. 2.12. Stop Conditions2.10. Process Environment Block The ideal condition to stop a target’s emulation is when it is finishedFor each user mode process there is one unpacking and is about to execute theprocess environment block (PEB). The original entry point (OEP). But,layout of PEB is shown below in developing a generic solution tostructure A.S3 in Appendix A. Some of determine exactly when OEP is reachedthe important fields accessed by is not a trivial task. In most cases themalware are: BeingDebugged, emulation is stopped when an un-ImageBaseAddress, emulated function call in a dependentInLoadOrderModuleList, system module is encountered.InMemoryOrderModuleList andInInitializationOrderModuleList of The emulator can stop the target’sPEB_LDR_DATA. execution for various reasons. Typical conditions other than the target-initiatedThe IsDebuggerPresent Win32 API explicit termination are described below:simply returns value in BeingDebuggedfield of PEB. This is used by malware to a. Encountering an un-emulated systemdetect a debugger’s presence as one of call in a dependent module.the anti-debugging tricks (see Example b. Encountering an unhandled3.7). The sorted list of modules is exception for which no SEH handlermaintained in three different was found. Some of these exceptionsLIST_ENTRY type data structures where include invalid memory read, write, 6
  • 7. execute, divide by zero or integer Example 3.1 overflow.c. Encountering an un-emulated or 0041C25A CALL 0041C25F illegal instruction. 0041C25F PUSH EBPd. Reaching configured timeout. 0041C260 MOV EBX,DWORD PTRe. Reaching the maximum number of SS:[ESP+8] instructions. 0041C264 MOV EBP,DWORD PTRf. Encountering an attempt to load a dll SS:[ESP+4] that could not be located. 0041C268 SUB DWORD PTRg. The target loading too many dlls in SS:[ESP+4],1A4AF an explicit load module.h. Encountering a very large nested call Example 3.1 shows a snippet of code depth of the SEH call chain. near entry point 0041C25A of a piece of malware when the program has just started. At address 0041C260, the MOV3. Malware with unique instruction references an address characteristics ([ESP+8]) at the top of initial stack. This address is the return address after theAn ideal emulator would be the one that CALL instruction in kernel32.dll thatimplements every detail of the supported “calls” the malware entry point. Theplatform to near perfection so that return address actually ends up callingmalware behavior is correctly captured. ExitProcess. Hence, it is desirable toBut practical constraints due to mimic the Windows program initialperformance optimizations and stack values. For an executable, initialundocumented features would allow stack values are set in the first fifteenonly limited implementation of the stack locations starting from the bottomemulator. of the stack.As a result, once the core emulator Example 3.2system is ready, developing a robustemulator is an iterative process driven by 004A1584 MOV EBX,DWORD PTRminor fine tuning for unique SS:[ESP+24] ; EBX=77E8141Acharacteristics of supported packers and 004A1588 AND EBX,FFE00000 ;symptoms exhibited by the malware test- EBX=77E00000bed. . .Below are some of the cases experienced 004A16C4 ADD EBX,10000with malware samples that led to the 004A16CA JE SHORT 004A16F7improvement of our emulator. The cases 004A16CC CMP WORD PTRdescribed in these examples are not DS:[EBX],5A4Dcomplete and are just a small sample of 004A16D1 JNZ SHORT 004A16C4the possible ways that malware canexhibit execution flow that affects the Example 3.2 shows a scenario whereemulator. malware follows an execution path using the alignment of load address of a dependent system module (kernel32.dll). 7
  • 8. At 004A16C4 EBX value is incremented LPVOID lpvReservedby system allocation granularity. At );004A16CC it compares the content ofthe value located at the address in EBX Example 3.5with WORD type 5A4D (ascii ‘MZ’),which is the startup marker for a PE 0048C075 MOV EAX, 0048C093image. If the address of the startup 0048C07A PUSH EBPmarker is found in the address pointed 0048C07B PUSH EAXby EBX, execution follows to location 0048C07C PUSH DWORD PTR FS:[0]004A16C4. 0048C082 MOV DWORD PTR FS:[0],ESPExample 3.3 0048C088 MOV EBP,4243484B 0048C08D MOV EAX,431428200 PUSH ED01C390 0048C092 INT331428205 MOV EAX,ESP 0048C093 CMP AL,431428207 CALL EAX 0048C095 JNZ SHORT 0048C09B0012FFC0 NOP 0048C097 NOP0012FFC1 RETN 0048C098 NOP31428209 XCHG EAX,EBX ; 0048C099 RETNEAX=7FFDF000, EBX=0012FFC03142820A POP EBX Example 3.5 shows a case of setting the proper values of registers just before aExample 3.3 shows code starting at the SEH handler is executed. Instructionentry point of the program at the onset of sequence range 0048C075-0048C082 setprogram execution, which demonstrates up a new SEH handler to 0048C093.use of initial value in the registers. At When the exception is generated due to31428209 EBX is referenced whose INT3 instruction, the SEH handler’svalue is equal to the PEB address of the second instruction at 0048C095 has aprogram. Initial value of other general conditional jump instruction dependingpurpose and segment registers should be on whether AL is zero or not. It is seenset similarly to the way as they are set in in real Windows, EAX is set to zero justWindows. before SEH handler gets control. Therefore, just before the SEH handlerExample 3.4 gets control, other registers should be set up as they are set in Windows.For the correct emulation of a dll, beforethe entry point function DllMain gets Example 3.6called, its input parameters must be setin the stack as in Windows. These input 004141EF SUB EDX,EDXparameters include a module handle 004141F1 MOV EAX,DWORD PTR(base address), reason for call and a FS:[EDX]reserved parameter as below. 004141F4 MOV ESP,DWORD PTR DS:[EAX]BOOL WINAPI DllMain( 004141F6 POP DWORD PTR HINSTANCE hinstDLL, FS:[EDX] DWORD fdwReason, 004141F9 POP EAX 8
  • 9. 004141FA POP EBP checked to evaluate the condition of the004141FB RETN branch instruction at 3142822A.Example 3.6 shows an exception handler Example 3.8as another case of use of Windows SEHto exhibit a twisted execution flow. At 0044D0A5 MOV EAX,DWORD PTR00414F4 it skips over the top level SEH FS:[30]handler and positions ESP to the SEH 0044D0AB TEST EAX,EAXframe for this handler. This is possible 0044D0AD JS SHORT 0044D0BBbecause when the application handler 0044D0AF MOV EAX,DWORD PTRgets control after an exception, Windows DS:[EAX+C] 0044D0B2 MOValso registers another handler on top ESI,DWORD PTR DS:[EAX+1C]before application handler gets control. 0044D0B5 LODS DWORD PTR DS:[ESI]At 004141F6 the two top SEH handlersare torn down and after 00414FB Example 3.8 shows a case where PEB isexecution resumes at location specified referenced at 0044DA05. At 0044D0AF,by ESP, that was last updated at 0044D0B2 and 0044D0B5,00414DFA. Actually, in this case before PEB_LDR_DATA,the SEH handler was invoked by InInitializationOrderModuleList andWindows, the malware had already InInitializationOrderModuleList.Flinkconfigured a return address on the stack respectively are referenced. Thethat gets executed after RETN at malware happens to be referencing the004141FB. kernel32.dll load information in its dependent module list sorted onExample 3.7 initialization order.3142821B MOV EAX, DWORD PTR Example 3.9FS:[18]31428220 MOV EAX, DWORD PTR 004033FA MOV EAX,DWORD PTRDS:[EAX+30] DS:[4503D4]31428223 MOVZX EAX, BYTE PTR 00403400 TEST CL,CLDS:[EAX+2] 00403402 JNZ SHORT 0040341A31428227 CMP EAX, 0 00403404 MOV EDX,DWORD PTR3142822A JNZ SHORT 3142826E FS:[2C]3142822C CALL 31428231 0040340B MOV EAX,DWORD PTR31428231 POP EBP DS:[EDX+EAX*4] 0040340E RETNExample 3.7 shows a case where themalware is checking for the presence of Example 3.9 shows a case of use ofa debugger. At 3142821B the address of Thread Local Storage(TLS) in aTIB is obtained and used to get the malware. At 00403404 the beginning ofaddress of PEB at 31428220. At the thread local storage pointer array31428223 BeingDebugged field of PEB value in FS:[2Ch] is copied over in(structure A.S3 in Appendix A) is EDX. The next instruction at 0040340B 9
  • 10. returns in EAX value of a TLS pointer as 4. Conclusionindexed by previous value in EAX. The prevalent use of emulation based technologies by present AV securityExample 3.10 vendors speaks for itself about its relevance and merit. Plain emulation isAll Win32 PE executables are expected hundreds of times slower [3] than nativeto follow the PE format execution speeds and may not sufficespecifications[14] in the strictest sense. when large numbers of packed malwareYet, it is seen that many malware samples, each with several hundredsamples do not conform to these formal millions of instructions need to beguidelines and are still allowed to run by processed. Dynamic binary translationthe Windows loader. [3][5][6][16] provides very good speed efficiency improvements over plain emulation by translating frequent loops in the target into harmless instructionsStructure Field Value and executing them at native speed. TheDos e_lfanew 0x10 code to be translated is partitioned into aHeader sequence of basic blocks. There is aOptional SizeOfCode 0x4c454eHeader 52 performance hit at the time ofOptional SizeOfInitiali 0x442e3 translation, but the translation is doneHeader zedData 233 only once and for subsequent executionOptional AddressOfEnt 0x11a4 of the same block, the translatedHeader ryPoint instructions are used. It is estimated thatSection PointerToRaw 0x10 dynamic binary translation is only aboutHeader Data ten times slower [16] than native execution. Table 2. There are also implementations of page- fault-handler-based unpacking systemsTable 2 shows an example of an where all memory writes from a packedinteresting case of values in the PE program are monitored from kernel untilheader of a malware sample, which is an execute is issued in the modifiedloaded with no complaints by Windows monitored memory regions [9]. Theloader. The file header that starts after page-fault-handler-based unpackingthe PE signature indicated by offset system yields maximum speede_lfanew, begins right in the middle of improvements since the malware isDOS header. SizeOfCode and allowed to run natively on the hostSizeOfInitializedData values are machine and in that sense does notcompletely random and require any kind of emulation. But, itsPointerToRawData offset for a section implementation is discouraged since italso begins right where file header starts! requires un-conventional ways ofIn general a piece of malware should be modifying the page fault interruptloaded by the emulator as long as the handler in the kernel and may not evenWindows loader accepts it by relaxing work on 64-bit Vista because of patchconstraints on these kinds of aberrations. guard protection. 10
  • 11. 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 : Ptr32 _EXCEPTION_REGISTRATION_RECORD+0x004 Handler : 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
  • 12. +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_DATAReferences1. Alex Shipp, Unpacking Strategies, Proceedings of the 14th Virus Bulletin usa-04/bh-us-04-eagle.pdf. International Conference, 2004. 9. Danny Quist & Valsmith, Covert2. Maksym Schipka, Tracing Execution Paths, Debugging: Circumventing Software Proceedings of the 15th Virus Bulletin Armoring Techniques, Black Hat Briefings International Conference 2005. 2007,3. Adrian E. Stephan, Defeating Polymorphism: Beyond Emulation, usa- Proceedings of the 15th Virus Bulletin 07/Quist_and_Valsmith/Presentation/bh- International Conference 2005. usa-07-quist_and_valsmith.pdf.4. Tobias Graf, Generic Unpacking - How to 10. Intel64 and IA-32 Architectures Software Handle Modified or Unknown PE Developers Manuals, Compression Engines, Proceedings of the 15th Virus Bulletin International Conference nuals/index.htm. 2005. 11. Russ Osterlund, What Goes On Inside5. Mark Probst, Fast Machine-Adaptable Windows 2000: Solving the Mysteries of the Dynamic binary Translation, Workshop on Loader, MSDN Magazine, March 2002, Binary Translation 2001. Fabrice Bellard, QEMU: A fast and portable 02/03/Loader/. dynamic translator, 12. Matt Pietrek, A Crash Course on the Depths of Win32™ Structured Exception Handling,7. Bochs emulator, MSDN Magazine, January 1997, Chris Eagle, Attacking Obfuscated Code on/exception.aspx. with IDA Pro, Black Hat Briefings 2004, 12
  • 13. 13. Matt Pietrek, Under The Hood, An In-Depth Look into the Win32 Portable Executable File Format, MSDN Magazine, April 2002, 02/02/PE/.14. Microsoft Portable Executable and Common Object File Format Specification, 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