AntiHookExec Version 1.0 (Anti API Hooking Proof-Of-Concept)

by Tan Chew Keong
15 April 2004

Download

Introduction

API hooking is a useful technique that can be used to monitor API calls used by Win32 programs. This allows understanding of the programs' functionalities based on the APIs that are called and their input parameters. However, API hooking is also used by rootkits and other malicious code to modify the behaviour of certain APIs to hide files, network ports, processes or services.

This proof-of-concept code demonstrates how to overcome some of the API hooking techniques to execute a specified EXE that is free from API hooks. This program has been tested to work against HackDefender Version 1.0 rootkit for Windows.

 

API Hooking Techniques

The idea behind API hooking is to allow an API call to be redirected to a replacement function. This replacement function will usually perform some manipulation of the input parameters before transferring control back to the called API. The replacement function could also manipulate the API's return results before passing them back to the caller. This simple idea has been used by rootkits and trojans to hide files, processes and network ports. For example, by hooking FindFirstFileA and FindNextFileA, it is possible to manipulate the list of filenames returned, thus allowing certain files to be hidden from the directory listing.

This proof-of-concept code demonstrates how a program can rid itself of system-wide API hooks that are implemented based on the following techniques.

1. Import/Export Table Modification
2. Overwriting the start of the hooked API with a JMP instruction

Import/Export Table Modification

This technique allows APIs to be hooked by making direct modifications to the Import/Export Tables of the targeted process and all its modules (DLLs). Each process and module(DLL) have their own Import Address Table (IAT) that contains the entry-point addresses of the APIs that are used. These addreseses will be used whenever the process makes a call to the repective APIs. Therefore, by replacing the entry-point address of an API (in the IAT) with that of a replacement function, it is possible to redirect any calls to the API to the replacement function.

However, modifying the IAT alone is insufficient since the targeted process might use the GetProcAddress API to obtain the real entry point address of an API. This problem could be solved by hooking the GetProcAddress API so that the address of the replacement function is returned instead. Alternatively, it is possible to directly modify the Export Address Table of the DLL that exports that particular API. Every DLL has an Export Address Table (EAT) that contains the entry-point addresses of the APIs that are implemented within the DLL. Hence, by replacing the entry-point of an API within the EAT with the relative address of the replacement function, we can cause GetProcAddress to return the address of the replacement function instead.

Overwriting the start of the hooked API with a JMP instruction

Another technique that can be used to implement API hooking involves overwriting the start of the hooked API with a JMP instruction that cause execution to be transferred to the replacement function. This technique requires less modifications within the memory space of the hooked process as compared to the previous technique.

 

AntiHookExec Algorithm

This proof-of-concept code works as follows:

1. Manually read ntdll.dll and kernel32.dll into memory using CreateFile, ReadFile APIs. Make sure they are properly aligned to the specified memory alignment. Henceforth, these two manually loaded images shall be called the file images. The memory images of ntdll.dll and kernel32.dll as mapped in by the OS shall be called the memory images.

    

2. Iterate through all the APIs exported by ntdll.dll and kernel32.dll using the Export Table of the file images. For each API exported, perform Instruction Length Disassembly to get a rough estimate of the function length (N). Compare the first N bytes of each API using the file images and the memory images. Any discrepancies between them would indicate that the particular API have been hooked using the second technique described above.

    

3. Restore each hooked API by copying the relevant bytes from the file images to the memory images.

    

4. Iterate through the Import Address Table (IAT) of kernel32.dll. For each imported API address from ntdll.dll, check that it has not been modified. Any modified IAT entries of kernel32.dll will be restored using the disk images.

    

5. Obtain the API address of CreateProcessA using the disk image of kernel32.dll. This ensures that any modifications to our IAT won't affect us.

    

6. Execute the specified EXE using CreateProcessA.

 

Usage

AntiHookExec.exe <exe filename>

This program will attempt to rid itself of userspace API hooks and execute <exe filename>

 

The following steps will be taken.

1. API Restoration. This program will attempt to detect any changes to the memory image of ntdll.dll by comparing it against the disk image. If there are any changes, the memory image will be patch by referencing the disk image.

    

2. Import Table Restoration. This program will attempt to restore the import tables in the memory image of kernel32.dll by comparing it against the disk image.

    

3. Obtain the memory address of CreateProcessA using the disk image of kernel32.dll, and use this address to execute <exe filename>

    

 

Limitations

The following are some limitations of this proof-of-concept code.

1. The system-wide API hooking program has not hooked ReadFile API, and cause it to return a falsified disk image of kernel32.dll and ntdll.dll.
2. The system-wide API hook has not disabled VirtualQuery and VirtualProtect APIs.
3. This program will not work against kernel-space rootkits.
4. This program will also not work against API hooks that are installed using SetWindowsHookEx.

 

Contacts

For further enquries or to submit malicious code for our analysis, email them to the following.

Overall-in-charge: Tan Chew Keong