Did It Execute? AppCompatCache

Application Compatability(or Shim) Cache

The Application Compatibility Cache, which appears to be more commonly referred to as the ShimCache, is used by an element of windows dedicated to, yes you guessed it Application Compatibility.

The basics concept of this feature is; when programs are written, they are usually compiled to work with the OS of the day. So as long as everything is as expected, the program runs, calls API's and the OS plays nice (round pegs in round holes).

As you can imagine only a clairvoyant would know what changes were to be made in the future, and thus makes the likelihood of any programs being able to future proof themselves highly unlikely. The other problem that exists; is that current programs would be created with excess code to ensure they work on all other previous version. These both lead to the problem of the square peg to a round hole.

Microsoft solved this problem for us, as they know what an API is calling and the differences between it and any API's on the current OS, they sit in the middle, take your square peg, and change it to fit into the round hole.

[The name Shim is a common reference, as the word means "make them fit" which is exactly what Windows is doing for us, taking something problematic and making it fit (work)]

Microsoft have a nice section on this on one of their pages - https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-7/dd837644%28v%3dws.10%29

So, what is it and where is it?

Ok, so their is uncertainty about some of this, primarily because Windows is closed source and not all aspect of this feature is documented. I have picked through a lot of blogs, slides, white papers and Microsoft tech pages, rather than writing my interpretation I am going to give you FireEye's, which is the best concise explanation:

The cache data tracks file path, size, last modified time, and last "execution" time (depending on OS). If a file is executed with Windows "createprocess," it is logged in the ShimCache. While a file's presence in the ShimCache does not 100% prove file execution, it does show Windows interacted with the file

 The cache is locating in the following Registry Key:

• On XP: 
• "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatibility\AppCompatCache"
• On Non-XP: 
• "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache"

What Data is Available:

Each entry in the AppCompatCache is preceeded by a header, this header differs depending on the version of windows you are looking at:

XP - 0xDEADBEEF.
Server 2k3, 2k8 and 2k8r2 - 0xBADC0FFE
Vista, 7 and 8 - 0xBADC0FFE
Windows 10 - "10ts"


As well as the headers differing there are other differences in the AppCompatCache, depending on the version of OS you are looking at, this determines things like; number of entries stored, the length of the entry and most importantly what data is available in the cache. Their do appear to be some consitancies in the cache, regadless of OS version which is

• The Executables Modified Time (note this is of the file itself, it not the run time, nor is it the time the registry was updated)
• The full path of the executable
• File Size

In more recant versions of windows (I am yet to pin point between which versions this change occurred) there is a new very useful flag added, which is the execution flag. denoting whether or not the program was executed. This provides us with some nice information which was not previously available, as Windows appears to 'scan' some directories for executables (probably to get ready for running them and pre-empting any compatibility issues) there may be occurrences of files which have not been executed, so this flag helps nicely.

Importance of Shutdown:

AppCompatCache data, is held in memory of a running system, if you run a parser or have a look in RegEdit, you will see a key with data which was accurate at the time of the last shutdown or reboot, (I am making the assumption that sleep will just retain the data in memory, and hibernate will probably do the same and just write the memory to disk to reload when woken)

This behavior is a key thing to remember for both Live and Static Forensics investigations.

For Live Investigations it is worth remembering so that the memory can be interrogated or dumped to get the latest information/state of the AppCompatCache.

For static (disk image) based investigation, it will be worth investigating the shutdown and startup event logs to try and identify what the devices pattern of life is, and correlate that with the time stamps of the registry key itself to identify how the data of the AppCompatCache fits in with the timeline of your investigation

I have done experiment which confirm some of this, however I haven't confirmed the process which performs the write to disk, I am relying on the words of the reputable Lenny Zeltser here.

Tools and Investigations.

The 2 best tools I have found which are easily available and easy enough to use to interrogate the Application Compatibility Cache are:

1. Mandiant's Shim Cache Parser which can parse a life system, or specified registry file.
2. Volatility's ShimCache plugin to interrogate memory

How is it used for compatibility?

This is one of the key things I am yet to understand, the cache appears to collect information on applications that are executed and sometimes that just exist on the system. It is expected that this is done to understand (as was explained at the beginning of this post, so that is can 'Shim' calls that are not valid on the current system, and to redirect them to something that does). So although there is information on the cache and its extremely useful byproduct of providing examiners with evidence of forensic investigation, I cant seem to find a lot in its original function.

There are 2 folders which seem to be associated in the %systemroot%:

• C:\Windows\appcompat
• C:\Windows\apppatch