Function Hijacking via Export Directory

I have been working on a contract that has necessitated the use of function hooking. Basically, I need to intercept an arbitrary program’s usage of a system dll library in order to interject my own logic, and interact with the objects produced by that binary.

There is a nice tool created by Microsoft Research, called Detours. This is basically an API which helps you to perform binary function interception and instrumentation. This API is fairly robust and well thought out, and I use it in this project. However, there is certainly a fair amount of missing functionality.

While testing my application against a popular product that uses the “unicows” library, I stumbled across a very interesting situation during which the Detours method of function interception will not apply.

Basically, unicows has it’s own custom version of GetProcAddress build in. This custom code crawls through the in memory PE header and obtains function offsets by hand. This means that, for dynamically loaded function addresses, using the Detours functionality I am unable to intercept functions loaded at run-time.

So, in order to properly intercept these functions, it was necessary to create an additional API from within Detours. This function needs to crawl through the PE header, and replace the Export Directory entry for a given API with the virtual address of the function you wish to be called, instead. The function will also return the original virtual address, so that you can call that function within your intercepted version.

The new code is here: DetourReplaceExport.txt

So, now I have a working solution for hijacking an API which is linked dynamically using a non-standard GetProcAddress. Yays!

DOS “debug” fun

Sometimes you get the urge to do some programming, but you don’t have access to a compiler. Luckily, virtually every Windows PC in the world has a utility called “debug” installed. This little program lets you input 16-bit x86 assembly language, and allows you to write it out to create a .com file. This file can then be executed inside of a DOS shell.

The following is an example of something simple but cool you can do with this program. I will be using some basic DOS interrupts in order to do console input and output. (Lookup ‘DOS interrupt 21h’ on google to find out more).

I’ll highlight everything i’m typing in green so you can try this at home. You won’t need to type the optional comments (anything after the semicolon is ignored), and they get lost when you write the file anyway.


-a 100
1476:0100 mov cl, d7 ; default cl to character 'd7'
1476:0102 mov ah, 6  ; ah:6 is console input/output
1476:0104 mov dl, ff ; dl:ff specifies input
1476:0106 int 21     ; interrupt 21 call
1476:0108 jz 10c     ; skip next instruction if failure
1476:010A mov cl, al ; save result of console input
1476:010C mov dl, cl ; load current character as output
1476:010E int 21     ; interrupt 21 call
1476:0110 jmp 102    ; loop forever!
-r cx
CX 0012
Writing 00012 bytes

Now, when you execute “”, you will see the screen swamped with the funky ‘d7’ ASCII character.

Whenever you type a character, the screen with update to display that character. Try alternating between visible characters and not visible characters (like space). For more fun, try to as quickly as possible type “|/-|/-” (animates like a little progress bar).

Note that you cant really exit the program. Pressing ctrl+c will actually just display a little heart character. It would be easy to modify the code to accept a character (like escape or control+c) to exit, but i’ll leave that up to you :].

This is just one basic thing you can make a .com file do. For a cooler example, check out neetro. Neetro is a little bit more complex than the program above, so it would have been a pain to write using “debug”. The source is instead compiled using nasm.