There is a native (written in C++/assembler) EMET GUI available for those who do not want to install the .NET runtime but still want to use Microsoft EMET:

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.

...

I began developing a custom graphical interface for the EMET package. But first there were a few hurdles I would need to overcome...

I'm having issues adding applications. When using add application under the administer menu or using protect process via right click, neither are working. To confirm this, if I right click on an process via right click and click on unprotect process, it says this process is not protected by EMET. I've tried with various processes FYI.

Hungry Man Thanks for your help during the alpha stages of development.

ichito: Yes the graphical interface has all of the features of the EMET GUI plus a few extra features. I am working on a replacement for the EMET DLL that has all of the EMET features plus a few Anti-ROP techniques.

1chaoticadult Thanks for the bug report. Could you be more specific? Are you by chance testing with notepad.exe? There are usually multiple notepad.exe files... one at C:\Windows and the others at C:\Windows\System32 and C:\Windows\SysWOW64 on an x64 system. If you are protected the executable located at C:\Windows... and then opening a .txt file... it is probably opening the executable at C:\Windows\System32. Same holds for write.exe and some of the other executables that actually launch other applications.

Let me look into this a bit more and see if I should do something a little more intelligent here.

Hungry Man Thanks for your help during the alpha stages of development.

ichito: Yes the graphical interface has all of the features of the EMET GUI plus a few extra features. I am working on a replacement for the EMET DLL that has all of the EMET features plus a few Anti-ROP techniques.

1chaoticadult Thanks for the bug report. Could you be more specific? Are you by chance testing with notepad.exe? There are usually multiple notepad.exe files... one at C:\Windows and the others at C:\Windows\System32 and C:\Windows\SysWOW64 on an x64 system. If you are protected the executable located at C:\Windows... and then opening a .txt file... it is probably opening the executable at C:\Windows\System32. Same holds for write.exe and some of the other executables that actually launch other applications.

Let me look into this a bit more and see if I should do something a little more intelligent here.

-MessageBoxA

Click to expand...

Actually MessageBoxA, I tried on 3rd party processes not system. I tried firefox, skype, aimp and a few others.

Actually MessageBoxA, I tried on 3rd party processes not system. I tried firefox, skype, aimp and a few others.

Click to expand...

Keep in mind that the changes are not saved until you exit the NEMET application. So if you are protecting an application... it is not actually protected until you exit NEMET. This is exactly the same behavior as Microsoft EMET. The reason both Microsoft and I did it this way... is because of limitations in the ancient database technology being used in the application compatibility engine. The Microsoft application compatibility database is using 1960's technology... a hash-bucket database similar to some of the first Unix databases ever created.

When you make a change in NEMET... such as adding protection on a new executable... the changes are not written until you exit nemet. Again... same behavior as Microsoft EMET.

Keep in mind that the changes are not saved until you exit the NEMET application. So if you are protecting an application... it is not actually protected until you exit NEMET. This is exactly the same behavior as Microsoft EMET. The reason both Microsoft and I did it this way... is because of limitations in the ancient database technology being used in the application compatibility engine. The Microsoft application compatibility database is using 1960's technology... a hash-bucket database similar to some of the first Unix databases ever created.

When you make a change in NEMET... such as adding protection on a new executable... the changes are not written until you exit nemet. Again... same behavior as Microsoft EMET.

-MessageBoxA

Click to expand...

I understand you need to do this as I have used EMET for a while. I assumed you knew I was doing this already.

When i saw it was NET free, i thought i'd be able to try it out Unfortunately it still requires SP3 Which i don't want/need

Hope others like it etc

Click to expand...

Heh, you are *very* adventurous to remain on XP with less than SP3. I can probably add support for SP2. I think it actually works... if I just remove the code making the service pack check. Can't even remember why I excluded the prior service packs. Keep in mind that hardware DEP is not supported in ntoskrnl prior to SP2 on WinXP.

Btw, my 'professional advice' is to upgrade to SP3. Hell.. come to think of it I would recommend moving to x64 Win7 for SEHOP/ASLR.

