Control-flow processor exceptions (single-stepping on branches) on control-flow branch instructions (jmp/call/ret)

"single-stepping on branches" is processor hardware feature of x86/Intel architecture. When it is enabled, the processor generates a single-step debug exception only after instructions that cause a branch. This mechanism
allows a debugger to single-step on control transfers caused by branches. What does this imply to defense against control-flow hijacking attacks (e.g. ROP or JOP) ? 

How to defend against Stack Pivoting attacks on existing 32-bit x86 processor architecture?

Stack Pivoting is a common technique widely used by vulnerability exploits to bypass hardware protections like NX/SMEP, or to chain ROP (Return-Oriented Programing, the Wikipedia link) gadgets. However, there is NO hardware protection solution to defend against it (at least for now:-). This blog will describe a software solution to detect Stack Pivoting at run time, and I will also point out some limitations due to current processor architecture implementations.  <Please let me know if this is NOT a new idea, or NOT doable.>

New security feature - Control Flow Guard (CFG) - available in Visual Studio 2015 Preview

This blog announced that the Preview for Visual Studio 2015 includes a new, work-in-progress feature, called Control Flow Guard (CFG). 

Latest researching status of ROP/JOP attacks and defenses

Control Flow Hijacking, like ROP, becomes a hot topic in recent years since ever DEP(W^X enforcement) and SMEP were introduced in h/w processor. Based upon the papers that I read recently, this post just gives a brief introduction on the recent researching status (though incomplete) about control flow attacks and defenses. 

Control Flow Integrity (CFI)

Traditionally, arbitrary malicious code execution (e.g. caused by buffer overflow, stack or heap manipulation) is one of major threats in computer security. 

But due to the fact that there are many hardware-enforced security features are introduced in recent processors, for example in my previous post, the attackers are starting to explore the other advanced techniques.

A Run-time Non-invasive Approach to Defending against ROP and JOP Attacks

<For some reason, I cannot public it. But I'm planning to open it at some time later >

This blog presents an idea to defend against both ROP (Return-oriented Programming) and JOP (Jump-oriented Programming) attacks ...

It is a low-overhead, real-time, and non-invasive solution with no need target exploit binary/source change.