void main()My next main coding project to attempt will be for Microsoft's EMET (Enhanced Mitigation Experience Toolkit — Dick Cheney had nothing to do with it). The actual EMET protection methods will remain the same (I don't know how to implement those!). OpenEMET will be a small, lightweight, 100% "native" configuration interface (and Notifier) that doesn't require installing the .NET Framework — for people that don't have it installed for anything else, or simply don't like it. :-) A program called NEMET ("Native EMET") was created a couple years ago, but it's never been updated to support features of newer EMET versions (like a Notifier); plus, I don't think it's even very "native" (look at it).
I intend to create a feature-complete*, transparent drop-in replacement for EMET (CLI/GUI/Notifier). Not sure if there are any small enhancements I can make that haven't already been added to EMET 4... And there will probably be a couple small "eye-candy" things missing from the GUI or Notifier (where they're using some .NET stuff).
*One feature I don't think I can implement is the "SSL Certificate Pinning" that was added in EMET 4 (implemented in the Agent/Notifier). I'm not sure how big of a deal that is, and they only have it configured for 32-bit Internet Explorer so far, but it sounds like it can be applied to other [32-bit] programs as well. I looked at it briefly but couldn't figure it out — it appears to send every IE SSL Cert to the Agent for checking, but I really have no idea how to decode that or what to do with it. If anyone wants to help with this part sometime, that would be cool! It might be fairly simple for someone familiar with Windows' Cryptography functions. :-O
Anyway, I decided to put up this page to provide any progress updates... If/when anything changes, I'll post an update here!
April 1: This is no April Fools' joke — OpenEMET is coming! About 3 weeks ago, I was wondering, once again (I had several times), about HOW I could implement EMET Agent's SSL Certificate Pinning feature (referenced above as probably not possible). While I didn't think the feature was that big of a deal anyway (just works with IE by default, etc.), I don't like the idea of doing something "part-way," and especially so when I'd like to make OpenEMET 100% feature-complete with the real EMET (seamless, drop-in replacing of any/all components: CLI/GUI/Agent).
So I went back and de-compiled Agent's .NET code again (I only discovered .NET decompiling a couple months AFTER manually reverse-engineering the creation of the .sdb AppCompat file!). I hadn't lookly closely enough the first time to notice the Cert* functions that the .NET functions are wrapping. e.g. Beginning with CertCreateCertificateContext, I think. Discovering how the certificate-verifying stuff works (presumably, I haven't tested any code yet) was HUGE for me, and renewed my enthusiasm for getting OpenEMET released! :-) Apologies the project has been dead for so long, messing with other things; although a year since I got the idea isn't too bad for me, really; and considering I have no experience putting together several complex-to-me parts of a program. :^)
While it would have been nice to have OpenEMET available some months before XP updates ended, I now have a special date in mind (can you find/guess it?) when I'd like to have a functional beta release — all components with a good amount of functionality, which probably would not include the Certificate Trust feature at first.
P.S. I believe I can also implement the EMET "Early Warning" reporting system (to Microsoft, although I doubt too many care about this? N/A on XP), which simply uses Windows Error Reporting functions on Vista+.
November 6: Well! Exactly 5 months later! :-( Sorry for jumping the gun so much, and thinking I'd have OpenEMET available by now... But, good news is that everything's still the same, just delayed by 5 months, LOL.
Good news (read: important "progress") is that back in mid-August (yeah, 2 months late), I spent a few hours total, over 2-3 days when I could during a 10-day window or so, and I think I was able to successfully emulate EMET in creating the .sdb AppCompat file, etc. (I didn't actually try it, but the sdb2xml dump is identical). That's ALL so far! Since I'm a Windows dev. n00b, I also spent a good amount of that time figuring out how to create a working "static import library" (I think?), which the compiler (linker) needs so Windows know where to load the Sdb* functions from — EMET's SdbHelper.dll on XP; otherwise AppHelp.dll. (That's because there's no included headers/.lib's for Sdb* stuff, and I wanted to make them (and learn) instead of manually loading each function with GetProcAddress! :-P Although I think that's what will actually wind up happening with delayed DLL loading, if I want to just "fall back" to SdbHelper.dll on XP. I can't remember right now, but I digress...)
Anyway, when I resume something soon (or earlier ;^)), it will be to create the corresponding AppCompat/EMET registry stuff. Again, I've never used registry functions, but should be fine and fairly easy. After that...? Quick-and-simple GUI design? Or CLI EMET_Conf first? Basic Notifier? Not sure what to concentrate on and release first, but don't want something too basic after so long!
You WILL see updates here when anything happens. :-)
June 6: Next week, after Windows updates, I plan to finally reinstall Windows and everything on at least one computer that I've been waiting months for, so it may be awhile before any coding stuff continues. However, before then, I'm gonna try to finally get some basic working code to create EMET's AppCompat .sdb file. I figured out the basic overview to do this back in March thanks to WinAPIOverride's monitoring, but never tried to replicate EMET myself. Since Windows XP lacks Sdb* functions to actually write stuff to the .sdb file, I'll need to commando commandeer EMET's SdbHelper.dll file (on XP), so that's what I'll use for initial testing. This needs to work before anything else. :-)
End of May: Since I'm pretty sure I can't legally distribute some necessary files with OpenEMET (like the actual core EMET.dll!), I wasn't sure of an easy way for users to supply them. After using Universal Extractor to extract EMET's .msi install file, I realized it's just using msiexec /a (see UniExtract source; or this). That means users would only need to give OpenEMET the real EMET installer, and I can easily grab the files needed. Excellent!!