Lie to me – Using Built-in Windows System Filters
I bit more than a week ago, I presented a brand new technical session at BriForum in Chicago. It had the title “Lie to me – Using built-in Windows system filters in virtual desktops”. In this article I want to give you a brief overview of what I shared with the BriForum attendees.
It all started in the 90’s of last century when Windows NT 4 was still new and Mark Russinovich figured out how to dynamically load a driver at start time of two really smart applications he wrote, RegMon and FileMon. Prior to this, you always had to reboot the system after installing a new driver. Mark’s tools were able to monitor registry and file system activities by injecting dynamic drivers sitting between user mode applications and those Windows system components they are talking to through the Windows API. For the first time administrators were able to observe details of Windows NT registry and file system. The good thing about the early versions of Windows NT was that administrators had an unfiltered or unmasked view on registry and file system information.
This all changed when Microsoft introduced Tsappcmp.dll with Windows NT terminal services. When applications are started in a terminal session, the Tsappcmp.dll module inserts hooks on the function calls for terminal service application-compatibility purposes. Since Windows Server 2008, this is only true for legacy applications. This means that application compatibility masking is only active when the linker option /TSAWARE is not enabled when an application is compiled. Tsappcmp.dll introduced the concept of redirecting function calls and registry access depending on the fact if the system is in install mode or in execute mode. In addition, the redirection and masking behavior of Tsappcmp.dll is configurable to a certain extend through compatibility settings and flags. Applications are not aware of the operating system lying to them.
Microsoft went even further when they decided to permit the execution of 32-bit x86 applications on 64-bit Windows, side-by-side with 64-bit applications. When the application loader of 64-bit Windows detects that an application has the 32-bit portable executable format, it injects a set of user-mode DLLs into the address space of the application – Wow64.dll, Wow64Cpu.dll and Wow64Win.dll. These DLLs are responsible for redirecting about 400 functions, a concept is called Wow64 (Win32 emulation on 64-bit Windows). 32-bit applications live in the %SystemDrive%Program Files (x86) folder and 32-bit system files are located in the %windir%syswow64 folder even though they believe they are still at the original places. The same is true for accessing 32-bit and 64-bit registry hives from their respective application types. In essence, Wow64 introduces yet another level of lies, tricking applications very successfully.
But terminal services and 64-bit compatibility was just the beginning. The next step was exposing a full framework for lying to applications. It is called “Shims”, allowing modifying the way how applications are calling into the Windows Import Address Table. Application function calls are redirected to the shim prior to calling Windows. The tool Compatibility Administrator shipped with the Application Compatibility Toolkit gives administrators access to the shim database built into all version of Windows that are officially supported today.
Finally, it is also possible to build custom filter drivers, a technology used by Microsoft and other software vendors. Microsoft App-V, Citrix Application Isolation and AppSense Environment Manager are good example for that. Since Windows Vista, file system filtering is implemented through Windows Driver Foundation and registry filtering takes advantage of the new Registry Filtering Model. But there are only few developers in the market that know how to build stable filter drivers.
But as you can see, Microsoft and third party vendors are successfully using multiple layers of masking and filtering application access to file system and registry. When combining the different ways to lie to applications, things can get really confusing for administrators. So better be aware of them, things may not be the way they seem to be…