Injective Code Inside an Import Table

Imagine that you could redirect the thoroughfare of the imported function’s entrances into your special routines by manipulating the import table thunks. It could be possible to filter the demands of the importations through your routines. Furthermore, you could settle your appropriate routine by this performance, which is done by the professional Portable Executable (PE) Protectors. Additionally, some sort of rootkits employ this approach to embed its malicious code inside the victim by a Trojan horse.

In the reverse engineering world, it’s described as an API redirection technique. Nevertheless, I am not going to accompany all viewpoints in this area with source code. This article merely represents a brief aspect of this technique by a simple code. I will describe other issues in the absence of the source code; I could not release the code that is related to commercial projects or intended to a malicious motivation. However, I think this article could be used as an introduction into this topic.

1. Intoduction to the Import Table

The portable executable file structure consists of the MS-DOS header, the NT headers, the Sections headers, and the Section images, as you observe in Figure 1. The MS-DOS header is common in all Microsoft executable file formats from the DOS days to the Windows days. The NT headers idea was abstracted form the Executable and Linkable Format (ELF) of the UNIX System. Indeed, the Portable Executable (PE) format is sister of the Linux Executable and Linkable Format (ELF). The PE format headers consist of the “PE” Signature, the Common Object File Format (COFF) header, the Portable Executable Optimal header, and the Section headers.

Figure 1: Portable Executable file format structure

The definition of the NT headers can be found in the <winnt.h> header file of the Virtual C++ included directory. This information can be retrieved very easily by using ImageNtHeader() from DbgHelp.dll. You also can employ the DOS header to fetch the NT headers, so the last position of the DOS header, e_lfanew, represents the offset of the NT headers.

typedef struct _IMAGE_NT_HEADERS {

   DWORD Signature;

   IMAGE_FILE_HEADER FileHeader;

   IMAGE_OPTIONAL_HEADER OptionalHeader;

} IMAGE_NT_HEADERS, *PIMAGE_NT_HEADERS;

In the Portable Executable Optional header, there are some data directories that delineate the relative location and the size of the principal information tables inside the virtual memory of the current process. These tables can hold information about resource, import, export, relocation, debug, thread local storage, and the COM runtime. It is impossible to find a PE executable file without the import table; this table contains the DLL names and the Functions names that are essential when the program requests them by their virtual addresses. The resource table is not found in the Console executable files; nevertheless, it is a vital part of the Windows executable files with a Graphic User Interface (GUI). The export table is necessary when a dynamic link library exports its function outside and also in an OLE Active-X container. The Dot NET virtual machine could not be executed unescorted by the COM+ runtime header. As you discerned, each table has a special commission in the PE format; see Table 1.

Table 1: Data Directories

// <winnt.h>

#define IMAGE_NUMBEROF_DIRECTORY_ENTRIES    16
// Optional header format.
typedef struct _IMAGE_OPTIONAL_HEADER {
   …
   IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];

} IMAGE_OPTIONAL_HEADER32, *PIMAGE_OPTIONAL_HEADER32;
// Directory Entries

#define IMAGE_DIRECTORY_ENTRY_EXPORT     0 // Export Directory

#define IMAGE_DIRECTORY_ENTRY_IMPORT     1 // Import Directory

#define IMAGE_DIRECTORY_ENTRY_RESOURCE   2 // Resource Directory

#define IMAGE_DIRECTORY_ENTRY_BASERELOC  5 // Base Relocation Table

#define IMAGE_DIRECTORY_ENTRY_DEBUG      6 // Debug Directory

#define IMAGE_DIRECTORY_ENTRY_TLS        9 // TLS Directory

You can obtain the position and size of the import table with only two or three lines of code. By knowing the position of the import table, you can move to the next step to retrieve the DLL names and the Function names. It will be discussed in the following section.

PIMAGE_NT_HEADERS pimage_nt_headers = ImageNtHeader(pImageBase);

DWORD it_voffset = pimage_nt_headers->OptionalHeader.

   DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress;

PIMAGE_DOS_HEADER pimage_dos_header = PIMAGE_DOS_HEADER(pImageBase);

PIMAGE_NT_HEADERS pimage_nt_headers = (PIMAGE_NT_HEADERS)

   (pImageBase + pimage_dos_header->e_lfanew);

DWORD it_voffset = pimage_nt_headers->OptionalHeader.

   DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress;

2. Import Descriptor at a Glance

