Windows Shim Database (SDB) Parser (shims)

Introduction

shims is a command line tool that targets the malware investigator, rather than the E-Discovery forensicator. The goal of the shims tool is to parse and extract components from an Application Compatibility Database (referenced here as Shim Database or SDB file) in view which applications are targeted for hot-patching, DLL injection or privilege escalation.

The Application Compatibility framework from Microsoft uses the Shim Database to identify if, and how, an application or DLL should be shimmed during process startup and/or DLL load. The default Shim Database is located at \Windows\AppPatch\sysmain.sdb and can contain thousands of entries for a normal Win7 box.

While the Window's Shim engine is used to enhance the user experience as well as resolve incompatibles between older binaries and operating systems they are running on, it can also be used (and has been used) as a launching point for malware. Specifically, the Application Compatibility framework allows installed applications on a Windows box to be patched 'on the fly' (ie. modified without a reboot), and this patch can be used to spawn other processes and/or inject undesired DLLs into the patched application. This functionality offers the malware writer another way to achieve persistence across reboots. Therefore, understanding which Shim Databases are on your system subsequently parsing those databases to extract targeted patches per application is one of the primary purposes of this tool.

How to Use the shims Tool

Below is the command menu which shows many of the options in summary form:

To extract general purpose information from one of these databases, use the -stats option. This gives summary information about the types of compatibility fixes that are in the database as well as various other metadata. Below is an example of pulling statistics from databases in the Volume Shadow copy #1. The data is truncated to just show one entry.

The output shows the various timestamps of the SDB file as well as the last time the database was updated (via the internal database timestamp labeled Database ModTime). Included in the database summary are the following: the version number, MD5/SHA1 hashes, identifier, and a number of other stats about the contents within it, such as the occurrences of the differing fixes and other elements.

Custom shims have some additional statistics that come from their respective registry entries. Of interest are: (a) the shim database 'install' timestamp and (b) when the subkey for the registry entry was modified. Below is an example of where these additional timestamps are populated in the stats output:

Searching the Shim Database

One can search the database in a number of ways, including: (a) case-insensitive substrings, (b) GUID identifier, (c) sequences of bytes used in patches and (d) TagIDs, which are keys used in the database for quick lookup purposes.

As a simple example, lets say one was interested in the shims used to inject a DLL into an application or change an application's permission level to Administrator. To craft a search to scan all the SDB's located in their conventional locations on the system volume, one could do the following:

The search syntax uses the keyword -strings with one argument containing the desired substrings to search for. If one of the substrings is found, the application entry that included the substring is returned so that one can see the context of where it was used. In this case, four application entries are found and the output is rendered in XML. Annotated are the locations of where the specified strings were found.

Looking at the Patch Internals

When looking at entries that include hot patches, one will see items that include a relative virtual address (RVA) of the targeted loaded image, an action to take (either 'match' or 'replace'), an optional module name to target and a byte sequence to use for the matching or replacing operation. The shims tool provides a summary view of this data by creating 'patch_translated' entries for each match item, as shown below:

For the above example, there are 2 pairs of match/replace entries. One can see this by looking at the matching RVA for each pair. The first pair starts by looking for the byte sequence "55 59 56 59" which equates to the ASCII characters 'UYVY'. The second pair starts by looking for the byte sequence "59 55 59 32' which equates to the ASCII characters 'YUY2'. Both of these happen to be video formats. The 'replace' portion for both of the matches are a sequence of "2d 2d 2d 2d", which equates to the ASCII characters '----', to evidently remove the video format options, should their companion match condition be satisfied.

Using various combinations of 'match/replace' entries, it is relatively straight forward to come up with any number of patterns to filter and act on. While not strictly necessary, a companion part of the Application Compatibility architecture is creating hot-patch points (or stubs) within a binary for each program or library entry point. With that said, Microsoft includes this capability in their Visual Studio Development platform, so it is pretty simple to actually build executables and libraries that contain this stub functionality in them.

The capability offered by the Application Compatibility architecture is very useful for rolling out fixes and ensuring that applications are updated with minimal user intervention and/or knowledge. Unfortunately, however, this power and flexibility offers the ability for malware writers to dynamically infect an application and cause it to do something the original author of the application did not intent it to do. While the shims tools can not tell you which patches in a Shim Database are good or bad, it can report which applications are patched and what the patch internals are.

For more information

The user's guide can be viewed here

If you would like more information about shims, contact us via email.

Downloads