PE File Format (5-2)-Improt Table (import Table)

Now we know how to find the imported table. The VirtualAddress of the second item in the Data Directory array contains the table address. The imported table is actually an array of IMAGE_IMPORT_DESCRIPTOR structures. Each structure contains information about a DLL related to the function introduced by the PE file. For example, if the PE file imports functions from 10 different DLL files, the array has 10 members. The array ends with a member of all 0. The following detailed research structure:

IMAGE_IMPORT_DESCRIPTOR STRUCT
Union
Characteristics dd?
OriginalFirstThunk dd?
Ends
TimeDateStamp dd?
ForwarderChain dd?
Name1 dd?
FirstThunk dd?
IMAGE_IMPORT_DESCRIPTOR ENDS

The first element of the structure is a Union sub-structure. In fact, this Union sub-structure only adds an alias to originalfirstthunk. You can also call it characteristics ". This member item points to an RVA pointing to a DWORD array. Every DWORD in the array is actually an image_thunk_data union. So what is image_thunk_data? Each image_thunk_data Union corresponds to an input function. The content of this DWORD (that is, image_thunk_data Union) depends on whether the file is loaded (that is, the content before and after loading is different, and the reason will be explained later ), and the function is input by name or serial number (that is, the input method is different and the content is different ). Input by name is a common method. When a function is input by serial number, the highest bit (0x80000000) in image_thunk_data DWORD of the EXE file is set up. For example, consider an image_thunk_data with a value of 0x80000112 in the gdi32.dll array. This image_thunk_data will input the output (exported) function in gdi32.dll. If the function is input by name, image_thunk_data DWORD contains a RVA (relative virtual address), pointing to the image_import_by_name structure. Because an input function corresponds to an image_thunk_data union, when the function is input by name, image_thunk_data points to another image_import_by_name structure. Therefore, an input function corresponds to an image_import_by_name structure. Now let's take a look at some things in the image_import_by_name structure. We hope there will be information about the introduced function. AO, it was as expected:

Image_import_by_name struct
Hint DW?
Name1 DB?
Image_import_by_name ends

Hint indicates the index number of the function in the output table where the DLL resides. This field is used by the PE Loader to quickly query functions in the DLL export table.
Name1 contains the name of the function to be introduced. The function name is an ASCIIZ string. Now let's take a look at this: if the program calls N input functions, there are N IMAGE_IMPORT_BY_NAME structures. We collect the RVA of these structures and put them in the IMAGE_THUNK_DATA structure to form an array, end with 0, and then put the RVA of this array into OriginalFirstThunk. In this way, we can use the OriginalFirstThunk line to pull all the functions called from a DLL.

Sorry, we were interrupted by the IMAGE_IMPORT_BY_NAME structure just now. Now let's return to the IMAGE_IMPORT_DESCRIPTOR structure and continue to look at other fields in it. To maintain consistency with the above discussion, let's take a look at the last domain FirstThunk. FirstThunk is very similar to OriginalFirstThunk and is also a RVA, it also points to an IMAGE_THUNK_DATA structure array (of course, this is another IMAGE_THUNK_DATA structure array, but the IMAGE_THUNK_DATA structure array and the IMAGE_THUNK_DATA structure array pointed by OriginalFirstThunk are exactly the same ). Let's straighten out: Now there are several IMAGE_IMPORT_BY_NAME structures, and you have created two structure arrays and saved the RVA pointing to those IMAGE_IMPORT_BY_NAME structures, in this way, the two arrays contain the same value (which can be quite accurate ). Finally, you decide to assign the RVA of the first array to OriginalFirstThunk, And the RVA of the second array to FirstThunk, so that everything is clear. If you feel dizzy about the relationship between the above pile of RVA and the structure array, let's take a look at it. The figure below may help you stay awake:

OriginalFirstThunk

IMAGE_IMPORT_BY_NAME

FirstThunk

|

|

Image_thunk_data

Image_thunk_data

Image_thunk_data

Image_thunk_data

...

Image_thunk_data

--->

--->

--->

--->

--->

--->

Function 1

Function 2

Function 3

Function 4

...

Function n

<---

<---

<---

<---

<---

<---

Image_thunk_data

Image_thunk_data

Image_thunk_data

Image_thunk_data

...

Image_thunk_data

Now you should understand what I mean. Do not be confused by the IMAGE_THUNK_DATA name: When a function is introduced by name, it only points to the rva of the IMAGE_IMPORT_BY_NAME structure. If you think of IMAGE_THUNK_DATA as RVA, it is easier to understand. The size of the OriginalFirstThunk and FirstThunk arrays depends on the number of functions introduced from the DLL in the PE file. For example, if the PE file introduces 10 functions from kernel32.dll, The Name1 field of the IMAGE_IMPORT_DESCRIPTOR structure contains the RVA pointing to the string "kernel32.dll", and each IMAGE_THUNK_DATA array has 10 elements.