Heh, you are *very* adventurous to remain on XP with less than SP3. I can probably add support for SP2. I think it actually works... if I just remove the code making the service pack check. Can't even remember why I excluded the prior service packs. Keep in mind that hardware DEP is not supported in ntoskrnl prior to SP2 on WinXP.
-MessageBoxA

ichito: Yes the graphical interface has all of the features of the EMET GUI plus a few extra features. I am working on a replacement for the EMET DLL that has all of the EMET features plus a few Anti-ROP techniques.
-MessageBoxA

Click to expand...

Thanks for explanation...but one question - "Anti-ROP" or "Anti-DROP"?

Even with your comp Fully updated with ALL patches etc, how would you be protected against undisclosed bugs & Zero Days etc ? You wouldn't ! Apart from safe surfing & common sense, which is what i do, & have been doing for years. Plus those nice Apps, including ShadowDefender. So NO worries here at All Whatsoever

I find it extremely satisfying that i've been able to venture to All the infected www's i have done over the years etc, & not once been infected with how my comp is set up

Anyway you're going OT with this, as i was responding to MessageBoxA with my details.

Sorry about the delayed response, even with my vampiric blood I need to rest in my coffin every once in a while. But now I am back in my dimly lit dungeon and ready for another 18 hours of strong coffee and rapid keyboard smashing.

CloneRanger said:

Not really, i have some Very good Apps installed This might make you gasp even more. I don't have ANY updates for XP/SP2 either No problems with Malware etc here

Click to expand...

Heh, I believe you. I have also been experimenting with hardening older OS such as Win3kServer and XP over the last 2 years. I have 13 honey boxes running fully patched XP-SP3 and 24-hour automated internet surfing. The bad news is that they get owned every few months from a zero-day.

If there is any advice you would take from me... I would suggest installing WehnTrust simply to get the ASLR and SEHOP. The boxes on my automated network running with this setup have demonstrated durability and immunity to many of the zero-day.

CloneRanger said:

One thing i wondered though, does your App actually install EMET ? Because EMET won't install on XP2 as it is first.

Click to expand...

Yes, if you install Microsoft EMET on Computer-A and open NEMET... and choose "Create Redeployment Pack" from the menu... it will create a zip file containing the EMET DLL along with all associated registry keys. You can then go to computer-B and open NEMET and choose "Install Redeployment Pack" from the menu and it will have effectively installed EMET and migrated all of the settings. I don't think it would be legal for me to distribute the EMET.DLL from my website.

Stay tuned... NEMET will probably not depend on the Microsoft EMET.DLL in the near future. It was actually trivial to implement all of the mitigations EMET.DLL provides. I am in the testing phase on a replacement library. (I am actually a lone-wolf developer so if there are any security companies interested in my work feel free to contact me)

I also need to do some soul searching and think about where I am going with my software. To be perfectly honest... I think Microsoft EMET would be much better if implemented as a device driver. It would give me much more control over ASLR and a better SEHOP. I may end up re-writing the whole thing as a device driver with a usermode interface... but Scape/Wehnus has essentially already done this with WehnTrust although I don't like his wierd DLL-cache implementation.

Thanks for explanation...but one question - "Anti-ROP" or "Anti-DROP"?

Click to expand...

Hmmmm, lets see if I can put this into laymen terms...

Have you ever watched those horror movies where the serial-killer cuts words out of the newspaper and glues them all onto a sheet of paper and sends a long message to the police or media? (yeah, I have apparently been reading too many Steven King novels...)

Heh, ROP (return-oriented programming) sorta works the same way... the instructions in an executable is like the book... and if I can get control of the call stack... I could JMP to a location... execute a few bytes of code... and return... maybe jump-pivot and JMP somewhere else. No need for shell code... your browser and dependent libraries have all of the instructions already in-place. (EAF might help here... because the attacker probably needs to know physical offsets from PEB... but in a browser the attack can meta-refresh or send location header and brute force to find offset)

Anyway it is really hard to defend again this... but I can check the value of the ESP register in some often-used locations. In a future version if I move away from the Microsoft EMET library... I'll be implementing some of these techniques.