PE file structure (4) PE import table

PE file structure description (2) an array is displayed at the end of the executable file header. PE file structure description (3) the PE export table explains the format of the first item, this article will reveal the second item in this array: image_directory_entry_import, that is, the import table.

You may have noticed that the names of several items in image_data_directory are related to the import table, including: image_directory_entry_import, image_directory_entry_bound_import, image_directory_entry_iat, and category, what is the relationship between them? Listen to me.

• Image_directory_entry_import is the import table we usually know. When loading a PE file, it loads the dependent DLL according to the content in the table and fills in the address of the required function.
• Image_directory_entry_bound_import is called binding an import table. The correction of the first import table import address is completed during PE loading, if a PE file imports many DLL or functions, the loading will be a little slow, so the bound import will occur, and the import table will be corrected before loading, this will be faster.
• Image_directory_entry_delay_import is called a delayed import table. a pe file may provide many functions and many other DLL files are imported, but not all functions provided by image_directory_entry_delay_import are used every time a file is loaded, it may not necessarily use all the DLL files that need to be imported, so delayed import will occur. This dll will be loaded only when the required DLL is actually used in a PE file, this function address is corrected only when an import function is actually used.
• Image_directory_entry_iat is the import address table. The first three tables are actually descriptions of the import function. The real function address is filled in the import address table.

Let's take a practical example and look at the figure below:

This Code calls a regopenkeyw import function. We can see that its opcode is FF 15 00 00 00 19 30 temperament FF 15, which indicates this is an indirect call, that is, call dword ptr [30190000]; this indicates that the address to be called is stored in the address 30190000, and the address 30190000 is within the range of the import address table. When the module is loaded, the PE Loader will modify the content in memory 30190000 based on the information described in the import table.

So what information is recorded in the import table? How can I modify IAT based on the information? Let's take a look at the definition of the import table:

 

[CPP]View plaincopy

1. Typedef struct _ image_import_descriptor {
2. Union {
3. DWORD characteristics; // 0 for terminating null import Descriptor
4. DWORD originalfirstthunk; // RVA to original unbound IAT (pimage_thunk_data)
5. } Dummyunionname;
6. DWORD timedatestamp; // 0 if not bound,
7. //-1 if bound, and real date \ time stamp
8. // In image_directory_entry_bound_import (New bind)
9. // O. W. date/time stamp of DLL bound to (old bind)
11. DWORD forwarderchain; //-1 if no forwarders
12. DWORD name;
13. DWORD firstthunk; // RVA to IAT (if bound this IAT has actual addresses)
14. } Image_import_descriptor;
15. Typedef image_import_descriptor unaligned * pimage_import_descriptor;

When you use rtlimagedirectoryentrytodata and pass the index number to 1, you will get a pointer to the above structure, which actually points to an array of the above structure. Each imported dll will become one of the arrays, that is, such a structure corresponds to an imported DLL.

Characteristics and originalfirstthunk: A consortium. If the last characteristics of the array is 0, otherwise originalfirstthunk saves an RVA and points to an image_thunk_data array, each of which represents an import function.

Timedatestamp: Before the image is bound, the value is 0, and the timestamp of the import module is used after the image is bound.

Forwarderchain: the forwarding chain. If there is no forwarder, the value is-1.

Name: An RVA that points to the name of the import module. Therefore, an image_import_descriptor describes an imported DLL.

Firstthunk: it is also an RVA and also points to an image_thunk_data array.
Since originalfirstthunk and firstthunk both point to an image_thunk_data array, and the names of these two fields are very similar, what is the difference between them? To answer this question, let's first look at the image_thunk_data structure:

 

[CPP]View plaincopy

1. Typedef struct _ image_thunk_data32 {
2. Union {
3. DWORD forwarderstring; // pbyte
4. DWORD function; // pdword
5. DWORD ordinal;
6. DWORD addressofdata; // pimage_import_by_name
7. } U1;
8. } Image_thunk_data32;
9. Typedef image_thunk_data32 * pimage_thunk_data32;

Forwarderstring is used for forwarding. For the moment, function indicates the function address. It is useful to import ordinal by sequence number. If it is imported by name, addressofdata points to the name information. We can see that this struct is a large union. We all know that a Union contains multiple domains but represents different meanings at different times. Should it be a name or a serial number? How should we differentiate it? It can be determined by ordinal that if the highest bit of ordinal is 1, it is imported by sequence number. At this time, the lowest 16 bits is the import sequence number. If the highest bit is 0, addressofdata is an RVA, point to an image_import_by_name structure to save name information. Because ordinal and addressofdata are actually in the same memory space, addressofdata can only represent RVA with 31 lower bits, however, a PE file cannot exceed 2 GB, so the maximum bit is always 0, which makes reasonable use of space. When writing the code, Microsoft provides two macro-defined processing sequence numbers for import: image_snap_by_ordinal to determine whether to import data by sequence number. image_ordinal is used to obtain the import sequence number.

In this case, we can look back at the image_thunk_data array pointed to by marker and firstthunk. The image_thunk_data array pointed to by originalfirstunk contains the import information. In this array, only ordinal and addressofdata are useful. Firstthunk is slightly different. Before the PE file is loaded or before the import table is not processed, the array it points to is not the same as the array in originalfirstthunk, but the content is the same, all include the import information. After loading, the function in firstthunk takes effect and points to the actual function address. Because firstthunk actually points to a position in IAT, IAt acts as the image_thunk_data array, after loading, these IAT items become the actual function address, that is, the meaning of the function. Compare the previous figure:

Is before loading.

Is loaded.

Summary:

1. The import table is actually an array of image_import_descriptor. Each imported DLL corresponds to an image_import_descriptor.
2. Image_import_descriptor contains two image_thunk_data arrays, each of which corresponds to an import function.
   
3. The arrays of originalfirstthunk and firstthunk before loading all point to the name information. After loading, the firstthunk array points to the actual function address.

PE file structure (4) PE import table