Import Libraries are dlls that an executable image are bound to. Much of windows core functionailty is found in Dlls that MS provides and is how applications interact with the base windows services. Function addresses in the binary file of a dll are not static, as new versions come out they are destined to change, so applications cannot be built using a hardcoded function address.

When an executable is first loaded, the Windows loader is responsible for reading in the files PE structure and loading the executable image into memory. One of the other steps it takes is to load all of the dlls that the application uses and map them into the process address space. The executable also lists all of the functions it will require from each dll. Because the function addresses are not static a mechanism had to be developed that allowed for the these variables to be changed without needing to alter all of the compiled code at runtime. This was accomplished through the use of an import address table. This is a table of function pointers filled in by the windows loader as the dlls are loaded. When the application was first compiled, it was designed so that all API calls will not use direct hardcoded addresses but rather work through a function pointer. Conventially this pointer table can be accessed in several ways. Either directly by a call[pointer address] or via a jmp thunk table.

Exercise

1. Download the example file and tutorial by Sunshine a.k.a Bastian Molkenthin. Read the tutorial and play with the example file included with the download.
2. Download the Mapping Exercise Module (with 96 exercises) from the Binary Auditor package. Take the first exercise (a01_identify_variables.exe) and analyse this file. Can you get the same findings as in the tutorial or is there any difference?