In the Windows Portable Executable (PE) format, the image import descriptor table describes the functions imported from a specific target DLL.<\/p>\n
struct IMAGE_IMPORT_DESCRIPTOR {\r\n DWORD OriginalFirstThunk;\r\n DWORD TimeDateStamp;\r\n DWORD ForwarderChain;\r\n DWORD Name;\r\n DWORD FirstThunk;\r\n};\r\n<\/pre>\nThe OriginalFirstThunk<\/code> points to an array of pointer-sized IMAGE_THUNK_DATA<\/code> structures which describe the functions being imported. The FirstThunk<\/code> points to an array of pointers, whose initial values are a copy of the values pointed to by OriginalFirstThunk<\/code>. When the DLL is loaded, those initial values in the FirstThunk<\/code> table are replaced by the actual function pointers determined at runtime.<\/p>\nBut why are there two copies of the table? The two tables are never needed at the same time, so why not reuse the memory? When the DLL is initially loaded, the entries describe the functions being imported, and after the function addresses are located, they could be written back into the same table.<\/p>\n
The answer is DLL binding<\/a>.<\/p>\nAs a load-time optimization, you can bind<\/i> your DLL to its targets. If the target DLL has 0x20304000<\/code> as its preferred base address, then if the DLL gets loaded at that preferred base address, you know what all the function addresses are going to be, and binding<\/i> records those precalculated function addresses into the FirstThunk<\/code> table. After binding is performed, the FirstThunk<\/code> table now holds the precalculated function addresses and is not a copy of the OriginalFirstThunk<\/code> table. The module timestamp of the DLL that was used to calculate the bindings is recorded in the image import directory.\u00b9<\/p>\nWhen the DLL is loaded, the loader checks whether the module timestamp recorded in the image import descriptor matches the timestamp of the actual module found at runtime. If so, then it just uses the precalculated values in the FirstThunk<\/code> table. And if not, then the loader uses the OriginalFirstThunk<\/code> table to look up the functions at runtime.<\/p>\nTherefore, you can’t combine the OriginalFirstThunk<\/code> and FirstThunk<\/code> tables: If the precalculated values in the FirstThunk<\/code> table cannot be used, you need to go back to the original values in OriginalFirstThunk<\/code> to resolve the imports the old-fashioned way.<\/p>\nBonus chatter<\/b>: Binding is of relatively little value nowadays due to address space layout randomization<\/a>.<\/p>\n