In last couple of years, I’ve been increasingly working on penetration testing mobile applications. I must admit: this is fun. Not only it’s a combination of reverse engineering (static analysis) and active packet/request mangling, but mobile applications bring with them a whole arsenal of new attack vectors (I plan to cover these in a series of diaries since I held a presentation about that last week at SANSFIRE – we’ll post the handler presentations on the web site soon too; and I also attended the SEC575: Mobile Device Security and Ethical Hacking course with fantastic Chris Crowley, one of the best SANS instructors for sure).

With Android and iOS being two main mobile platforms today it’s logical that most of the mobile penetration tests are concerned with them as well. Here and there I see Windows mobile, but since even Microsoft is giving hope on this platform it appears that we can safely decide to cover Android and iOS only.

Android being more open, I prefer to do penetration testing on Android applications. Typically, when an organization creates applications for several mobile platforms, they use same server infrastructure (i.e. web services). This is logical – it would not make sense to have multiple server infrastructure that basically performs same activities for all platforms.

My process is to do the test on the Android application and then verify findings on the iOS app – if it uses the same server side infrastructure and if it handles local information correctly (and same as Android).

Does obfuscation help?

On Android, many developers use ProGuard. ProGuard is a Java shrinker, optimizer, obfuscator, and preverifier. It is useful as it makes an APK file as small as possible, however in that process the class, method and variable names get obfuscated so it is much more difficult to analyze such applications. You can see one (a bit extreme) example below:

In most of my engagements, I ask for a build without ProGuard. I guess my success ratio is around 50% - quite often I get the response back which says: This is how our production application looks like, and you, as an attacker, should be able to circumvent those protections, otherwise the application is secure.

After such an answer we go through the long cycle of explanation why obscurity is not security: why ProGuard adds nothing but delays activities a bit. And since penetration testers are almost always limited with time (which is not a problem for an attacker, once the application gets published), it is not in company’s interest to waste a penetration tester’s time on deobfuscation. Sure, this should be noted as maybe an additional control (albeit weak).

While the screenshot above looks very difficult to analyze, even jadx, my favorite decompilation tool available at https://github.com/skylot/jadx can deobfuscate it a bit so it’s easier to work on such an app – just selecting Tools -> Deobfuscation, we get the following listing, which is much easier to read. Import this into your favorite IDE and off you go:

If you perform penetration testing, how do you deal with obfuscation? Let us know!

--
Bojan (https://twitter.com/bojanz)
INFIGO IS