ROP and deROP

I ve been writing a lot about ROP in my past posts ( Here for a collection) covering some of the principal anti ROP techniques used by modern operative systems. Today I ‘d like to suggest another great reading from Kanjie Lu et Al. From Peking University, Cina titled “deROP: removing return oriented programming from malware.”

Many different researches put theirs efforts in finding a good ways to fight ROP malware, for example Davi et Al. And Chen et Al. Implemented a threshold system able to count how many buckets of instruction followed by RETN are present in a executable, once the threshold is reached the security mechanism alerts the user about that. Another direction is to look for violations of last-in, first-out invariants of the stack data structure that call and return instructions usually maintain in normal benign programs. Francillion Et Al. Implemented shadow return address in hardware stack such that only call and return instructions can modify the return- address stack.Davi et al. claim that it is possible to extend their ROP defender with a frequency measurement unit to detect attacks with return-less ROP. The idea is that pop-jump sequences are uncommon in ordinary programs, while returnless ROP invokes such a sequence after each instruction sequence.Most recently, Onarlioglu et al. propose G-Free, which is a compiler-based approach to defeat against any possible form of ROP.

Kanjie Lu in this paper propose a “conversion tool” able to transform the most advanced ROP-Based payloads into equivalent non-ROP Payloads able to being analyzed from normal Malware analysis tools.

Instead, we propose an automatic converter, called deRop, to convert ROP shellcode into its semantically equivalent non-ROP shellcode so that any of the existing malware analysis tools can ana- lyze it.

The following image (taken from the paper ) shows an high level overview of the designed deRop system.

The paper well describes all the process behind the development of the tool underlining main difficulties and structural choices. The authors tested their work by applying their tool on 4 real Payloads obtaining great results.

Even if the idea behind the entire work is surprising good, the developed tool presents some limitations if applied in real wokrld, for example its output is one running instance specific in ASLR, and again deRop needs dynamically executing the vulnerable application in order to locate the gadgets in the ROP exploit. But to know more about that please read the whole paper it is really a good reading ! Have fun.