The important tables in the PE file are: 1. Export table, 2. Import table, 3. IAT table, 4. Relocation table, 5. Resource table
Import table structure:
typedef struct _IMAGE_IMPORT_DESCRIPTOR { union { DWORD Characteristics; // 0 for terminating null import descriptor DWORD OriginalFirstThunk; // RVA to original unbound IAT (PIMAGE_THUNK_DATA) }; DWORD TimeDateStamp; // 0 if not bound, // -1 if bound, and real date\time stamp // in IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT (new BIND) // O.W. date/time stamp of DLL bound to (Old BIND) DWORD ForwarderChain; // -1 if no forwarders DWORD Name; DWORD FirstThunk; // RVA to IAT (if bound this IAT has actual addresses) } IMAGE_IMPORT_DESCRIPTOR; typedef IMAGE_IMPORT_DESCRIPTOR UNALIGNED *PIMAGE_IMPORT_DESCRIPTOR;
There are not many members of the above structure, and the only useful members are the first union member, the fourth dll name, and the fifth FirstThunk (ITA table head address).
The detailed explanation is as follows:
1) Although the first member is a union, the commonly used type is the second member DWORD OriginalFirstThunk in the union. You can see that it is
very similar to the fifth member variable when you see the name. They record THUNK_DATA The RVA of the table, in fact, the type of the first and last members of the above structure can be changed to PIMAGE_THUNK_DATA,
but the reason why it has not been changed, I think the reason is that the RVA pointed to by the fifth member is also the address of the IAT table, and the IAT table uses It is used to fill in the API address pointer, and the function pointer types are different, so
the DWORD table type is uniformly used. Of course, it is reasonable to use LPVOID. Or it can be understood that OriginalFirstThunk and FirstThunk should be
PIMAGE_THUNK_DATA in the file, but they are LPVOID or DWORD after they are loaded into memory.
Let's take a look at what type of pointer PIMAGE_THUNK_DATA is,
typedef struct _IMAGE_THUNK_DATA32 { union { PBYTE ForwarderString; PDWORD Function; DWORD Ordinal; PIMAGE_IMPORT_BY_NAME AddressOfData; } u1; } IMAGE_THUNK_DATA32; typedef IMAGE_THUNK_DATA32 * PIMAGE_THUNK_DATA32;
Although the above structure seems to be huge, in fact, there is only one member in it, which is equivalent to the size of a DWORD type. The commonly used types in the union are
DWORD Ordinal and PIMAGE_IMPORT_BY_NAME AddressOfData. As for whether it is a serial number or a name, through the The highest bit of the value is obtained. If the highest bit is 1,
it indicates the serial number, and the serial number is stored in the last two bytes. In fact, it also means that the serial number export can only export 65536 functions. If the highest bit is 0, it indicates that it is the API name. Export,
but the value does not directly point to the address of the API name, but points to a structure, a flexible array as follows:
typedef struct _IMAGE_IMPORT_BY_NAME { WORD Hint; BYTE Name[1]; } IMAGE_IMPORT_BY_NAME, *PIMAGE_IMPORT_BY_NAME;
The first two-byte member is rarely used, and the second one is used directly, that is, the API name address. PIMAGE_THUNK_DATA is as described above
. If there is a value in OriginalFirstThunk and FirstThunk, it will be parsed as above. There is only one PIMAGE_THUNK_DATA table in the import table corresponding to a dll, which means that the content in the files pointed to by OriginalFirstThunk and FirstThunk is the same, and because FirstThunk is still an IAT table, it is the same as the content pointed to by
the 12th of the data directory in the Nt header.
it's the same.
Now there is another question, which member is the data that the system points to when loading the PE file? In fact, first look at
whether exists. If it is not or it is a wrong value (manually modified by someone), then the data in FirstThunk may not be read or it may not be loaded. When
neither OriginalFirstThunk nor FirstThunk point to the PIMAGE_THUNK_DATA data, it must be It cannot be loaded. In addition, when the data pointed to in OriginalFirstThunk is correct, it
is also possible to change FirstThunk to other valid data. The PIMAGE_THUNK_DATA table pointed to is zero-terminated, and loading to 0 loads the next import table.
2) The fourth member variable of IMAGE_IMPORT_DESCRIPTOR is the name of the dll, which is very important and cannot be corrected, otherwise it cannot be loaded. One dll corresponds to one import table.