These notes have be sitting around in a file for a while now. The reason we're publishing them is to both motivate ourselves and also to motivate others to continue documenting how AppCompat on Microsoft Windows works.
AppCompat is built into the Windows loader that provides a common infrastructure to patch the IAT (Import Address Table) of a process for shimming. AppCompat at its core is made up of databases / DLLs that define which shims apply to which binaries.
Why do we care about AppCompat when we're security people? We'll there are several reasons. For example there is an AppCompat patch to use a 'Fault tolerant heap'. So even applications deployed on the latest and greatest Windows may not be able to use the default heap and revert to a less secure implementation due to 'compatibility reasons' (which is code for they corrupt their heap). Knowing this information allows us to better understand our exposure.
We also see other applications for AppCompat to improve security using a Microsoft sanctioned patching mechanism. For example we think it would be great you could deploy via the AppCompat enterprise configuration VirtualAlloc replacements for all processes.
Prior Research / Database Structure
Alex Ionsecu looked into AppCompat and the database . We're not going to repeat what he said so we encourage you to go and read that first. However his SDB tool from part 4 can be built using the Microsoft APIs.
There is also interesting Chinese blog post from 2008 which details quite a bit about how stuff works (although via Google translate it's hard going).
Building Databases / Configuring Applications
If you want to see which fixes are available via a GUI and experiment Microsoft make a tool available called the Microsoft Application Compatibility Toolkit. This can be used to build new AppCompat databases and configurations. It can also be used to investigate the available fix if you don't want to implement a tool like Alex's.
Files related to AppCompat
The files on Windows 7 at least which appear to make up AppCompat are (note: does not document the loader aspects):
Application Verifier (yes it too uses the AppCompat infrastructure)
AppCompat DLL Structure
As Alex noted it appears Microsoft use a C++ class (its called ShimLib::) internally when implementing AppCompat DLLs. AppCompat is used by Microsoft technologies such as EMET and Application Verifier. For example see EMET.dll in C:\Program Files (x86)\EMET and you'll see it has the standard AppCompat exports:
- GetHookAPIs(char *,ushort *,ulong *)
- NotifyShims(char *, unsigned __int16 *, unsigned __int32 *)
During our research we found a single DLL, apihex86.dll, that doesn't use the Microsoft C++ class (ShimLib::) that the others do. As a result it's this binary that we're focusing our efforts on in order to understand the interface so we can look at writing out own shims (also its tiny compared to the others).
Looking at GetHookAPIs we see it sets up an array of structures with both the original API and the new API to be called in its place before passing the array back to the caller. In short quite simple...
AppCompat Machine Deployment
When AppCompat is used on a machine the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags is populated. For example on my machine where I have deployed EMET against a process (we've previously mentioned EMET uses AppCompat) we see a custom AppCompat (SDB) database installed:
|Click for larger version|
Then a mapping between these two databases and the EMET configured process:
|Click for larger version|
You know you're looking at something interesting when you Google 'shimlib appcompat' and get 0 results and 'appcompat gethookapi' gets you 8. Anyway that's it for now...