How Does IAT Hooking Work, and What Are Its Issues?

For those unfamiliar with the term ‘hooking’ (don’t worry, you’re definitely not alone), it involves a method of manipulating a program to perform actions it wasn’t originally designed for. In a video game, for example, you can ‘hook’ into functions like health reduction when your character takes damage, allowing you to execute custom code. This code could potentially boost your character’s health and ammo.

The process of hooking entails altering the function’s address within the Import Address Table (IAT) and redirecting the program to execute your code instead of the original function.

Demystifying IDT, IAT, and ILT

The ‘Import Directory Table’ (IDT) is a fundamental component of this process. It contains an array of IMAGE_IMPORT_DESCRIPTOR structures and is typically found at the start of the .idata section in a binary file (although it may sometimes reside in .rdata). These structures are vital for handling each imported Dynamic Link Library (DLL) in the process.

The layout of IMAGE_IMPORT_DESCRIPTOR structures is as follows:

typedef struct _IMAGE_IMPORT_DESCRIPTOR {
    union {
        DWORD Characteristics; // 0 for terminating null import descriptor
        DWORD OriginalFirstThunk; // RVA to the ILT/INT
    } DUMMYUNIONNAME;
    
    DWORD TimeDateStamp; /* 0 if not bound,
       -1 if bound, and real date\time stamp
       in IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT (new BIND)
       O.W. date/time stamp of DLL bound to (Old BIND) */
    DWORD ForwarderChain; // -1 if no forwarders
    DWORD Name;
    DWORD FirstThunk; // RVA to IAT (if bound this IAT has actual addresses).
} IMAGE_IMPORT_DESCRIPTOR;
typedef IMAGE_IMPORT_DESCRIPTOR UNALIGNED *PIMAGE_IMPORT_DESCRIPTOR;

Key elements to note in this structure are:

• OriginalFirstThunk (the relative virtual address to the ILT/INT)
• Name (the DLL’s name)
• FirstThunk (the relative virtual address to the IAT).

The ILT/INT, short for Import Lookup Table or Import Name Table, respectively, serves as a table of function names imported into the process by the DLL. The IMAGE_IMPORT_DESCRIPTOR contains the address of the ILT/INT.

IAT, or Import Address Table, pretty much does what it says on the tin; it’s a table of addresses for each imported function. Although on disk, the IAT mirrors the ILT (holding only function names), at runtime, the loader overwrites the IAT with the actual function addresses.

How IAT Hooking Operates

IAT Hooking is a relatively straightforward technique, frequently employed in various malware and game hacking contexts, including:

• Preventing a function from executing.
• Extracting information from a function.
• Running additional code when the original function is called.

Once you have found the IAT and the function to hook, the process is the following:

1. Change the function’s address in the IAT to your code’s address. Consequently, whenever the function is called, it will execute your code instead of the original function.
2. Your code can then run, and you can subsequently jump to the original function to execute it.

Challenges and Detection

There are some potential issues with IAT Hooking:

1. Detection is relatively easy since each imported function comes from another binary (e.g. kernel32.dll), which has specific memory bounds. If the function’s address in the IAT is changed to an address outside these bounds, it indicates that the original function has been tampered with.
2. This type of hooking is ineffective if the import is performed via ordinal.