Inject your code to a Portable Executable file

Downloads

• PE Viewer
• PE Maker - Step 1 - Add new Section.
• PE Maker - Step 2 - Travel towards OEP.
• PE Maker - Step 3 - Support Import Table.
• PE Maker - Step 4 - Support DLL and OCX.
• PE Maker - Step 5 - Final work.
• CALC.EXE - test file

Contents

• 0. Preface
• 1. Prerequisite
• 2. Portable Executable file format
  • 2.1 The MS-DOS data
  • 2.2 The Windows NT data
  • 2.3 The Section Headers and Sections
• 3. Debugger, Disassembler and some Useful Tools
  • 3.1 Debuggers
    • 3.1.1 SoftICE
    • 3.1.2 OllyDbg
    • 3.1.3 Which parts are important in a debugger interface?
  • 3.2 Disassembler
    • 3.2.1 Proview disassembler
    • 3.2.2 W32Dasm
    • 3.2.3 IDA Pro
  • 3.3 Some Useful Tools
    • 3.3.1 LordPE
    • 3.3.2 PEiD
    • 3.3.3 Resource Hacker
    • 3.3.4 WinHex
    • 3.3.5 CFF Explorer
• 4. Add new section and Change OEP
  • 4.1 Retrieve and Rebuild PE file
  • 4.2 Create Data for new Section
  • 4.3 Some notes regarding creating a new PE file
  • 4.4 Some notes regarding linking this VC Project
• 5. Store Important Data and Reach Original OEP
  • 5.1 Restore the first Registers Context
  • 5.2 Restore the Original Stack
  • 5.3 Approach OEP by Structured Exception Handling
    • 5.3.1 Implement Exception Handler
    • 5.3.2 Attain OEP by adjusting the Thread Context
• 6. Build an Import Table and Reconstruct the Original Import Table
  • 6.1 Construct the Client Import Table
  • 6.2 Using other API functions in run-time
  • 6.3 Fix up the Original Import Table
• 7. Support DLL and OCX
  • 7.1 Twice OEP approach
  • 7.2 Implement Relocation Table
  • 7.3 Build a Special Import table
• 8. Preserve the Thread Local Storage
• 9. Inject your code
• 10. Conclusion

0 Preface

It might be, you demand to comprehend the ways a virus program injects its procedure in to the interior of a portable executable file and corrupts it, or you are interested in implementing a packer or a protector for your specific intention to encrypt the data of your portable executable (PE) file. This article is committed to represent a brief intuition to realize the performance which is accomplished by EXE tools or some kind of mal-wares.

You can employ the source code of this article to create your custom EXE builder. It could be used to make an EXE protector in the right way, or with a wrong intention, to pullulate a virus. However, my purpose of writing this article has been to gaze on the first application, so I will not be responsible for the immoral usage of these methods.

1 Prerequisite

There are no specific mandatory prerequisites to follow the topics in this article. If you are familiar with debugger and also the portable file format, I suggest you to drop the sections 2 and 3, the whole of these sections have been made for people who don’t have any knowledge regarding the EXE file format and also debuggers.

2 Portable Executable file format

The Portable Executable file format was defined to provide the best way for the Windows Operating System to execute code and also to store the essential data which is needed to run a program, for example constant data, variable data, import library links, and resource data. It consists of MS-DOS file information, Windows NT file information, Section Headers, and Section images, Table 1.

2.1 The MS-DOS data

These data let you remember the first days of developing the Windows Operating System, the days. We were at the beginning of a way to achieve a complete Operating System like Windows NT 3.51 (I mean, Win3.1, Win95, Win98 were not perfect OSs). The MS-DOS data causes that your executable file calls a function inside MS-DOS and the MS-DOS Stub program lets it display: "This program can not be run in MS-DOS mode" or "This program can be run only in Windows mode", or some things like these comments when you try to run a Windows EXE file inside MS-DOS 6.0, where there is no footstep of Windows. Thus, this data is reserved for the code to indicate these comments in the MS-DOS operating system. The most interesting part of the MS-DOS data is "MZ"! Can you believe, it refers to the name of "Mark Zbikowski", one of the first Microsoft programmers?

To me, only the offset of the PE signature in the MS-DOS data is important, so I can use it to find the position of the Windows NT data. I just recommend you to take a look at Table 1, then observe the structure of IMAGE_DOS_HEADER in the <winnt.h> header in the <Microsoft Visual Studio .net path>\VC7\PlatformSDK\include\ folder or the <Microsoft Visual Studio 6.0 path>\VC98\include\ folder. I do not know why the Microsoft team has forgotten to provide some comment about this structure in the MSDN library!

typedef struct _IMAGE_DOS_HEADER { // DOS .EXE header "MZ"
    WORD   e_magic;                // Magic number
    WORD   e_cblp;                 // Bytes on last page of file
    WORD   e_cp;                   // Pages in file
    WORD   e_crlc;                 // Relocations
    WORD   e_cparhdr;              // Size of header in paragraphs
    WORD   e_minalloc;             // Minimum extra paragraphs needed
    WORD   e_maxalloc;             // Maximum extra paragraphs needed
    WORD   e_ss;                   // Initial (relative) SS value
    WORD   e_sp;                   // Initial SP value
    WORD   e_csum;                 // Checksum
    WORD   e_ip;                   // Initial IP value
    WORD   e_cs;                   // Initial (relative) CS value
    WORD   e_lfarlc;               // File address of relocation table
    WORD   e_ovno;                 // Overlay number
    WORD   e_res[4];               // Reserved words
    WORD   e_oemid;                // OEM identifier (for e_oeminfo)
    WORD   e_oeminfo;              // OEM information; e_oemid specific
    WORD   e_res2[10];             // Reserved words
    LONG   e_lfanew;               // File address of the new exe header
  } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

e_lfanew is the offset which refers to the position of the Windows NT data. I have provided a program to obtain the header information from an EXE file and to display it to you. To use the program, just try:

PE Viewer

• Download source files - 132 Kb

This sample is useful for the whole of this article.

