api.rar_remote

API Interception via DLL Redirection

In Windows, all applications must communicate with the kernel through API functions; as such,

these functions are critical to even the simplest Windows application. Thus, the ability to intercept,

monitor, and modify a program's API calls, commonly called API hooking, effectively gives one full

control over that process. This can be useful for a multitude of reasons, including debugging, reverse

engineering, and hacking (in all interpretations of the word).

While there are several methods which can be used to achieve our goal, this tutorial will

examine only DLL redirection. This approach was chosen for several reasons:

1. It is relatively simple to implement.

system files.

Tools and Prerequisites

The following software will be used throughout this paper. You may of course use whatever

utilities to which you are partial, however, bear in mind that their specific usage and implementation

may vary:

• Visual C++ – Used to compile our DLL files.

• OllyDbg – Used to examine the target application and any external modules.

• DumpbinGUI – Used to obtain a list of functions exported by a target DLL.

• Linkout.pl – A perl script used to automate the majority of our leg work (requires ActivePerl).

It is assumed that the reader has a fairly solid grasp on Win32 programming in C/C++,

original, but each function may contain whatever code we like. There are two ways to achieve DLL

redirection; the first method is sometimes referred to as “dot local” redirection:

“Applications can depend on a specific version of a shared DLL and start to fail if another application

is installed with a newer or older version of the same DLL. There are two ways to ensure that your

application uses the correct DLL: DLL redirection and side-by-side components. Developers and

administrators should use DLL redirection for existing applications, because it does not require any

changes to the application. “

In other words, dot local DLL redirection affords developers the ability to force an application

to use a different version of a particular DLL file than that used by the rest of the system. For example,

if an application called oldapp.exe only worked with an outdated version of user32.dll, then instead of

replacing the user32.dll file in the system32 directory (potentially causing many other applications to

break), you could tell it to load the older version of user32.dll from the program's current directory by

creating an appropriate dot local file. All other applications will still load the newer DLL from

system32 and remain unaffected. All that is needed is to create a dot local file (which is simply an

empty file whose name contains the name of the target application followed by a .local extension; in

this case it would be oldapp.exe.local), and place it and the older version of user32.dll in the same

directory as oldapp.exe.

However, there are a few limitations. Most notably, according to MSDN, certain DLL files

is a unreliable method, and should be used only on Windows 2000 machines.

The second method, and the one which we will be using, uses manifest files to achieve the same

result. Manifest files use the same naming convention as dot local files (i.e., oldapp.exe.manifest), but

are not empty files. They must contain certain XML-formatted information in order to function

properly, or else the target application will fail to load. In addition, manifest files are only supported on

Windows XP and Vista; however, they are far more reliable than using dot local redirection, and allow

restrictions/changes may be applied to Windows Vista).

Programs only use DLL redirection when told to – luckily, telling them to do so is fairly simple.

For dot local redirection, the creation of a file called program_name.exe.local will cause the application

to look in the present working directory for DLL files before looking for them in the system folders.

Very simple, but as previously noted, not very reliable on modern systems.

Manifest files are a bit more complex, as there is some necessary XML information that must be

stored in the manifest file in order for it to function properly. Below is an example of a manifest file:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity

version="6.0.0.0"

<dependentAssembly>

<assemblyIdentity

type="win32"

name="Microsoft.Windows.Common-Controls"

version="6.0.0.0"

processorArchitecture="X86"

publicKeyToken="6595b64144ccf1df"

language="*"

/>

</dependentAssembly>

of this tutorial (more information can be found regarding manifest files here). However, note the <file>

section; inside this section we have declared a name attribute, setting it equal to user32.dll. This tells

the application to which the manifest file belongs that user32i.dll should be loaded from the current

working directory. Once this file is created, save it using the same name convention used for dot local

files (program_name.exe.manifest), and place it in the same directory as the target application.

Creating a Stub DLL

We now know how DLL redirection works, but like most things, it is a little bit more complex

in practice: once we have redirected the program to load our DLL, we need to have all the functions it

is looking for. Let's say that we want to intercept every call that Internet Explorer makes to

MessageBox. MessageBox is located in user32.dll, so we will need to create a DLL called user32.dll

There could be hundreds of functions that IE will be looking for in user32.dll and if any of these are

missing then IE will fail to load. Since we don't want to re-write all of the user32 DLL functions, we

will simply forward the rest of the functions to the original user32.dll file.

First, we use the dumpbinGUI utility to view all of the functions exported from user32.dll (right

click user32.dll, and go to DumpbinGUI->EXPORTS). You should see something very similar to this: