A lesson in Android application testing and analysis

[blindfuzzy]

Note: The application was provided to me as a .apk file with no source code or documentation for the testing.

A typical workflow involves loading the app onto a device or in an emulator and testing its functionality to see what it does. Typically I monitor network the app will communicate on as in order to determine what server or servers the app talks to and what protocols it uses to do so. The application used SSL/TLS to talk to the server in this case.

Burpsuite was used to try to "man-in-the-middle" all the web traffic between the app and the server, and the app returned a SSL certificate error. The app refused to execute, which somewhat complicated any analysis on the app. (App was not pleased with the Burp certificate)

Maybe, I could fool Android into trusting the certificate (which may in turn fool the app also to trust the certificate), I then tried installing the Burpsuite certificate into the Android device’s trusted certificate storage. Some applications will check the device’s trusted certificate authority and see the Burpsuite certificate and continue on with the SSL connection.

This trick did not work on this app. What happened was that the application was using certificate pinning so that only the server’s specific SSL certificate would be accepted. No other certificates would be accepted by the app. Time to find another approach!

I installed the Android SSL TrustKiller app onto a rooted device in order to see if it would would actually succeed in bypassing the SSL certificate pinning within the app. This app will hook various SSL methods that are normally used by apps to establish SSL and TLS connections between client and server. (aka nothing to fancy going on here)

For basic android SSL functionality, it has proven effective at bypassing certificate pinning and allowing the SSL connection to be subverted. It did not work with this app and the SSL error returned and the app refused to launch. In addition, I assumed that the app had some type of checks to see whether the device was rooted and I would be back to square one with the app not starting. Time see what else I could do....

I again extracted the .apk file and used dex2jar to convert the classes.dex file into a .jar file. Using JD-GUI, I then decompiled the source code of the resulting .jar file so that I could see how they implemented their SSL certificate pinning within the application.

What I noticed was that the developers of this application had implemented some very specific checks in addition to the certificate pinning. They had implemented a custom Trust Manager to check specific attributes of the SSL certificate issued by the server against the pinned certificate, which included verification of the hostname in the SSL certificate. Since they were doing these specific checks, the iSECPartners SSL Trust Killer would not be of use at all.

Okay, so I've identified the code that does the checking....now what?

We can use apktool from there we can decode the dex (thedalvik executable code) into smali, an assembly language representation of dalvik bytecode. The nice thing about smali files is that they can be edited and recompiled into an android app (.apk) using apktool.

The first step is to disassemble the application:

Code: [Select]

apktool d <apk file name>
Once this has finished, there will be a folder created with the same name as the original apk file. Inside this folder will be subdirectories:

Code: [Select]

<apk file name folder>
-- assets
-- original
-- res
-- smali
-- unknown
Underneath the smali folder, you will find all of the .smali files for each of the classes within the original .apk file. From the analysis in JD-GUI, I knew the classpaths for the files that contained the SSL checking. I then edited the corresponding smali files for the classes and removed the SSL certificate checking methods. In this case, the classes were throwing some SSLExceptions if the certificates did not match. I just commented out the code that threw the exception and told the app to return normally (without having thrown an exception).

Once the smali code has been edited, you can recompile the smali code back into an .apk file.

Code: [Select]

apktool b <apk file name folder>
Apktool will scan the smali code and rebuild it into a .apk file that you can run on your device.

Digitally signing the .apk IS required before you can run the .apk on your device.

There's a link a the bottom with further information. on how to sign the app.

After a few tries and tweaking within the .smali files and finally recompiling everything, I was successfully able to get the app to talk to its server through Burp. Win.

This just goes to show that no app is safe. And android developers should implement various "checks" along the way to ensure non-malicious data is being used within their app. Developers should not just rely on the "Top 10" to ensure their apps security but try and think outside of the box and ensure proper auditing before their app hits the mainstream.

developer.android.com/tools/publishing/app-signing.html