Table 1 - Portable Executable file format structure

00000000  ASCII "MZ"
00000002  DW 0090
00000004  DW 0003
00000006  DW 0000
00000008  DW 0004
0000000A  DW 0000
0000000C  DW FFFF
0000000E  DW 0000
00000010  DW 00B8
00000012  DW 0000
00000014  DW 0000
00000016  DW 0000
00000018  DW 0040
0000001A  DW 0000
0000001C  DB 00
…
…
0000003B  DB 00
0000003C  DD 000000F0

00000040  º.´.Í!¸\LÍ!This program canno
00000060  t be run in DOS mode....$.......

000000F0  ASCII "PE"

000000F4  DW 014C
000000F6  DW 0003
000000F8  DD 3B7D8410
000000FC  DD 00000000
00000100  DD 00000000
00000104  DW 00E0
00000106  DW 010F

00000108  DW 010B
0000010A  DB 07
0000010B  DB 00
0000010C  DD 00012800
00000110  DD 00009C00
00000114  DD 00000000
00000118  DD 00012475
0000011C  DD 00001000
00000120  DD 00014000
00000124  DD 01000000
00000128  DD 00001000
0000012C  DD 00000200
00000130  DW 0005
00000132  DW 0001
00000134  DW 0005
00000136  DW 0001
00000138  DW 0004
0000013A  DW 0000
0000013C  DD 00000000
00000140  DD 0001F000
00000144  DD 00000400
00000148  DD 0001D7FC
0000014C  DW 0002
0000014E  DW 8000
00000150  DD 00040000
00000154  DD 00001000
00000158  DD 00100000
0000015C  DD 00001000
00000160  DD 00000000
00000164  DD 00000010

000001E8  ASCII".text"
000001F0  DD 000126B0
000001F4  DD 00001000
000001F8  DD 00012800
000001FC  DD 00000400
00000200  DD 00000000
00000204  DD 00000000
00000208  DW 0000
0000020A  DW 0000
0000020C  DD 60000020
    CODE|EXECUTE|READ

00000210  ASCII".data"; SECTION
00000218  DD 0000101C ; VirtualSize = 0x101C
0000021C  DD 00014000 ; VirtualAddress = 0x14000
00000220  DD 00000A00 ; SizeOfRawData = 0xA00
00000224  DD 00012C00 ; PointerToRawData = 0x12C00
00000228  DD 00000000 ; PointerToRelocations = 0x0
0000022C  DD 00000000 ; PointerToLineNumbers = 0x0
00000230  DW 0000     ; NumberOfRelocations = 0x0
00000232  DW 0000     ; NumberOfLineNumbers = 0x0
00000234  DD C0000040 ; Characteristics = 
                        INITIALIZED_DATA|READ|WRITE
00000238  ASCII".rsrc"; SECTION
00000240  DD 00008960 ; VirtualSize = 0x8960
00000244  DD 00016000 ; VirtualAddress = 0x16000
00000248  DD 00008A00 ; SizeOfRawData = 0x8A00
0000024C  DD 00013600 ; PointerToRawData = 0x13600
00000250  DD 00000000 ; PointerToRelocations = 0x0
00000254  DD 00000000 ; PointerToLineNumbers = 0x0
00000258  DW 0000     ; NumberOfRelocations = 0x0
0000025A  DW 0000     ; NumberOfLineNumbers = 0x0
0000025C  DD 40000040 ; Characteristics = 
                        INITIALIZED_DATA|READ

