Prior to this, we have done some practice and understanding of this input table, which will help you to further deepen the understanding of this concept. The Little Turtle thought, the more complex the problem we should go to operate it, know it, it is easy to know it!
In the last lesson we like the same as a deer bump, and finally hit the input table contains the function name, hey, but the address, we still can not find ... In this lesson we will delve into the structure of the input table and help you understand how the input table works by combining example analysis.
Input Table Structure
in retrospect, the second member of the DataDirectory (Data Catalog table) in the image_optional_header structure of the PE file header points to the input table. The input table starts with an array of image_import_descriptor (the IID). Each DLL file that is linked in by a PE file corresponds to a IID array structure. In this IID array, there is no indication of the number of items (that is, how many linked files are not explicitly indicated), but it ends with an all-null (0) IID.
The image_import_descriptor structure is defined as follows:
It points to first Thunk,image_thunk_data, which has the address of Hint and Function name.
The field can be ignored. If there is a binding, it contains the time/data stamp (Time/data stamp). If it is 0, there is no binding to occur in the DLL being imported. Recently, it was set to 0xFFFFFFFF to indicate that the binding occurred.
In general, we can also ignore this field. In the old version of the binding, it refers to the API's first forwarder chain (the list of transitive chains). It can be set to 0xFFFFFFFF to represent no forwarder.
It represents the relative virtual address of the DLL name, which is the name of the imported DLL file (for example: KERNEL32.DLL), relative to an RVA of an ASCII string with NULL as the Terminator.
it contains the virtual address of the first THUNK array defined by Image_thunk_data, initialized THUNK with a function virtual address by loader. In the absence of orignal first thunk, it points to the thunks of first thunk:hints and the Function names.
this Originalfirstthunk andFirstthunk obviously is in-laws, two guys first name is almost ha. So what are they hiding from? Here, let's take a look at the following picture (the painting is very hard, we look at the ha):
we see: Originalfirstthunk andFirstthunk They're all two. An array of type Image_thunk_data, which is a pointer-size union (union) type. Each IMAGE_THUNK_DATA structure defines an import function information (that is, the guy that points to the structure of Image_import_by_name, which the guy will discuss later), and then the array ends with a content of 0 Image_thunk_data Structure as the end flag.
we get the IMAGE_THUNK_DATA structure is defined as follows:
forwarderstring DWORD? ; RVA pointing to the string of a steering person
Function DWORD? ; The memory address of the function being entered
Ordinal DWORD? ; The ordinal value of the API being entered
addressofdata DWORD? ; point to Image_import_by_name
We can see that because of the union structure, Image_thunk_data is actually a double-word size. The structure is endowed with different meanings at different times (great wonder no bird ...). ）。 In fact, this data structure of union is easy to understand: plainly is poor, can save the province, and then plainly, is a few brothers and sisters take turns wearing a pair of trousers to Blind date! You understand? haha ~
So how do we tell what it means to be when?
The provisions are as follows:
When the highest bit of the Image_thunk_data value is 1 o'clock, the function is entered as an ordinal, when the lower 31 bits are treated as a function ordinal.
Whenthe highest bit of the Image_thunk_data value is 0 o'clock, which indicates that the function is entered as a function name of the string type, when the value of the double word is a RVA, pointing to a image_import_by_name structure. (demo, see the Little Turtle Decryption Series video lectures)
Okay, then we'll talk about the point.image_import_by_name Structure. image_import_by_name structure is only the size of one font data, and there is an information structure of input function. The structure is as follows:
The Hint field in the struct also represents the ordinal of the function, but this field is optional, and some compilers always set it to the 0,name field to define the name string for the import function, which is a string ending with 0.
the whole process looks a little bit annoying, don't worry, behind we have a demo ha.
Input Address Table (IAT)
Why is the two parallel pointer array pointing at the image_import_by_name structure at the same time? The first array (which is pointed to by Originalfirstthunk) is a separate item and cannot be rewritten, which we call INT. The second array (pointed to by Firstthunk) is actually written by the PE loader.
Okay, so what about the core operation of the PE loader? Here is the secret to everyone ~
The PE Loader first searches for originalfirstthunk, finds each pointer in the array after the loader iterates, finds the address of the input function pointed to by each image_import_by_name structure, and then loads the actual entry address of the function to replace the Firstthunk an entry in the array, so we call it the Input Address table (IAT). So, when our PE file is ready to be executed after loading the memory, the image is converted to:
at this point, the other parts of the input table are unimportant, and the program relies on the function address provided by the IAT to run normally.
Input Table Instance Analysis: (The process will be shown in the video, here is not verbose ~)
Tools: PEinfo.exe, UltraEdit, LORDPE
Anatomy object: Hello.exe
Small turtle PE detailed input table (import table) 2 (PE detailed 08)