In summary, they found out that in spite of EMET protecting a wide variety of functions, EMET has a function and a global variable that turns off EMET. So they can call it or set the variable and EMET is bypassed.
Why bother with all the fancy tricks to get around the various protections when you can just ask EMET to turn them off for you?
So how does EMET prevent me from setting up the registers and directly calling NT kernel by executing SYSENTER/SYSCALL instruction, completely bypassing ntdll.dll and other (native) libraries?
I'm sure there's some sort of mitigation, curious to learn what. Otherwise EMET would be pretty useless, right?
"x86 Instruction Set Reference, SYSENTER, Fast System Call":
I guess system call numbers change between Windows versions, so shellcode that uses system calls wouldn't be portable. The author of that last paper also says that this would drastically increase the size of the shellcode.
Probably the worst thing about the new EMET is the speed hit. The new functions (EAF+) in EMET 5.5 can slow application loading from ~2 seconds to around 30.
I'm starting to wonder if Microsoft actually tests anything before releasing it these days.
Why bother with all the fancy tricks to get around the various protections when you can just ask EMET to turn them off for you?