Native EMET third-party graphical interface

Hi,

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:

Microsoft EMET third-party GUI

-MessageBoxA

 

Glad to see this finally out and about.

Great way to use EMET.

 

I would know if NEMET has the same features in protection as original EMET...if answer is "YES" it can be very useful tool.

 

@MessageBoxA

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.

 

Hi,

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

 

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

 

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

 

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

 

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

 

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.

-MessageBoxA

 

Another request to support XP SP2. Thanks

 

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

 

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

Great I see soccerfan would also appreciate it too Be interesting to see what it can do.

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

TIA

 

I don't think any justification for this would satisfy me.

 

ROP = return orient programming

he means ROP, specifically ROP gadgets, which are really cool

 

Kinda a "security 101" situation. Update your programs - that goes x100 for your OS.

 

Why should i ? Works just fine & NOTHING gets in here unless i allow it

I'm not advocating others should do the same. Everyone can do what they like & suits them !

 

If we stopped at "it works fine" we'd be back in the stone age.

If by "fine" you mean "full of well known holes and performance problems." Yeah, that's fine.

 

You mean like digital audio is "supposed" to be better than HI Q analog stone age audio

The day i get infected i'll post here about it, but don't hold your breath

 

So the idea is to wait until you get infected to prove that the vulnerabilities exist?

 

Okay its working fine here with my setup, I am actually very pleased with the GUI.

 

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.

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.

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.

-MessageBoxA

 

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.

-MessageBoxA