An interesting “bug” came up in my emulator today. I was resolving a GetProcAddress to the wrong import (as compared to a live program). I hadn’t noticed this before, because I had accidentally set my emulator debug mode to do a one time correction of any discrepencies, by copying the relevant memory contents from the live program at load time.
What I discovered, was that GetProcAddress was actually being resolved to point somewhere in SHIMENG.DLL; but for all purposes was equivalent to the original GetProcAddress. I couldn’t find a name to match the address using the Microsoft debug symbols, but it did show the prototype as being the same as GetProcAddress.
Infact, SHIMENG.DLL is part of a compatability layer implemented in Vista. It allows for import hooking, and these hooks can replace the function of any specific API. This allows for the implementation of legacy API functions that would since be considered obsolete. It also allows for legacy beahviour to be implemented.
Apparently, using the microsoft application compatability toolkit, shims can be created for specific executables. The idea is that you load into the shim database information for those legacy applications.
The PE loader if it is to implement a shim must also hook GetProcAddress since the address it returns must point to the correctly hooked function also. This is what I think is happening with GetProcAddress by default in Vista. It points to the shim version.
There is not a whole lot of documentation on the shim engine used in Windows, but its certainly interesting to note.