DLL Redirection — debugging techniques for Windows Applications

Posted at Jun 07, 11:31h in linker Macrium Software, Marketing Categories: linker, windows-internals, debugging, dll, devteam

Just how exactly should that API be called?

When you’re dealing with a simple Windows API call such as MessageBox, you can probably deduce what you should be doing via an experiment or two, but some API calls are non-trivial and involve a lot of set up, particularly the likes of Volume Shadow Copy, and some more obscure, undocumented APIs.

Luckily, there is a way to trivially work out how applications use these APIs, if you can identify one that does what you think it should. Firstly, dependency walker should be used to profile the calls an application is making and which DLLs are being made.

The next thing you need to know is that it is possible to redirect DLL function calls in Windows. This technique means you can effectively replace a system DLL with your own DLL, provided you redirect all of the symbols in it to the original.

So the next thing you need to do is to list the functions exported by a DLL. The SDK gives you a utility to do this — here’s an example:

C:> dumpbin /exports c:windowssystem32kernel32.dll
Microsoft (R) COFF/PE Dumper Version 11.00.50214.1
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file c:windowsSystem32kernel32.dll
File Type: DLL
Section contains the following exports for KERNEL32.dll
00000000 characteristics
4E20FCBC time date stamp Sat Jul 16 03:51:40 2011
0.00 version
1 ordinal base
1390 number of functions
1390 number of names
ordinal hint RVA      name
...
138 89 00023190 CreateFileA
139 8A 0000EAD0 CreateFileMappingA
140 8B 00064FB0 CreateFileMappingNumaA
141 8C 0004C550 CreateFileMappingNumaW
142 8D 0000F9F0 CreateFileMappingW
143 8E 000759C0 CreateFileTransactedA
144 8F 00075820 CreateFileTransactedW
145 90 00011870 CreateFileW
...
Since I detest the very sight of VBScript, I chose to write the next part in Python. This essentially processes the raw output from dumpbin, producing a header which includes linker pragmas to set up DLL redirection.
[code language="python"]
#!/usr/bin/env python
import re
import sys
def get_functions(file_path):
funcs = []
exports = re.compile('s+d+s+[A-Fa-f0-9]+s+'
'[A-Fa-f0-9]+s+(?P<functionname>S+)')
redirexps = re.compile('s+d+s+[A-Fa-f0-9]+s+(?P<functionname>S+)'
's+(forwarded to '
'(?P<forward_name>[A-Za-z0-9_.]+))')
with open(file_path, "rb") as f:
while True:
line = f.readline()
if not line:
break
matches = exports.match(line)
if matches:
funcs.append(matches.group('functionname'))
matches = redirexps.match(line)
if matches:
funcs.append(matches.group('functionname'))

return funcs
def convert_to_pragma(funcs, orig_dll):
return ["#pragma comment(linker, "/export:%s=%s.%s,@%d")" %
(func, orig_dll, func, i) for i, func in enumerate(funcs, 1)]
def write_defs(funcs, output_file):
deffile_text = "LIBRARY vssapi.dllnn"
deffile_text += "EXPORTSn"
for func in funcs:
"""
special processing is needed for C++ redirects
"""
deffile_text += " %s=Redirected%sn" % (func, func)

deffile_text += "nn"
with open(output_file, "wb") as f:
f.write(deffile_text)
def write_full_header(pragma_lines, output):
header_text = "/* DLL Redirection Header */ nn"
header_text += "#pragma oncenn"
for p in pragma_lines:
header_text += "%sn" % (p)
header_text += "nn"
with open(output, "wb") as f:
f.write(header_text)
if __name__ == "__main__":
input_file = sys.argv[1]
target_dll = sys.argv[2]
output_prefix = sys.argv[3]
output_header = "%s.h" % (output_prefix)
output_defs = "%s.def" % (output_prefix)

write_full_header(convert_to_pragma(get_functions(input_file), target_dll),
output_header)
write_defs(get_functions(input_file), output_defs)
[/code]
If you include this header in a project named after the DLL you want to intercept, in our case kernel32.dll, and rename the original dll kernel32_0.dll, paste these into the application directory, depends.exe will show you this:
Kernel32.dll Redirection in Dependency Walker
In other words, all the calls to kernel32.dll (ours) are being redirected to the original - note we've some interesting behaviour going on, because our kernel32.dll uses the real kernel32.dll...
Now, here's the magic. We do not have to redirect those functions - we could export symbols matching the names of those functions ourselves, and do whatever we felt like doing.
This is how you work out how an obscure API call is used - replace it with a stub which does two things:
  • Writes the arguments somewhere useful, e.g. a log file
  • Calls the original
It's that simple. The possibilities extend way beyond this, of course. You can write any code you like in place of the existing function call. A brief function would look like this:
[code language="cpp"]
typedef HANDLE (WINAPI *pCreateFileW)(LPCTSTR,DWORD,DWORD,LPSECURITY_ATTRIBUTES,
DWORD, DWORD, HANDLE);
extern "C" HANDLE WINAPI RedirectedCreateFileW (
LPCTSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSA,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile)
{
HMODULE hOrigLib = LoadLibrary(L"kernel32_0.dll");
pCreateFileW orig_func = (pCreateFileW)
GetProcAddress(hOrigLib, "CreateFileW");
// do something here
HANDLE h = orig_func(lpFileName, dwDesiredAccess, dwShareMode, lpSA,
dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile);
CloseHandle(hOrigLib);
return h;
}
[/code]
Of course, this method is quite intrusive, requiring copying DLLs into place. On the plus side, it works with delay-loaded DLLs via LoadLibrary, for which IAT Hooking fails. Since we're not needing to hide with this technique, for what we want it makes perfect sense.

Previous Post

How to discover SQL instances

Next Post

Supporting Windows XP SP2+ with vNext