Bypassing Award-Winning ($50k) EMET 3.5's ROP Mitigations

I have managed to bypass EMET 3.5, which is recently released after Microsoft BlueHat Prize, and wrote full-functioning exploit for CVE-2011-1260 (I choosed this CVE randomly!) with all EMET’s ROP mitigation enabled.

http://support.microsoft.com/kb/2458544

EMET’s ROP mitigation works around hooking certain APIs (Like VirtualProtect) with Shim Engine and monitors their initialization.I have used SHARED_USER_DATA which mapped at fixed address “0x7FFE0000” to find KiFastSystemCall address (SystemCallStub at “0x7FFE0300”), So I could call any syscall by now!By calling ZwProtectVirtualMemory’s SYSCALL “0x0D7”, I made shellcode’s memory address RWX. After this step I could execute any instruction I wanted. But to execute actual shellcode (with hooked APIs like “WinExec”) I did patched EMET to be deactivated completely. BOOM! you can use both this methods for generally bypassing EMET ROP mitigations in other exploits, all you need is to bypass ASLR.

Demo on Youtube
Here is the asm code which makes EMET 3.5 deactivated  And actual exploit. </div>

UPDATE : MS claims it was aware of this kind of bypasses, so I bypassed EMET ROP mitigations using another EMET’s implementation mistake. EMET team forget about the KernelBase.dll and left all its functions unprotected. so I used @antic0de’s method for finding base address of kernelbase.dll at run-time, then I used VirtualProtect inside the kernelbase.dll, not ntdll.dll or krenel32.dll. you can get new exploit at the end of this post.

This is imported from my old WP blog, some links might be broken, link to the original post.