00000400  EA 22 DD 77 D7 23 DD 77  ê"Ýw×#Ýw
00000408  9A 18 DD 77 00 00 00 00  šÝw....
00000410  2E 1E C7 77 83 1D C7 77  .ÇwƒÇw
00000418  FF 1E C7 77 00 00 00 00  ÿÇw....
00000420  93 9F E7 77 D8 05 E8 77  “ŸçwØèw
00000428  FD A5 E7 77 AD A9 E9 77  ý¥çw­©éw
00000430  A3 36 E7 77 03 38 E7 77  £6çw>8çw
00000438  41 E3 E6 77 60 8D E7 77  Aãæw`çw
00000440  E6 1B E6 77 2B 2A E7 77  ææw+*çw
00000448  7A 17 E6 77 79 C8 E6 77  zæwyÈæw
00000450  14 1B E7 77 C1 30 E7 77  çwÁ0çw
…

…
0001BF00  63 00 2E 00 63 00 68 00  c...c.h.
0001BF08  6D 00 0A 00 43 00 61 00  m...C.a.
0001BF10  6C 00 63 00 75 00 6C 00  l.c.u.l.
0001BF18  61 00 74 00 6F 00 72 00  a.t.o.r.
0001BF20  11 00 4E 00 6F 00 74 00  .N.o.t.
0001BF28  20 00 45 00 6E 00 6F 00   .E.n.o.
0001BF30  75 00 67 00 68 00 20 00  u.g.h. .
0001BF38  4D 00 65 00 6D 00 6F 00  M.e.m.o.
0001BF40  72 00 79 00 00 00 00 00  r.y.....
0001BF48  00 00 00 00 00 00 00 00  ........
0001BF50  00 00 00 00 00 00 00 00  ........
0001BF58  00 00 00 00 00 00 00 00  ........
0001BF60  00 00 00 00 00 00 00 00  ........
0001BF68  00 00 00 00 00 00 00 00  ........
0001BF70  00 00 00 00 00 00 00 00  ........
0001BF78  00 00 00 00 00 00 00 00  ........

2.2 The Windows NT data

As mentioned in the preceding section, e_lfanew storage in the MS-DOS data structure refers to the location of the Windows NT information. Hence, if you assume that the pMem pointer relates the start point of the memory space for a selected portable executable file, you can retrieve the MS-DOS header and also the Windows NT headers by the following lines, which you also can perceive in the PE viewer sample (pelib.cpp, PEStructure::OpenFileName()):

IMAGE_DOS_HEADER        image_dos_header;
IMAGE_NT_HEADERS        image_nt_headers;
PCHAR pMem;
…
memcpy(&image_dos_header, pMem, 
       sizeof(IMAGE_DOS_HEADER));
memcpy(&image_nt_headers,
       pMem+image_dos_header.e_lfanew, 
       sizeof(IMAGE_NT_HEADERS));

It seems to be very simple, the retrieval of the headers information. I recommend inspecting the MSDN library regarding the IMAGE_NT_HEADERS structure definition. It makes comprehensible to grasp what the image NT header maintains to execute a code inside the Windows NT OS. Now, you are conversant with the Windows NT structure, it consists of the "PE" Signature, the File Header, and the Optional Header. Do not forget to take a glimpse at their comments in the MSDN Library and besides in Table 1.

One the whole, I consider merely, on the most circumstances, the following cells of the IMAGE_NT_HEADERS structure:

FileHeader->NumberOfSections
OptionalHeader->AddressOfEntryPoint
OptionalHeader->ImageBase
OptionalHeader->SectionAlignment
OptionalHeader->FileAlignment
OptionalHeader->SizeOfImage
OptionalHeader->
  DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]->VirtualAddress
OptionalHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]->Size

You can observe clearly, the main purpose of these values, and their role when the internal virtual memory space allocated for an EXE file by the Windows OS is fully allocated, if you pay attention to their explanations in MSDN library, so I am not going to repeat the MSDN annotations here.

I should mention a brief comment regarding the PE data directories, or OptionalHeader-> DataDirectory[], as I think there are a few aspects of interest concerning them. When you come to survey the Optional header through the Windows NT information, you will find that there are 16 directories at the end of the Optional Header, where you can find the consecutive directories, including their Relative Virtual Address and Size. I just mention here, the notes from <winnt.h> to clarify these information:

#define IMAGE_DIRECTORY_ENTRY_EXPORT          0   // Export Directory

#define IMAGE_DIRECTORY_ENTRY_IMPORT          1   // Import Directory

#define IMAGE_DIRECTORY_ENTRY_RESOURCE        2   // Resource Directory

#define IMAGE_DIRECTORY_ENTRY_EXCEPTION       3   // Exception Directory

#define IMAGE_DIRECTORY_ENTRY_SECURITY        4   // Security Directory

#define IMAGE_DIRECTORY_ENTRY_BASERELOC       5   // Base Relocation Table

#define IMAGE_DIRECTORY_ENTRY_DEBUG           6   // Debug Directory

#define IMAGE_DIRECTORY_ENTRY_ARCHITECTURE    7   // Architecture Specific Data

#define IMAGE_DIRECTORY_ENTRY_GLOBALPTR       8   // RVA of GP

#define IMAGE_DIRECTORY_ENTRY_TLS             9   // TLS Directory

#define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG    10   // Load Configuration Directory

#define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT   11   // Bound Import Directory in headers

#define IMAGE_DIRECTORY_ENTRY_IAT            12   // Import Address Table

#define IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT   13   // Delay Load Import Descriptors

#define IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR 14   // COM Runtime descriptor

The last one (15) was reserved for use in future; I have not yet seen any purpose to use it even in PE64.

For instance, if you desire to perceive the relative virtual address (RVA) and the size of the resource data, it is enough to retrieve them by:

DWORD dwRVA = image_nt_headers.OptionalHeader->
  DataDirectory[IMAGE_DIRECTORY_ENTRY_RESOURCE]->VirtualAddress;
DWORD dwSize = image_nt_headers.OptionalHeader->
  DataDirectory[IMAGE_DIRECTORY_ENTRY_RESOURCE]->Size;

To comprehend more regarding the significance of data directories, I forward you to section 3.4.3, Microsoft Portable Executable and the Common Object File Format Specification document by Microsoft, and furthermore section 6 of this document, where you discern the various types of sections and their applications. We will discuss the section's advantage subsequently.

2.3 The Section Headers and Sections

We currently observe how the portable executable files declare the location and the size of a section on a disk storage file and inside the virtual memory space allocated for the program with IMAGE_NT_HEADERS-> OptionalHeader->SizeOfImage by the Windows task manager, as well the characteristics to demonstrate the type of the section. To understand better the Section header as my previous declaration, I suggest having a short gape on the IMAGE_SECTION_HEADER structure definition in the MSDN library. For an EXE packer developer, VirtualSize, VirtualAddress, SizeOfRawData, PointerToRawData, and Characteristics cells have significant rules. While developing an EXE packer, you should be clever enough to play with them. There are somethings to be noted while you modify them; you should take care to align the VirtualSize and VirtualAddress according to OptionalHeader->SectionAlignment, as well as SizeOfRawData and PointerToRawData in line with OptionalHeader->FileAlignment. Otherwise, you will corrupt your target EXE file and it will never run. Regarding Characteristics, I pay attention mostly to establish a section by IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE | IMAGE_SCN_CNT_INITIALIZED_DATA, I prefer my new section has ability to initialize such data during running process; such as import table; besides, I need it to be able to modify itself by the loader with my settings in the section characteristics to read- and writeable.

Moreover, you should pay attention to the section names, you can know the purpose of each section by its name. I will just forward you to section 6: Microsoft Portable Executable and the Common Object File Format Specification documents. I believe, it represents the totality of sections by their names, Table 2.

Table 2 - Section names

To comprehend the section headers and also the sections, you can run the sample PE viewer. By this PE viewer, you only can realize the application of the section headers in a file image, so to observe the main significance in the Virtual Memory, you should try to load a PE file by a debugger, and the next section represents the main idea of using the virtual address and –size in the virtual memory by using a debugger. The last note is about IMAGE_NT_HEADERS-> FileHeader-><CODE>NumberOfSections, that provides a number of sections in a PE file, do not forget to adjust it whenever you remove or add some sections to a PE file, I am talking about section injection!

3 Debugger, Disassembler and some Useful Tools

In this part, you will become familiar with the necessary and essential equipments to develop your PE tools.

3.1 Debuggers

The first essential prerequisite, to become a PE tools developer, is to have enough experience with bug tracer tools. Furthermore, you should know most of the assembly instructions. To me, the Intel documents are the best references. You can obtain them from the Intel site for IA-32, and on top of that IA-64; the future belongs to IA-64 CPUs, Windows XP 64-bit, and also PE64!

• IA-32 Intel Architecture Software Developer’s Manuals.
• Intel Itanium Architecture Assembly Language Reference Guide.
• The Intel Itanium Processor Developer Resource Guide.

To trace a PE file, SoftICE by Compuware Corporation, I knew it also as named NuMega when I was at high school, is the best debugger in the world. It implements process tracing by using kernel mode method debugging without applying Windows debugging application programming interface (API) functions. In addition, I am going to introduce one perfect debugger in user mode level. It utilizes the Windows debugging API to trace a PE file and also attaches itself to an active process. These API functions have been provided by Microsoft teams, inside the Windows Kernel32 library, to trace a specific process, by using Microsoft tools, or perhaps, to make your own debugger! Some of those API functions inlude: CreateThread(), CreateProcess(), OpenProcess(), DebugActiveProcess(), GetThreadContext(), SetThreadContext(), ContinueDebugEvent(), DebugBreak(), ReadProcessMemory(), WriteProcessMemory(), SuspendThread(), and ResumeThread().

3.1.1 SoftICE

It was in 1987; Frank Grossman and Jim Moskun decided to establish a company called NuMega Technologies in Nashua, NH, in order to develop some equipments to trace and test the reliability of Microsoft Windows software programs. Now, it is a part of Compuware Corporation and its product has participated to accelerate the reliability in Windows software, and additionally in Windows driver developments. Currently, everyone knows the Compuware DriverStudio which is used to establish an environment for implementing the elaboration of a kernel driver or a system file by aiding the Windows Driver Development Kit (DDK). It bypasses the involvement of DDK to implement a portable executable file of kernel level for a Windows system software developer. For us, only one instrument of DriverStudio is important, SoftICE, this debugger can be used to trace every portable executable file, a PE file for user mode level or a PE file for kernel mode level.

Figure 1 - SoftICE Window

3.1.2 OllyDbg

It was about 4 years ago, that I first saw this debugger by chance. For me, it was the best choice, I was not so wealthy to purchase SoftICE, and at that time, SoftICE only had good functions for DOS, Windows 98, and Windows 2000. I found that this debugger supported all kinds of Windows versions. Therefore, I started to learn it very fast, and now it is my favorite debugger for the Windows OS. It is a debugger that can be used to trace all kinds of portable executable files except a Common Language Infrastructure (CLI) file format in user mode level, by using the Windows debugging API. Oleh Yuschuk, the author, is one of worthiest software developers I have seen in my life. He is a Ukrainian who now lives in Germany. I should mention here that his debugger is the best choice for hacker and cracker parties around the world! It is a freeware! You can try it from OllyDbg Homepage.

Figure 2 - OllyDbg CPU Window

3.1.3 Which parts are important in a debugger interface?

I have introduced two debuggers without talking about how you can employ them, and also which parts you should pay attention more. Regarding using debuggers, I refer you to their instructions in help documents. However, I want to explain shortly the important parts of a debugger; of course, I am talking about low-level debuggers, or in other words, machine-language debuggers of the x86 CPU families.

All of low-level debuggers consist of the following subdivisions:

1. Registers viewer.

   EAX

   ECX

   EDX

   EBX

   ESP

   EBP

   ESI

   EDI

   EIP

   o d t s z a p c

2. Disassembler or Code viewer.

   010119E0 PUSH EBP 010119E1 MOV EBP,ESP 010119E3 PUSH -1 010119E5 PUSH 01001570 010119EA PUSH 01011D60 010119EF MOV EAX,DWORD PTR FS:[0] 010119F5 PUSH EAX 010119F6 MOV DWORD PTR FS:[0],ESP 010119FD ADD ESP,-68 01011A00 PUSH EBX 01011A01 PUSH ESI 01011A02 PUSH EDI 01011A03 MOV DWORD PTR SS:[EBP-18],ESP 01011A06 MOV DWORD PTR SS:[EBP-4],0

3. Memory watcher.

   0023:01013000 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0023:01013010 01 00 00 00 20 00 00 00-0A 00 00 00 0A 00 00 00 ................ 0023:01013020 20 00 00 00 00 00 00 00-53 63 69 43 61 6C 63 00 ........SciCalc. 0023:01013030 00 00 00 00 00 00 00 00-62 61 63 6B 67 72 6F 75 ........backgrou 0023:01013040 6E 64 00 00 00 00 00 00-2E 00 00 00 00 00 00 00 nd..............

4. Stack viewer.

   0010:0007FFC4 4F 6D 81 7C 38 07 91 7C-FF FF FF FF 00 90 FD 7F Om |8 ‘| . 0010:0007FFD4 ED A6 54 80 C8 FF 07 00-E8 B4 F5 81 FF FF FF FF T . 0010:0007FFE4 F3 99 83 7C 58 6D 81 7C-00 00 00 00 00 00 00 00 Xm |........ 0010:0007FFF4 00 00 00 00 E0 19 01 01-00 00 00 00 00 00 00 00 .... ....

5. Command line, command buttons, or shortcut keys to follow the debugging process.

   Command	SoftICE	OllyDbg
   Run	F5	F9
   Step Into	F11	F7
   Step Over	F10	F8
   Set Break Point	F8	F2

You can compare Figure 1 and Figure 2 to distinguish the difference between SoftICE and OllyDbg. When you want to trace a PE file, you should mostly consider these five subdivisions. Furthermore, every debugger comprises of some other useful parts; you should discover them by yourself.

3.2 Disassembler

We can consider OllyDbg and SoftICE as excellent disassemblers, but I also want to introduce another disassembler tool which is famous in the reverse engineering world.

3.2.1 Proview disassembler

Proview or PVDasm is an admirable disassembler by the Reverse-Engineering-Community; it is still under development and bug fixing. You can find its disassmbler source engine and employ it to create your own disassembler.

3.2.2 W32Dasm

W32DASM can disassemble both 16 and 32 bit executable file formats. In addition to its disassembling ability, you can employ it to analyze import, export and resource data directories data.

3.2.3 IDA Pro

All reverse-engineering experts know that IDA Pro can be used to investigate, not only x86 instructions, but that of various kinds of CPU types like AVR, PIC, and etc. It can illustrate the assembly source of a portable executable file by using colored graphics and tables, and is very useful for any newbie in this area. Furthermore, it has the capability to trace an executable file inside the user mode level in the same way as OllyDbg.

3.3 Some Useful Tools

A good PE tools developer is conversant with the tools which save his time, so I recommend to select some appropriate instruments to investigate the base information under a portable executable file.

3.3.1 LordPE

LordPE by y0da is still the first choice to retrieve PE file information with the possibility to modify them.

3.3.2 PEiD

PE iDentifier is valuable to identify the type of compilers, packers, and cryptors of PE files. As of now, it can detect more than 500 different signature types of PE files.

3.3.3 Resource Hacker

Resource Hacker can be employed to modify resource directory information; icon, menu, version info, string table, and etc.

3.3.4 WinHex

WinHex, it is clear what you can do with this tool.

3.3.5 CFF Explorer

Eventually, CFF Explorer by Ntoskrnl is what you wish to have as a PE Utility tool in your dream; it supports PE32/64, PE rebuild included Common Language Infrastructure (CLI) file, in other words, the .NET file, a resource modifier, and much more facilities which can not be found in others, just try and discover every unimaginable option by hand.

4 Add new section and Change OEP

We are ready to do the first step of making our project. So I have provided a library to add a new section and rebuild the portable executable file. Before starting, I like you get familiar with the headers of a PE file, by using OllyDbg. You should first open a PE file, that pops up a menu, View->Executable file, again get a popup menu Special->PE header. And you will observe a scene similar to Figure 3. Now, come to Main Menu View->Memory, try to distinguish the sections inside the Memory map window.

Figure 3

00000000
00000002
00000004
00000006
00000008
0000000A
0000000C
0000000E
00000010
00000012
00000014
00000016
00000018
0000001A
0000001C
0000001D
0000001E
0000001F
00000020
00000021
00000022
00000023
00000024
00000025
00000026
00000027
00000028
00000029
0000002A
0000002B
0000002C
0000002D
0000002E
0000002F
00000030
00000031
00000032
00000033
00000034
00000035
00000036
00000037
00000038
00000039
0000003A
0000003B
0000003C

 4D 5A
 9000
 0300
 0000
 0400
 0000
 FFFF
 0000
 B800
 0000
 0000
 0000
 4000
 0000
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 00
 F0000000  

 ASCII "MZ"
 DW 0090
 DW 0003
 DW 0000
 DW 0004
 DW 0000
 DW FFFF
 DW 0000
 DW 00B8
 DW 0000
 DW 0000
 DW 0000
 DW 0040
 DW 0000
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DB 00
 DD 000000F0 

 DOS EXE Signature
 DOS_PartPag = 90 (144.)
 DOS_PageCnt = 3
 DOS_ReloCnt = 0
 DOS_HdrSize = 4
 DOS_MinMem = 0
 DOS_MaxMem = FFFF (65535.)
 DOS_ReloSS = 0
 DOS_ExeSP = B8
 DOS_ChkSum = 0
 DOS_ExeIP = 0
 DOS_ReloCS = 0
 DOS_TablOff = 40
 DOS_Overlay = 0
































 Offset to PE signature

I want to explain how we can plainly change the Offset of Entry Point (OEP) in our sample file, CALC.EXE of Windows XP. First, by using a PE Tool, and also using our PE Viewer, we find OEP, 0x00012475, and Image Base, 0x01000000. This value of OEP is the Relative Virtual Address, so the Image Base value is used to convert it to the Virtual Address.

DWORD OEP_RVA = image_nt_headers->OptionalHeader.AddressOfEntryPoint ; 
// OEP_RVA = 0x00012475

DWORD OEP_VA = image_nt_headers->OptionalHeader.ImageBase + OEP_RVA ; 
// OEP_VA = 0x01000000 + 0x00012475 = 0x01012475

PE Maker - Step 1

• Download source files - 54.7 Kb

CALC.EXE - test file

• Download test PE file - 49.5 Kb

DynLoader(), in loader.cpp, is reserved for the data of the new section, in other words, the Loader.

DynLoader Step 1

__stdcall void DynLoader()
{
_asm
{
//----------------------------------

    DWORD_TYPE(DYN_LOADER_START_MAGIC)
//----------------------------------

    MOV EAX,01012475h // << Original OEP

    JMP EAX
//----------------------------------

    DWORD_TYPE(DYN_LOADER_END_MAGIC)
//----------------------------------

}
}

Unfortunately, this source can only be applied for the sample test file. We should complete it by saving the value of the original OEP in the new section, and use it to reach the real OEP. I have accomplished it in Step 2 (Section 5).

4.1 Retrieve and Rebuild PE file

I have made a simple class library to recover PE information and to use it in a new PE file.

CPELibrary Class Step 1

//----------------------------------------------------------------

class CPELibrary 
{
private:
    //-----------------------------------------

    PCHAR                   pMem;
    DWORD                   dwFileSize;
    //-----------------------------------------

protected:
    //-----------------------------------------

    PIMAGE_DOS_HEADER       image_dos_header;
    PCHAR                   pDosStub;
    DWORD                   dwDosStubSize, dwDosStubOffset;
    PIMAGE_NT_HEADERS       image_nt_headers;
    PIMAGE_SECTION_HEADER   image_section_header[MAX_SECTION_NUM];
    PCHAR                   image_section[MAX_SECTION_NUM];
    //-----------------------------------------

protected:
    //-----------------------------------------

    DWORD PEAlign(DWORD dwTarNum,DWORD dwAlignTo);
    void AlignmentSections();
    //-----------------------------------------

    DWORD Offset2RVA(DWORD dwRO);
    DWORD RVA2Offset(DWORD dwRVA);
    //-----------------------------------------

    PIMAGE_SECTION_HEADER ImageRVA2Section(DWORD dwRVA);
    PIMAGE_SECTION_HEADER ImageOffset2Section(DWORD dwRO);
    //-----------------------------------------

    DWORD ImageOffset2SectionNum(DWORD dwRVA);
    PIMAGE_SECTION_HEADER AddNewSection(char* szName,DWORD dwSize);
    //-----------------------------------------

public:
    //-----------------------------------------

    CPELibrary();
    ~CPELibrary();
    //-----------------------------------------

    void OpenFile(char* FileName);
    void SaveFile(char* FileName);    
    //-----------------------------------------

};

By Table 1, the usage of image_dos_header, pDosStub, image_nt_headers, image_section_header [MAX_SECTION_NUM], and image_section[MAX_SECTION_NUM] is clear. We use OpenFile() and SaveFile() to retrieve and rebuild a PE file. Furthermore, AddNewSection() is employed to create the new section, the important step.

4.2 Create Data for new Section

In pecrypt.cpp, I have represented another class, CPECryptor, to comprise the data of the new section. Nevertheless, the data of the new section is created by DynLoader() in loader.cpp, DynLoader Step 1. We use the CPECryptor class to enter this data in to the new section, and also some other stuff.

CPECryptor Class Step 1

//----------------------------------------------------------------

class CPECryptor: public CPELibrary
{
private:
    //----------------------------------------

    PCHAR pNewSection;
    //----------------------------------------

    DWORD GetFunctionVA(void* FuncName);
    void* ReturnToBytePtr(void* FuncName, DWORD findstr);
    //----------------------------------------

protected:
    //----------------------------------------

public:    
    //----------------------------------------

    void CryptFile(int(__cdecl *callback) (unsigned int, unsigned int));
    //----------------------------------------

};
//----------------------------------------------------------------

4.3 Some notes regarding creating a new PE file

• Align the VirtualAddress and the VirtualSize of each section by SectionAlignment:

  image_section_header[i]->VirtualAddress=
      PEAlign(image_section_header[i]->VirtualAddress,
      image_nt_headers->OptionalHeader.SectionAlignment);
  
  image_section_header[i]->Misc.VirtualSize=
      PEAlign(image_section_header[i]->Misc.VirtualSize,
      image_nt_headers->OptionalHeader.SectionAlignment);

• Align the PointerToRawData and the SizeOfRawData of each section by FileAlignment:

  image_section_header[i]->PointerToRawData =
      PEAlign(image_section_header[i]->PointerToRawData,
              image_nt_headers->OptionalHeader.FileAlignment);
  
  image_section_header[i]->SizeOfRawData =
      PEAlign(image_section_header[i]->SizeOfRawData,
              image_nt_headers->OptionalHeader.FileAlignment);

• Correct the SizeofImage by the virtual size and the virtual address of the last section:

  image_nt_headers->OptionalHeader.SizeOfImage = 
            image_section_header[LastSection]->VirtualAddress +
            image_section_header[LastSection]->Misc.VirtualSize;

• Set the Bound Import Directory header to zero, as this directory is not very important to execute a PE file:

  image_nt_headers->
    OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT].
    VirtualAddress = 0;
  image_nt_headers->
    OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT].Size = 0;

4.4 Some notes regarding linking this VC Project

• Set Linker->General->Enable Incremental Linking to No (/INCREMENTAL:NO).

  

  You can comprehend the difference between incremental link and no-incremental link by looking at the following picture:

  

  To acquire the virtual address of DynLoader(), we obtain the virtual address of JMP pemaker.DynLoader in the incremental link, but by no-incremental link, the real virtual address is gained by the following code:

  DWORD dwVA= (DWORD) DynLoader;

  This setting is more critical in the incremental link when you try to find the beginning and ending of the Loader, DynLoader(), by CPECryptor::ReturnToBytePtr():

  void* CPECryptor::ReturnToBytePtr(void* FuncName, DWORD findstr)
  {
      void* tmpd;
      __asm
     {
          mov eax, FuncName
          jmp df
  hjg:    inc eax
  df:     mov ebx, [eax]
          cmp ebx, findstr
          jnz hjg
          mov tmpd, eax
      }
      return tmpd;
  }

5 Store Important Data and Reach Original OEP

Right now, we save the Original OEP and also the Image Base in order to reach to the virtual address of OEP. I have reserved a free space at the end of DynLoader() to store them, DynLoader Step 2.

PE Maker - Step 2

• Download source files - 58.3 Kb

DynLoader Step 2

__stdcall void DynLoader()
{
_asm
{
//----------------------------------

    DWORD_TYPE(DYN_LOADER_START_MAGIC)
//----------------------------------

Main_0:
    PUSHAD
    // get base ebp

    CALL Main_1
Main_1:    
    POP EBP
    SUB EBP,OFFSET Main_1
    MOV EAX,DWORD PTR [EBP+_RO_dwImageBase]
    ADD EAX,DWORD PTR [EBP+_RO_dwOrgEntryPoint]
    PUSH EAX
    RETN // >> JMP to Original OEP

//----------------------------------

    DWORD_TYPE(DYN_LOADER_START_DATA1)
//----------------------------------

_RO_dwImageBase:                DWORD_TYPE(0xCCCCCCCC)
_RO_dwOrgEntryPoint:            DWORD_TYPE(0xCCCCCCCC)
//----------------------------------

    DWORD_TYPE(DYN_LOADER_END_MAGIC)
//----------------------------------

}
}

The new function, CPECryptor::CopyData1(), will implement the copy of the Image Base value and the Offset of Entry Point value into 8 bytes of free space in the loader.

5.1 Restore the first Registers Context

It is important to recover the Original Context of the thread. We have not yet done it in the DynLoader Step 2 source code. We can modify the source of DynLoader() to repossess the first Context.

__stdcall void DynLoader()
{
_asm
{
//----------------------------------

    DWORD_TYPE(DYN_LOADER_START_MAGIC)
//----------------------------------

Main_0:
    PUSHAD// Save the registers context in stack

    CALL Main_1
Main_1:    
    POP EBP// Get Base EBP

    SUB EBP,OFFSET Main_1
    MOV EAX,DWORD PTR [EBP+_RO_dwImageBase]
    ADD EAX,DWORD PTR [EBP+_RO_dwOrgEntryPoint]
    MOV DWORD PTR [ESP+1Ch],EAX // pStack.Eax <- EAX

    POPAD // Restore the first registers context from stack

    PUSH EAX
    XOR  EAX, EAX
    RETN // >> JMP to Original OEP

//----------------------------------

    DWORD_TYPE(DYN_LOADER_START_DATA1)
//----------------------------------

_RO_dwImageBase:                DWORD_TYPE(0xCCCCCCCC)
_RO_dwOrgEntryPoint:            DWORD_TYPE(0xCCCCCCCC)
//----------------------------------

    DWORD_TYPE(DYN_LOADER_END_MAGIC)
//----------------------------------

}
}

5.2 Restore the Original Stack

We can also recover the original stack by setting the value of the beginning stack + 0x34 to the Original OEP, but it is not very important. Nevertheless, in the following code, I have accomplished the loader code by a simple trick to reach OEP in addition to redecorating the stack. You can observe the implementation by tracing using OllyDbg or SoftICE.

__stdcall void DynLoader()
{
_asm
{
//----------------------------------

    DWORD_TYPE(DYN_LOADER_START_MAGIC)
//----------------------------------

Main_0:
    PUSHAD // Save the registers context in stack

    CALL Main_1
Main_1:    
    POP EBP
    SUB EBP,OFFSET Main_1
    MOV EAX,DWORD PTR [EBP+_RO_dwImageBase]
    ADD EAX,DWORD PTR [EBP+_RO_dwOrgEntryPoint]
    MOV DWORD PTR [ESP+54h],EAX // pStack.Eip <- EAX

    POPAD // Restore the first registers context from stack

    CALL _OEP_Jump
    DWORD_TYPE(0xCCCCCCCC)
_OEP_Jump:
    PUSH EBP
    MOV EBP,ESP
    MOV EAX,DWORD PTR [ESP+3Ch] // EAX <- pStack.Eip

    MOV DWORD PTR [ESP+4h],EAX  // _OEP_Jump RETURN pointer <- EAX

    XOR EAX,EAX
    LEAVE
    RETN
//----------------------------------

    DWORD_TYPE(DYN_LOADER_START_DATA1)
//----------------------------------

_RO_dwImageBase:                DWORD_TYPE(0xCCCCCCCC)
_RO_dwOrgEntryPoint:            DWORD_TYPE(0xCCCCCCCC)
//----------------------------------

    DWORD_TYPE(DYN_LOADER_END_MAGIC)
//----------------------------------

}
}

5.3 Approach OEP by Structured Exception Handling

An exception is generated when a program falls into a fault code execution and an error happens, so in such a special condition, the program immediately jumps to a function called the exception handler from exception handler list of the Thread Information Block.

The next example of a try-except statement in C++ clarifies the operation of structured exception handling. Besides the assembly code of this code, it elucidates the structured exception handler installation, the raise of an exception, and the exception handler function.

#include "stdafx.h"

#include "windows.h"


void RAISE_AN_EXCEPTION()
{    
_asm
{
    INT 3
    INT 3
    INT 3
    INT 3
}
}

int _tmain(int argc, _TCHAR* argv[])
{
    __try
    {
        __try{
            printf("1: Raise an Exception\n");
            RAISE_AN_EXCEPTION();
        }
        __finally
        {
            printf("2: In Finally\n");
        }
    }
    __except( printf("3: In Filter\n"), EXCEPTION_EXECUTE_HANDLER )
    {
        printf("4: In Exception Handler\n");
    }
    return 0;
}

; main()
00401000: PUSH EBP
00401001: MOV EBP,ESP
00401003: PUSH -1
00401005: PUSH 00407160
; __try {
; the structured exception handler (SEH) installation 
0040100A: PUSH _except_handler3  
0040100F: MOV EAX,DWORD PTR FS:[0]
00401015: PUSH EAX
00401016: MOV DWORD PTR FS:[0],ESP
0040101D: SUB ESP,8
00401020: PUSH EBX
00401021: PUSH ESI
00401022: PUSH EDI
00401023: MOV DWORD PTR SS:[EBP-18],ESP
;     __try {
00401026: XOR ESI,ESI
00401028: MOV DWORD PTR SS:[EBP-4],ESI
0040102B: MOV DWORD PTR SS:[EBP-4],1
00401032: PUSH OFFSET "1: Raise an Exception"
00401037: CALL printf
0040103C: ADD ESP,4
; the raise a exception, INT 3 exception
; RAISE_AN_EXCEPTION()
0040103F: INT3      
00401040: INT3
00401041: INT3
00401042: INT3
;     } __finally {
00401043: MOV DWORD PTR SS:[EBP-4],ESI
00401046: CALL 0040104D
0040104B: JMP 00401080
0040104D: PUSH OFFSET "2: In Finally"
00401052: CALL printf
00401057: ADD ESP,4
0040105A: RETN
;     }
; }
; __except( 
0040105B: JMP 00401080
0040105D: PUSH OFFSET "3: In Filter"
00401062: CALL printf
00401067: ADD ESP,4
0040106A: MOV EAX,1 ; EXCEPTION_EXECUTE_HANDLER = 1
0040106F: RETN
;     , EXCEPTION_EXECUTE_HANDLER )
; {
; the exception handler funtion
00401070: MOV ESP,DWORD PTR SS:[EBP-18]
00401073: PUSH OFFSET "4: In Exception Handler"
00401078: CALL printf
0040107D: ADD ESP,4
; }
00401080: MOV DWORD PTR SS:[EBP-4],-1
0040108C: XOR EAX,EAX
; restore previous SEH
0040108E: MOV ECX,DWORD PTR SS:[EBP-10]
00401091: MOV DWORD PTR FS:[0],ECX
00401098: POP EDI
00401099: POP ESI
0040109A: POP EBX
0040109B: MOV ESP,EBP
0040109D: POP EBP
0040109E: RETN

Make a Win32 console project, and link and run the preceding C++ code, to perceive the result:

This program runs the exception expression, printf("3: In Filter\n");, when an exception happens, in this example the INT 3 exception. You can employ other kinds of exception too. In OllyDbg, Debugging options->Exceptions, you can see a short list of different types of exceptions.

5.3.1 Implement Exception Handler

We desire to construct a structured exception handler in order to reach OEP. Now, I think you have distinguished the SEH installation, the exception raise, and the exception expression filter, by foregoing the assembly code. To establish our exception handler approach, we need to comprise the following codes:

• SEH installation:

      LEA EAX,[EBP+_except_handler1_OEP_Jump]
      PUSH EAX
      PUSH DWORD PTR FS:[0]
      MOV DWORD PTR FS:[0],ESP

• An Exception Raise:

      INT 3

• Exception handler expression filter:

  _except_handler1_OEP_Jump:
      PUSH EBP
      MOV EBP,ESP
      ...
      MOV EAX, EXCEPTION_CONTINUE_SEARCH // EXCEPTION_CONTINUE_SEARCH = 0
      LEAVE
      RETN

So we yearn for making the ensuing C++ code in assembly language to inaugurate our engine to approach the Offset of Entry Point by SEH.

__try // SEH installation

{
    __asm 
    {
        INT 3 // An Exception Raise

    }
}
__except( ..., EXCEPTION_CONTINUE_SEARCH ){}
// Exception handler expression filter

In assembly code...

    ; ----------------------------------------------------

    ; the structured exception handler (SEH) installation

    ; __try {

    LEA EAX,[EBP+_except_handler1_OEP_Jump]
    PUSH EAX
    PUSH DWORD PTR FS:[0]
    MOV DWORD PTR FS:[0],ESP
    ; ----------------------------------------------------

    ; the raise a INT 3 exception

    INT 3
    INT 3
    INT 3
    INT 3
    ; }

    ; __except( ... 

    ; ----------------------------------------------------

    ; exception handler expression filter

_except_handler1_OEP_Jump:
    PUSH EBP
    MOV EBP,ESP
    ... 
    MOV EAX, EXCEPTION_CONTINUE_SEARCH ; EXCEPTION_CONTINUE_SEARCH = 0

    LEAVE
    RETN
    ; , EXCEPTION_CONTINUE_SEARCH ) { }

The exception value, __except(..., Value), determines how the exception is handled, it can have three values, 1, 0, -1. To understand them, refer to the try-except statement description in the MSDN library. We set it to EXCEPTION_CONTINUE_SEARCH (0), not to run the exception handler function, therefore by this value, the exception is not recognized, is simply ignored, and the thread continues its code-execution.

How the SEH installation is implemented

As you perceived from the illustrated code, the SEH installation is done by the FS segment register. Microsoft Windows 32 bit uses the FS segment register as a pointer to the data block of the main thread. The first 0x1C bytes comprise the information of the Thread Information Block (TIB). Therefore, FS:[00h] refers to ExceptionList of the main thread, Table 3. In our code, we have pushed the pointer to _except_handler1_OEP_Jump in the stack and changed the value of ExceptionList, FS:[00h], to the beginning of the stack, ESP.

Thread Information Block (TIB)

typedef struct _NT_TIB32 {
    DWORD ExceptionList;
    DWORD StackBase;
    DWORD StackLimit;
    DWORD SubSystemTib;
    union {
        DWORD FiberData;
        DWORD Version;
    };
    DWORD ArbitraryUserPointer;
    DWORD Self;
} NT_TIB32, *PNT_TIB32;

Table 3 - FS segment register and Thread Information Block

5.3.2 Attain OEP by adjusting the Thread Context

In this part, we effectuate our performance by accomplishing the OEP approach. We change the Context of the thread and ignore every simple exception handling, and let the thread continue the execution, but in the original OEP!

When an exception happens, the context of the processor during the time of the exception is saved in the stack. By EXCEPTION_POINTERS, we have access to the pointer of ContextRecord. The ContextRecord has the CONTEXT data structure, Table 4, this is the thread context during the exception time. When we ignore the exception by EXCEPTION_CONTINUE_SEARCH (0), the instruction pointer as well the context will be set to ContextRecord in order to return to the previous condition. Therefore, if we change the Eip of the Win32 Thread Context to the Original Offset of Entry Point, it will come clearly into OEP.

    MOV EAX, ContextRecord
    MOV EDI, dwOEP                   ; EAX <- dwOEP

    MOV DWORD PTR DS:[EAX+0B8h], EDI ; pContext.Eip <- EAX

Win32 Thread Context structure

#define MAXIMUM_SUPPORTED_EXTENSION     512

typedef struct _CONTEXT {
    //-----------------------------------------

    DWORD ContextFlags;
    //-----------------------------------------

    DWORD   Dr0;
    DWORD   Dr1;
    DWORD   Dr2;
    DWORD   Dr3;
    DWORD   Dr6;
    DWORD   Dr7;
    //-----------------------------------------

    FLOATING_SAVE_AREA FloatSave;
    //-----------------------------------------

    DWORD   SegGs;
    DWORD   SegFs;
    DWORD   SegEs;
    DWORD   SegDs;
    //-----------------------------------------

    DWORD   Edi;
    DWORD   Esi;
    DWORD   Ebx;
    DWORD   Edx;
    DWORD   Ecx;
    DWORD   Eax;
    //-----------------------------------------

    DWORD   Ebp;
    DWORD   Eip;
    DWORD   SegCs;
    DWORD   EFlags;
    DWORD   Esp;
    DWORD   SegSs;
    //-----------------------------------------

    BYTE    ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];
    //----------------------------------------

} CONTEXT, 
*LPCONTEXT;

Table 4 - CONTEXT