Friday, November 04, 2011

Microsoft® EMET third-party GUI

Around this time last year I was working on a contract implementing a service running on a Microsoft® Embedded XP device that required a high level of security. Unfortunately I knew that Embedded XP did not have the SEHOP and ASLR protections of modern operating systems such as Windows® Vista and Microsoft Windows® 7. Because my service was communicating over the WAN it could potentially be vulnerable to zero-day exploits.


 

The Problem

    I really wanted to use the Enhanced Mitigation Experience Toolkit for providing SEHOP and pseudo-ASLR but unfortunately the EMET graphical interface was implemented with the .NET Framework. This imposed several problems; I had very limited drive space to work with... the operating system was installed on a 512 megabyte Secure Digital (SD) card. The operating system and other various tools consumed most of this space. Also because the device was designated as High-Security I did not want to increase the attack surface by installing the .NET framework. There have been many vulnerabilities found within the .NET framework over the last few years.

The Solution

    I began developing a custom graphical interface for the EMET package. But first there were a few hurdles I would need to overcome. The first problem I encountered was the archaic Application Compatibility Database engine that was being used. I began reverse engineering this beast and it appears to be similar to the old hash-bucket databases we used back in the old Unix days. Somewhat similar to the old ndbm, dbm and gdbm. The problem was that the AppHelp.dll that is distributed with Microsoft Windows® XP is missing many of the functions for creating and writing to the Application Compatibility Database.

    There were a few other issues such as figuring out how the mostly-undocumented Boot Configuration Data (BCD) store is implemented. On operating systems prior to Vista I could simply change a few registry keys and modify the boot.ini but to make my software future proof I would need to support the BCD.

    I recently added the ability to install and configure EMET on ComputerA and export all of the settings and package all of the binaries into a redistributable package ready for installation on ComputerB. I also wanted to expose more of the EMET internals to the end-user such as heap pre-allocations.

Final Thoughts

    If you are interested in using the third-party graphical interface for the Enhanced Mitigation Experience Toolkit you may download it here.

Download: Native EMET graphical interface
MD5: B8FB870B831954EC6FB6580F72E4AF83
SHA1: 806E50C3A7BF38363E045BD1B5CA42351D40DB3B

About Me

Welcome to my blog. My name is David Delaune and I have been developing software for over twenty years. I came from a Unix background and moved to GNU/Linux around 1994 and finally started developing on the Microsoft Windows platform around the year 2000.

Recent Posts