The import directory entry of the import table leads you to the position of the import table inside the file image. There is a container for each imported DLL, import descriptor, that embraces the address of first thunk and the address of original first thunk, the pointer to the DLL name. The First Thunk refers to the location of the first thunk; the thunks will be initialized by the PE loader of Windows during the running of the program, as shown in Figure 5. The Original First Thunk points to the first storage of the thunks, where the address of the Hint data and the Function Name data for each functions is provided, Figure 4. In that case, the First Original Thunk is not present; the First Thunk refers to where the Hint data and the Function Name data are located, Figure 3.

The import descriptor is represented with IMAGE_IMPORT_DESCRIPTOR structures, as in the following definition:

typedef struct _IMAGE_IMPORT_DESCRIPTOR {

   DWORD   OriginalFirstThunk;

   DWORD   TimeDateStamp;

   DWORD   ForwarderChain;

   DWORD   Name;

   DWORD   FirstThunk;

} IMAGE_IMPORT_DESCRIPTOR, *PIMAGE_IMPORT_DESCRIPTOR;

typedef struct _IMAGE_IMPORT_BY_NAME {

   WORD    Hint;

   BYTE    Name[1];

} IMAGE_IMPORT_BY_NAME, *PIMAGE_IMPORT_BY_NAME;

typedef struct _IMAGE_THUNK_DATA {

   union {

      PDWORD                 Function;

      PIMAGE_IMPORT_BY_NAME  AddressOfData;

   } u1;

} IMAGE_THUNK_DATA, *PIMAGE_THUNK_DATA;

Figure 3: Import Table View

Figure 4: Import Table View with Orignal First Thunk

These two import tables (Figures 3 and 4) illustrate the difference between an import table with and without the original first thunk.

Figure 5: Import Table after overwritten by PE loader

You can use Dependency Walker, Figure 6, to observe all the information of the import table. By the way, I have provided another tool, Import Table viewer, Figure 7, with simple and similar operation. I am sure its source will help you understand the main representation that is done by this kind of equipment.

Figure 6: Dependency Walker, Steve P. Miller

Here, you observe a simple source that could be used to display the import DLLs and the import Functions with a console mode program. However, I think my Import Table viewer, Figure 7, has more incentive to follow the topic because of its graphic user interface.

PCHAR       pThunk;

PCHAR       pHintName;

DWORD       dwAPIaddress;

PCHAR       pDllName;

PCHAR       pAPIName;

//—————————————-

DWORD dwImportDirectory= RVA2Offset(pImageBase, pimage_nt_headers->

   OptionalHeader.

   DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);

//—————————————-

PIMAGE_IMPORT_DESCRIPTOR pimage_import_descriptor=

   (PIMAGE_IMPORT_DESCRIPTOR)

   (pImageBase+dwImportDirectory);

//—————————————-

while(pimage_import_descriptor->Name!=0)

{

   pThunk= pImageBase+pimage_import_descriptor->FirstThunk;

   pHintName= pImageBase;

   if(pimage_import_descriptor->OriginalFirstThunk!=0)

   {

        pHintName+= RVA2Offset(pImageBase,

           pimage_import_descriptor->OriginalFirstThunk);

   }

   else

   {

      pHintName+= RVA2Offset(pImageBase,

         pimage_import_descriptor->FirstThunk);

   }

   pDllName= pImageBase + RVA2Offset(pImageBase,

      pimage_import_descriptor->Name);

   printf(” DLL Name: %s First Thunk: 0x%x”, pDllName,

          pimage_import_descriptor->FirstThunk);

   PIMAGE_THUNK_DATA pimage_thunk_data= (PIMAGE_THUNK_DATA) pHintName;

   while(pimage_thunk_data->u1.AddressOfData!=0)

   {

      dwAPIaddress= pimage_thunk_data->u1.AddressOfData;

      if((dwAPIaddress&0x80000000)==0x80000000)

      {

         dwAPIaddress&= 0x7FFFFFFF;

         printf(“Proccess: 0x%x”, dwAPIaddress);

      }

      else

      {

         pAPIName= pImageBase+RVA2Offset(pImageBase, dwAPIaddress)+2;

         printf(“Proccess: %s”, pAPIName);

      }

      pThunk+= 4;

      pHintName+= 4;

      pimage_thunk_data++;

   }

   pimage_import_descriptor++;

}

Figure 7: Import Table viewer