Android application obfuscation

I had the opportunity to attend 2013 RSA last week. Compared with less than five vendors last year, there were more than 20 vendors focusing on mobile security. I found something interesting on android application obfuscation. Arxan was one of them. This company showcased its Mobile Application Protection Suite to protect code integrity and intellectual property from reversing engineering mobile applications. It works in the similar approach as PE packer by obfuscating codes and injecting scramble code instructions. Another vendor, Allatori, also provides similar services.

With more and more techniques of mobile app obfuscation on the market, it is possible that hackers will leverage them to mass-produce mobile malware by repackaging the obfuscation shell around known malicious codes, just like what had happened in PC threat landscape.

In this blog, I will do DEX analysis 101: reverse engineering a few repackaged samples. DEX file contains most program codes of Android application package file (APK). I use 101 Editor as the tool to view DEX files. 010 Editor offers generic interface for various types of file format. In this case, after I downloaded DEX template file and imported it into 010 Editor, I can go throug DEX format, shown as the following:

One sample was processed by zipalign so its DEX content was the same as the original file. It still had 116 strings. Other files was injected with some codes or their strings was encrypted. As the result, they showed different number of strings, methods, and even classes.





Afterwards, I submitted them to Mobile Sandbox online service (www.mobile-sandbox.com) .
The output reports showed that they shared the same behavior activities.



It is a simple demo. However, the concern behind it is that we need to keep track of each application coming out of application obfuscators (by certificate?) The "mobile packer" software companies should work with security vendors so that the latter can determine if a submitted sample with a certain certificate is malicious or not. For more details, please refer IEEE taggant system.

The move to plugin-free browsers

Apple was the first major player to offer a browser with no plugins with Safari for iOS. Even the very popular Flash plugin cannot run in the browser. However, no vendor, including Apple, has had such restrictions on their desktop products.

Microsoft has now also gone plugin-free with Internet Explorer 10 Metro. This version of Internet Explorer does not support plugins (except for the embedded Flash plugin which is a allowed on a few whitelisted sites only). See "Get Ready for plugin-free browsing" for additional details.

Chrome and Firefox are also moving in the direction of plugin-free browsers too. The first step is Click to Play, which enables plugins only after an interaction from the user, not by default. With the release of Firefox 19, Mozilla has removed the need to leverage the Adobe Reader plugin by providing a JavaScript based PDF reader. Firefox is also going to enable Click to Play by default (except for Flash) in the next releases.

Blame the plugin vendors

HTML5 is helping browser vendors to get rid of some plugins, like Flash. For example, the standardization around video and sound means Flash is no longer the only option to play a video on modern browsers.

But the main drive toward plugin-free browsers is security.The latest Java vulnerabilities actively exploited and leveraged in successful attacks against Facebook and Apple, are just the latest flaws exposed in Java, Flash and Adobe Reader plugins.

Because these plugins live outside of the browser, they cannot be updated automatically by the browser vendors. Our State of the Web reports continually show that users are slow to update their plugins, even after well publicized vulnerabilities are found.

Not the end of vulnerable browsers

The end of the plugins does not mean the end of vulnerabilities in browser, just fewer of them. This month Microsoft patched about 11 security flaws. But unlike vulnerabilities in plugins which can be exploited in all browsers, browser vulns are specific to each vendor.