Tutorial 6: Import Table
We will learn about import table in this tutorial. Let me warn you first. This tutorial is a long and difficult one for those who are not familiar with the import table. You may need have to to read this tutorial several times and may even Examine The Related Structures Under a debugger.
Download The Example.
THEORY:
First of all, you should know what an import function is. An import function is a function that is not in the caller's module but is called by the module, thus the name "import". The import functions actually reside in one or more DLLs . Only the information about the functions is kept in the caller's module. That information includes the function names and the names of the DLLs in which they reside. Now how can we find out where in the PE file the information is kept? We must turn To The Data Directory for the Answer. I'll Refresh Your Memory A bit. Below is The PE header:
Image_nt_headers STRUCT SIGNATURE DD? FileHeader Image_File_Header <> OptionalHeader Image_Optional_Header <> iMage_NT_HEADERS Ends
The Last Member of The Optional Header Is The Data Directory:
Image_optional_header32 structure .... loaderflags dd? Numberofrvaandsizes DD? DataDirectory image_data_directory 16 DUP (<>) image_optional_header32 Ends
The data directory is an array of IMAGE_DATA_DIRECTORY structure. A total of 16 members. If you remember the section table as the root directory of the sections in a PE file, you should also think of the data directory as the root directory of the logical components stored inside those sections. To be precise, the data directory contains the locations and sizes of the important data structures in the PE file. Each member contains information about an important data structure.Member
INFO INSIDE
0
Export Symbols
1
Import Symbols
2
Resources
3
EXCEPTION
4
Security
5
Base Relocation
6
Debug
Seduce
Copyright String
8
Unknown
9
Thread Local Storage (TLS)
10
Load Configuration
11
Bound IMPORT
12
Import address Table
13
Delay Import
14
Com descriptor
Only the members painted in gold are known to me Now that you know what each member of the data directory contains, we can learn about the member in detail Each member of the data directory is a structure called IMAGE_DATA_DIRECTORY which has the following definition..:
Image_data_directory STRUCT VIRTUALADDRESS DD? ISIZE DD? Image_Data_directory Ends
VirtualAddress is actually the relative virtual address (RVA) of the data structure. For example, if this structure is for import symbols, this field contains the RVA of the IMAGE_IMPORT_DESCRIPTOR array. Isize contains the size in bytes of the data structure referred to by VirtualAddress .
Here's The General Scheme ON Finding Important Data Structures in a pe file:
From the DOS header, you go to the PE header Obtain the address of the data directory in the optional header Multiply the size of IMAGE_DATA_DIRECTORY with the member index you want:. For example if you want to know where the import symbols are, you must multiply the size of IMAGE_DATA_DIRECTORY (8 bytes) with 1. Add the result to the address of the data directory and you have the address of the IMAGE_DATA_DIRECTORY structure that contains the info about the desired data structure.Now we will enter into the real discussion about the import table. The address of the import table is contained in the VirtualAddress field of the second member of the data directory. The import table is actually an array of IMAGE_IMPORT_DESCRIPTOR structures. Each structure contains information about a DLL the PE file imports symbols from. For Example, IF The PE File Imports Functions from 10 Different Dlls, There Will Be 10 Members in this array. The array is terminated by The Member Which Contain All Zeroe s. Now We can Examine The structure in detail:
Image_import_descriptor STRUCT UNION CHARACTERISTICS DD? ORIGINALFIRSTHUNK DD? ENDS TIMEDATESTAMP DD? FORWARDERCHAIN DD? NAME1 DD? FIRSTHUNK DD? Image_Import_Descriptor Ends
The first member of this structure is a union. Actually, the union only provides the alias for OriginalFirstThunk, so you can call it "Characteristics". This member contains the the RVA of an array of IMAGE_THUNK_DATA structures. What is IMAGE_THUNK_DATA? It's a union of dword size Usually, we interpret it as the pointer to an IMAGE_IMPORT_BY_NAME structure Note that IMAGE_THUNK_DATA contains the pointer to an IMAGE_IMPORT_BY_NAME structure:.. not the structure itself Look at it this way:. There are several IMAGE_IMPORT_BY_NAME structures We collect the RVA of. those structures (IMAGE_THUNK_DATAs) into an array, terminate it with 0. Then we put the RVA of the array into OriginalFirstThunk.The IMAGE_IMPORT_BY_NAME structure contains information about an import function Now let's see what IMAGE_IMPORT_BY_NAME structure looks like:. IMAGE_IMPORT_BY_NAME STRUCT Hint dw Name1? DB? image_import_by_name ends
Hint contains the index into the export table of the DLL the function resides in. This field is for use by the PE loader so it can look up the function in the DLL's export table quickly.This value is not essential and some linkers may set the value in this field to 0.Name1 contains the name of the import function. The name is an ASCIIZ string. Note that Name1's size is defined as byte but it's really a variable-sized field. It's just that there is no way to represent a .
.
Name1 contains the RVA to the name of the DLL, in short, the pointer to the name of the DLL. The string is an ASCIIZ one.FirstThunk is very similar to OriginalFirstThunk, ie. It contains an RVA of an array of IMAGE_THUNK_DATA structures ( a different array though) Ok, if you're still confused, look at it this way:.. There are several IMAGE_IMPORT_BY_NAME structures you create two arrays, then fill them with the RVAs of those IMAGE_IMPORT_BY_NAME structures, so both arrays contain exactly the same Values (IE Exact Duplicate). Now You Assign To OriginalFirstthunk and the RVA of The Second Array To Firstthunk.
OriginalFirstthunkImage_import_by_namefirstthunk |
|
Image_thunk_data
Image_thunk_data
Image_thunk_data
Image_thunk_data
...
Image_thunk_data
---> ---> ---> ---> ---> --->
Function 1
Function 2
Function 3
Function 4
...
Function N
<--- <--- <--- <--- <--- <---
Image_thunk_data
Image_thunk_data
Image_thunk_data
Image_thunk_data
...
Image_thunk_data
Now you should be able to understand what I mean Do not be confused by the name IMAGE_THUNK_DATA:.. It's only an RVA into IMAGE_IMPORT_BY_NAME structure If you replace the word IMAGE_THUNK_DATA with RVA in your mind, you'll perhaps see it more clearly. The number of array elements in OriginalFirstThunk and FirstThunk array depends on the functions the PE file imports from the DLL. For example, if the PE file imports 10 functions from kernel32.dll, Name1 in the IMAGE_IMPORT_DESCRIPTOR structure will contain the RVA of the string " kernel32.dll "and there will be 10 IMAGE_THUNK_DATAs in each array The next question is:. why do we need two arrays that are exactly the same to answer that question, we need to know that when the PE file is loaded into memory,? the PE loader will look at the IMAGE_THUNK_DATAs and IMAGE_IMPORT_BY_NAMEs and determine the addresses of the import functions. Then it replaces the IMAGE_THUNK_DATAs in the array pointed to by FirstThunk with the real addresses of the f Unampings. thus when pe file is ready to run, the above picture is change to: OriginalFirstthunk image_import_by_name firstthunk |
|
Image_thunk_data
Image_thunk_data
Image_thunk_data
Image_thunk_data
...
Image_thunk_data
---> ---> ---> ---> ---> --->
Function 1
Function 2
Function 3
Function 4
...
Function N
Address of Function 1
Address of Function 2
Address of Function 3
Address of Function 4
...
Address of Function N
The array of RVAs pointed to by OriginalFirstThunk remains unchanged so that if the need arises to find the names of import functions, the PE loader can still find them.There is a little twist on this * straightforward * scheme. Some functions are exported by ordinal . only It means you do not call the functions by their names: you call them by their positions in this case, there will be no IMAGE_IMPORT_BY_NAME structure for that function in the caller's module Instead, the IMAGE_THUNK_DATA for that function will contain the.. ordinal of the function in the low word and the most significant bit (MSB) of IMAGE_THUNK_DATA set to 1. for example, if a function is exported by ordinal only and its ordinal is 1234h, the IMAGE_THUNK_DATA for that function will be 80001234h. Microsoft provides A Handy Constant for Testing The MSB of A DWORD, Image_ORDINAL_FLAG32. IT HAS The Value of 80000000H.suppose That We Want To List The Names of All Import Functions of A PE File, We need to follow the steps be Low:
Verify that the file is a valid PE From the DOS header, go to the PE header Obtain the address of the data directory in OptionalHeader Go to the 2nd member of the data directory. Extract the value of VirtualAddress Use that value to go to the first IMAGE_IMPORT_DESCRIPTOR structure Check the value of OriginalFirstThunk. If it's not zero, follow the RVA in OriginalFirstThunk to the RVA array. If OriginalFirstThunk is zero, use the value in FirstThunk instead. Some linkers generate PE files with 0 in OriginalFirstThunk. This is considered a bug . Just to be on the safe side, we check the value in OriginalFirstThunk first. For each member in the array, we check the value of the member against IMAGE_ORDINAL_FLAG32. If the most significant bit of the member is 1, then the function is exported BY ORDINAL NUMBER from the low word of the mer. if The MOST SIGNIFICANT BIT OF THE MEMBER IS 0, Use The Value In The Me MEMBER As The RVA INTO THE Image_IMPORT_BY_NAME, SK ip Hint, and you're at the name of the function. Skip to the next array member, and retrieve the names until the end of the array is reached (it's null -terminated). Now we are done extracting the names of the functions . imported from a DLL We go to the next DLL Skip to the next IMAGE_IMPORT_DESCRIPTOR and process it Do that until the end of the array is reached (IMAGE_IMPORT_DESCRIPTOR array is terminated by a member with all zeroes in its fields) .Example..:
This Also Shows The VALUES IN The Image_Import_Descriptor Structures.
.386 .model flat, stdcall option casemap: none include /masm32/include/windows.inc include /masm32/include/kernel32.inc include /masm32/include/comdlg32.inc include /masm32/include/user32.inc includelib / masm32 /lib/user32.lib includelib /masm32/lib/kernel32.lib includelib /masm32/lib/comdlg32.lib IDD_MAINDLG equ 101 IDC_EDIT equ 1000 IDM_OPEN equ 40001 IDM_EXIT equ 40003 DlgProc proto: DWORD,: DWORD,: DWORD,: DWORD ShowImportFunctions proto: DWORD ShowTheFunctions proto: DWORD,: DWORD AppendText proto: DWORD,: DWORD SEH struct PrevLink dd; the address of the previous seh structure CurrentHandler dd; the address of the new exception handler SafeOffset dd; The offset where it's safe??? to continue execution PrevEsp dd;? the old value in esp PrevEbp dd;? The old value in ebp sEH ends .data AppName db "PE tutorial no.6", 0 ofn OPENFILENAME <> FilterString db "Executable Files (* .exe, * .dll) ", 0," *. EXE; *. DLL ", 0 DB" All Files ", 0," *. * ", 0, 0 FileOpener DB" Cannot Open THE FILE Forread ", 0 FileOpenMappinger DB" Cannot Open THE FILE for MAMORY MAPPING ", 0 FileMappinger DB" Cannot Map The File Into Memory ", 0 Notvalidpe DB" this File Is Not a Valid PE ", 0 CRLF DB 0DH, 0AH, 0 ImportDescriptor db 0dh, 0ah, "================ [image_import_descriptor] ===============================================================00 0DH, 0AH DB "TIMEDATESTAMP =% LX", 0DH, 0AH DB "ForwarderChain =% LX", 0DH, 0AH DB "Name =% S", 0DH, 0AH DB "
Firstthunk =% lx ", 0 nameheader db 0dh, 0ah," hint function ", 0DH, 0AH DB" --------------------------- ------------ ", 0 NameTemplate DB"% U% S ", 0 OrdinalTemplate DB"% u (ORD.) ", 0 .DATA? BUFFER DB 512 DUP (?) HFile ? dd hMapping dd pMapping dd ValidPE dd .code start:??? invoke GetModuleHandle, NULL invoke DialogBoxParam, eax, IDD_MAINDLG, NULL, addr DlgProc, 0 invoke ExitProcess, 0 DlgProc proc hDlg: DWORD, uMsg: DWORD, wParam: DWORD, lParam: DWORD .if uMsg == WM_INITDIALOG invoke SendDlgItemMessage, hDlg, IDC_EDIT, EM_SETLIMITTEXT, 0,0 .elseif uMsg == WM_CLOSE invoke EndDialog, hDlg, 0 .elseif uMsg == WM_COMMAND .if lParam == 0 mov eax, wParam. if ax == IDM_OPEN invoke ShowImportFunctions, hDlg .else; IDM_EXIT invoke SendMessage, hDlg, WM_CLOSE, 0,0 .endif .endif .else mov eax, FALSE ret .endif mov eax, TRUE ret DlgProc endp SEHHandler proc uses edx pExcept: DWORD , Pframe: DWORD, PCONTEXT: DWORD, PDISPATCH: DWORD MOV EDX, PFRAME Assume Edx: Ptr Seh Mov Eax, PContext assume eax: ptr CONTEXT push [edx] .SafeOffset pop [eax] .regEip push [edx] .PrevEsp pop [eax] .regEsp push [edx] .PrevEbp pop [eax] .regEbp mov ValidPE, FALSE mov eax, ExceptionContinueExecution ret SEHHandler endp ShowImportFunctions proc uses edi hDlg: DWORD LOCAL seh: SEH mov ofn.lStructSize, SIZEOF ofn mov ofn.lpstrFilter, OFFSET FilterString mov ofn.lpstrFile, OFFSET buffer mov ofn.nMaxFile, 512 mov ofn.Flags, OFN_FILEMUSTEXIST or OFN_PATHMUSTEXIST or OFN_LONGNAMES OR OFN_EXPLORER OR OFN_HIDEREADONLY Invoke GetopenFileName, Addr OFN .IF EAX ==
TRUE invoke CreateFile, addr buffer, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL .if eax! = INVALID_HANDLE_VALUE mov hFile, eax invoke CreateFileMapping, hFile, NULL, PAGE_READONLY, 0,0,0 .if eax! = NULL mov hMapping , eax invoke MapViewOfFile, hMapping, FILE_MAP_READ, 0,0,0 .if eax = NULL mov pMapping, eax assume fs:! nothing push fs: [0] pop seh.PrevLink mov seh.CurrentHandler, offset SEHHandler mov seh.SafeOffset, offset FinalExit lea eax, seh mov fs: [0], eax mov seh.PrevEsp, esp mov seh.PrevEbp, ebp mov edi, pMapping assume edi: ptr IMAGE_DOS_HEADER .if [edi] .e_magic == IMAGE_DOS_SIGNATURE add edi, [edi ] .e_lfaNew Assume EDI: PTR Image_NT_HEADERS .IF [EDI]. Signature == Image_NT_SIGNATURE MOV VALIDPE, TRUE .ELSE MOV VALID PE, FALSE .endif .else mov ValidPE, FALSE .endif FinalExit: push seh.PrevLink pop fs: [0] .if ValidPE == TRUE invoke ShowTheFunctions, hDlg, edi .else invoke MessageBox, 0, addr NotValidPE, addr AppName, MB_OK MB_ICONERROR .endif invoke UnmapViewOfFile, pMapping .else invoke MessageBox, 0, addr FileMappingError, addr AppName, MB_OK MB_ICONERROR .endif invoke CloseHandle, hMapping .else invoke MessageBox, 0, addr FileOpenMappingError, addr AppName, MB_OK
MB_ICONERROR .endif invoke CloseHandle, hFile .else invoke MessageBox, 0, addr FileOpenError, addr AppName, MB_OK MB_ICONERROR .endif .endif ret ShowImportFunctions endp AppendText proc hDlg: DWORD, pText: DWORD invoke SendDlgItemMessage, hDlg, IDC_EDIT, EM_REPLACESEL, 0, pText invoke SendDlgItemMessage, hDlg, IDC_EDIT, EM_REPLACESEL, 0, addr CRLF invoke SendDlgItemMessage, hDlg, IDC_EDIT, EM_SETSEL, -1,0 ret AppendText endp RVAToOffset PROC uses edi esi edx ecx pFileMap: DWORD, RVA: DWORD mov esi, pFileMap assume esi : ptr IMAGE_DOS_HEADER add esi, [esi] .e_lfanew assume esi: ptr IMAGE_NT_HEADERS mov edi, RVA; edi == RVA mov edx, esi add edx, sizeof IMAGE_NT_HEADERS mov cx, [esi] .FileHeader.NumberOfSections movzx ecx, cx assume edx : ptr IMAGE_SECTION_HEADER .while ecx> 0; check all sections .if edi> = [edx] .VirtualAddress mov eax, [edx] .VirtualAddress add eax, [edx] .SizeOfRawData .if edi file offset ret .endif .endif add edx, sizeof IMAGE_SECTION_HEADER dec ecx .endw assume edx: nothing assume esi: nothing mov eax, edi ret RVAToOffset endp ShowTheFunctions proc uses esi ecx ebx hDlg: DWORD, pNTHdr: DWORD LOCAL temp [512]: BYTE invoke SetDlgItemText, hDlg, IDC_EDIT, 0 invoke AppendText, hDlg, addr buffer mov edi, pNTHdr assume edi: ptr IMAGE_NT_HEADERS mov edi, [edi] .OptionalHeader.DataDirectory [sizeof IMAGE_DATA_DIRECTORY] .VirtualAddress invoke RVAToOffset, pMapping, edi mov edi, eax add edi, pMapping assume edi:! ptr IMAGE_IMPORT_DESCRIPTOR .while ([edi] .OriginalFirstThunk == 0 && [edi] .TimeDateStamp == 0 && [edi] .ForwarderChain == 0 && [edi] .Name1 == 0 && [edi] .FirstThunk == 0) invoke AppendText, hDlg, addr ImportDescriptor invoke RVAToOffset, pMapping, [edi] .Name1 mov edx, eax add edx, pMapping invoke wsprintf, addr temp, addr IDTemplate, [edi] .OriginalFirstThunk, [ EDI] .timedatestamp, [EDI] .forwarder Chain, edx, [edi] .FirstThunk invoke AppendText, hDlg, addr temp .if [edi] .OriginalFirstThunk == 0 mov esi, [edi] .FirstThunk .else mov esi, [edi] .OriginalFirstThunk .endif invoke RVAToOffset, pMapping ESI Add Eax, Pmapping Mov ESI, EAX Invoke AppendText, HDLG, AddR NameHeader .While Dword Ptr [ESI]! = 0 test dword ptr [esi], IMAGE_ORDINAL_FLAG32 jnz ImportByOrdinal invoke RVAToOffset, pMapping, dword ptr [esi] mov edx, eax add edx, pMapping assume edx: ptr IMAGE_IMPORT_BY_NAME mov cx, [edx] .Hint movzx ecx, cx invoke wsprintf, addr temp, addr NameTemplate, ecx, addr [edx] .Name1 jmp ShowTheText ImportByOrdinal: mov edx, dword ptr [esi] and edx, 0FFFFh invoke wsprintf, addr temp, addr OrdinalTemplate, edx ShowTheText: invoke AppendText, hDlg, addr temp add esi , 4.ndw add edi, sizeof image_import_descriptor .ndw return showthefunctions endp end startanalysis: The program shows.. Showthefunctions Proc Uses ESI ECX EBX HDLG: DWORD, PNTHDR: DWORD LOCAL TEMP [512]: BYTE Reserve 512 Bytes of Stack Space for string operation. Invoke setdlgitemtext, hdlg, idc_edit, 0 Clear the text in the Edit Control Invoke AppendText, HDLG, AddR Buffer Insert the name of the PE file into the edit control. AppendText just sends EM_REPLACESEL messages to append the text to the edit control. Note that it sends EM_SETSEL with wParam = -1 and lParam = 0 to the edit control to move the cursor to the End of the text. MOV EDI, PNTHDR Assume EDI: Ptr Image_NT_Headers Mov Edi, [EDI] .OptionalHeader.DataDirectory] .VirtualAddress Of The RVA of The Import Symbols. Invoke Ratooffset, Pmapping, EDI MOV EDI, EAX Add Edi, PMApping Here comes one of the pitfalls for newcomers to PE programming. Most of the addresses in the PE file are RVAs and RVAs are meaningful only when the PE file is loaded into memory by the PE loader. In our case, we do map the file into memory but not the way the PE loader does. Thus we can not use those RVAs directly. Somehow we have to convert those RVAs into file offsets. I write RVAToOffset function just for this purpose. I will not analyze it in detail here. Suffice to say that it checks the submitted RVA against the starting-ending RVAs of all sections in the PE file and use the value in PointerToRawData field in the IMAGE_SECTION_HEADER structure to convert the RVA to file offset.To use this function, you pass it two parameters: the pointer to the memory mapped file and the RVA you want to convert. It returns the file offset in eax. in the above snippet, we must add the pointer to the memory mapped file to the file offset to convert it to virtual address. Seems COMPLICATED, HuH?: ASSUM E EDI: PTR image_import_descriptor .while! ([EDI] .originalfirstthunk == 0 && [EDI] .timedatestamp == 0 && [EDI] .forwarderchain == 0 && [EDI] .name1 == 0 && [EDI] .firstthunk == 0) EDI NOW POINTS TO The First Image_import_descriptor Structure. We Will Walk The Array Until We Find The Structure with Zeroes in All members Which Denotes The end of the array. Invoke appendtext, hdlg, addr importdescriptor invoke rvatooffset, pmapping, [edi] .name1 MOV EDX, EAX Add Edx, PMApping We want to display the values of the current IMAGE_IMPORT_DESCRIPTOR structure in the edit control. Name1 is different from the other members since it contains the RVA to the name of the dll. Thus we must convert it to a virtual address first.invoke wsprintf, addr Temp, addr idtemplate, [edi] .originalfirstthunk, [edi] .timedatestamp, [EDI] .forwarderchain, edx, [edi] .firstthunk invoke appendtext, HDLG, Addr Temp Display The Values of The Current Image_import_Descriptor. . IF [EDI] .originalfirstthunk == 0 MOV ESI, [EDI] .firstthunk .else Mov ESI, [EDI] .originalFirstthunk .endif Next we prepare to walk the IMAGE_THUNK_DATA array. Normally we would choose to use the array pointed to by OriginalFirstThunk. However, some linkers errornously put 0 in OriginalFirstThunk thus we must check first if the value of OriginalFirstThunk is zero. If it is, we use The array pointed to by firstthunk instead. Invoke Rvatooffset, Pmapping, ESI Add Eax, Pmapping Mov ESI, ESI Again, The Value in OriginalFirstthunk / Firstthunk is an RVA. We Must Convert It To Virtual Address. Invoke appendtext, hdlg, addr namehead .While Dword PTR [ESI]! = 0 Now We are ready to walk the array of image_thunk_datas to look for the name of the functions imported from this dll. We will Walk The Array Until We Find An Entries Which Contains 0. Test DWORD PTR [ESI], image_ordinal_flag32 jnz importbyordinal The first thing we do with the IMAGE_THUNK_DATA is to test it against IMAGE_ORDINAL_FLAG32. This test checks if the most significant bit of the IMAGE_THUNK_DATA is 1. If it is, the function is exported by ordinal so we have no need to process it further. We can extract its ordinal from the low word of the IMAGE_THUNK_DATA and go on with the next IMAGE_THUNK_DATA dword.invoke RVAToOffset, pMapping, dword ptr [esi] mov edx, eax add edx, pMapping assume edx: ptr IMAGE_IMPORT_BY_NAME IF the msb of the iamge_thunk_data is 0, IT Contains The RVA of Image_Import_by_name struge. We need to convert it to virtual address first. MOV CX, [EDX]. Hint Movzx ECX, CX Invoke Wsprintf, Addr Temp, Addr NameTemplate, ECX, Addr [EDX] .Name1 JMP ShowThetExt Hint Is A Word-Sized Field. We Must Convert It To A Dword-Size Value Before Submitting It To Wsprintf. And We Print Both The Hint and The Function Name In The Edit Control Importbyordinal: Mov Edx, DWORD PTR [ESI] and Edx, 0FFFFH INVOKE WSPRINTF, AddR Temp, Addr OrdinalTemplate, EDX In the case the function is exported by Ordinal Only, We Zero Out The High Word and Display the Ordinal. ShowthetxT: Invoke AppendText, HDLG, Addr Temp Add ESI, 4 After Inserting The Function Name / Ordinal INTO The NEXT IMAGE_THUNK_DATA. .Endw add edi, sizeof image_import_descriptor WHEN All Image_thunk_data dwords in The Array Are Processed, We Skip to the next image_import_descriptor to process the import functions from Other DLLS. APPENDIX: It would be incomplete if I do not mention something about bound import. In order to explain what it is, I need to digress a bit. When the PE loader loads a PE file into memory, it examines the import table and loads the required DLLs into the process address space. Then it walks the IMAGE_THUNK_DATA array much like we did and replaces the IMAGE_THUNK_DATAs with the real addresses of the import functions. This step takes time. If somehow the programmer can predict the addresses of the functions correctly, the PE loader does not have to fix the IMAGE_THUNK_DATAs each time the PE file is run. Bound import is the product of that idea.To put it in simple terms, there is a utility named bind.exe that comes with Microsoft compilers such as Visual Studio that examines the import table of a PE file and replaces the IMAGE_THUNK_DATA dwords with the addresses of the import functions.When the file is loaded, the PE loader must check if the addresses are valid. If the DLL versions do not match the o nes in the PE files or if the DLLs need to be relocated, the PE loader knows that the precomputed addresses are not valid thus it must walk the array pointed to by OriginalFirstThunk to calculate the new addresses of import functions.Bound import does not have much significance in our example because we use OriginalFirstThunk by default. For more information about the bound import, I recommmend LUEVELSMEYER's pe.txt. [Iczelion's Win32 Assembly Homepage]
