This is just a quick paper/example on IAT function hooking.
For more information on the Import Address Table check out the previous paper found here.
For an abbreviated refresher, anytime your code dynamically links to an external dll it loads and references external functions via a table of function pointers.
In this simple sample, our base executable has a password verification routine and calls the msvcrt.dll library function strcmp to determine if the user entered password matchs the programs.
Remember i just needed a semi interesting simple demo app to show the hooking technique. Mabey a more interesting hook would be to intercept the call to a decrypting function and display the key and decrypted data. All of these things are just as easily accomplished with this technique.
So anyway..when the Windows loader loads the executable image it will also load up all dlls that the app requires. It will then wade through the imports that the exe says its needs, and place the adderesses to those functions into the import address table in the places the executable expects.
Changing which function actually gets called is as easy as changing one of those addresses in the pointer table.
The easiest way for us to accomplish this is to add our own dll to the Import table. When the Windows loader goes to initilize our dll, it will also give us the oppertunity to execute some code before the main application gets to run. In this dllmain code, we will change one of these function pointers stealing it away from the real function and pointing it instead into our replacement code.
This is a really old and really great technique for monitoring the execution flow of processes and spying on what they are doing.
The example code download contains full source for the password program as well as the hook_iat dll. I am not going to reference the specifics of the coding here as it is all there for you to look at. Instead here we will focus on a couple other more conversational points.
After we have created our dll, we need a way to have it loaded by the Windows loader (or injected into the address space of our sample executable). For this task i have chosen to modify the targets import table and add our dll so that it is automatically loaded by Windows for us. Another option would be to inject the dll dynamically to the running process. If you want to explore this route I have some free GPL code for it in the API logger portion of this project.
As for import table modifications, there are several tools i know of that can do this for you automatically such as LordPE, IIDKing, or my impreb tool available in the open source section of this site.
Mine is probably the least user friendly and most buggy but its what I used of course :P
Anyway, use whichever one you are most comfortable with, it might take a couple shots so just play with the tools and make sure you always have a backup of the original exe. To test to make sure you have it right, load up the exe in lordpe and list the import table and make sure everything looks right.
So once you have it set and loading, now we have to do one more quick tweak to the executable file before we run it. For our target exe, the Import Address Table lays in the .rdata section which is initially mapped as non-writable memory.
We need to change a function address in this section, so we will have to make sure to list the sections and change this ones charateristics to make sure it includes the Writable attribute.
Humm what other notes are worth mentioning...oghh ya, make sure that your replacement function prototype matchs that of the function you are replacing.
Also in the sample i used a hardcoded IAT address i got from disassembly. Once the exe is compiled, the IAT address cannot change until it is compiled again, so this is valid for hooking a known exe version. If you wanted to know how to calculate this offset at runtime, it can be done and I have included a text file with more details in the download package. PE parsing is not the most trivial thing, however i do have free implementations on my site here to help you out too.
Although pretty obvious, it might also be worth mentioning that once you hook the function you totally control its output. If it was say a decryption function that was returning configuration data to the parent application, you could easily intercept the decrypted data returned from the real function, display a dialog allowing the user to modify it, and then seamlessly pass it back to the parent app who would be none the wiser.
Well, ok the parent app doesnt have to be none the wiser. Technically this technique is pretty easy to detect with software checks. You would be surprised just how many hooks like this Windows natively uses! For this task i have created HookExplorer which is a GPL user mode hook scanner (see help file link for more details). While its hasnt quite reached public release at the time of writing, you can keep an eye on the software rss feed for first dibs.
IAT hooking gives you the powa to snoop, change, & control :)
Anyway, check out the code, play with the technique and enjoy your shiny new toy.
Downloads
-dzzie [dzzie@yahoo.com]