I just started working my way to reversing Windows binaries and I stumbled upon the Import Address Table. When reversing a particular DLL I encountered many thunk-functions which all supposedly referenced the IAT. From my experience on Linux I guessed that this is somewhat similar to the procedure linkage table (or rather the global offset table I suppose). Based on that I would assume that the linking process is similar, though I cannot seem to find detailed information on that. Any help would be appreciated.
Furthermore I was wondering whether you could resolve these thunks without ever running the binary. In particular because it is in fact a DLL that I am analyzing the information to resolve these should be available already? Though I cannot really make sense out of the information available.
Just to be sure I am not completely off, here is an example of what I am talking about:
Memory at the address (in section
0x18005ba68: 94 00 00 06 00 00 00 00
Edit: Thanks for the input. I now feel like I misunderstood the purpose of the IAT. So consider the following scenario: We have a PE executable A which imports symbols from a DLL B.
- The import directory table is used in A, whereas in B a corresponding entry has to be found in the export directory table. Is that correct?
- In the DLL (B) I am investigating the thunks mentioned are neither imported nor exported symbols. So what may I be witnessing?
- The overall process must be looking something like this:
- A is executed. All needed DLLs are searched and linked (this is called binding in this context?)
- This causes B to be actually loaded at some address. Now symbols from B in A can be resolved (using the import directory table). Is B necessarily position independent? I read about preferred base addresses and conditional re-location of the whole binary if it cannot be matched. Is this still correct?
- I still do not see a point why the second layer jump table I encountered is needed.