Photo by Ferenc Almasi on Unsplash

Living Dangerously without Obfuscation

A story how I (seemingly) hacked an Android application from a unicorn startup

Background

First and foremost, this is not a “How To” or even a step by step tutorial to hack an Android Application.

This is my journey when I started learning how important it is to implement secure coding to the project—and some takeaways that I would like to share when taking this journey.

For the context, I’m an Android application developer and I love learning all about Android development. I’ve taken some projects related to smart house and VOD platform at my previous workplace. During my time there, I caught an interest in securing Android application using obfuscation.

Because no application is safe from Reverse Engineering—where you can decompile an APK to its original form (decompiled .java classes), and see how it was built. There’s a saying:

“Every application is open source if you know Assembly”

Reverse Engineering (Oversimplification)

So my understanding is:

“Obfuscation is a way to make it harder for people to read your code from your project when you published it.”

For example, if we have this code sample in our project:

Code Before Obfuscation

This chunk of code will stay this way even after being compiled into an APK. But with obfuscation, you can make your code look like this even when decompiled:

Code After Obfuscation

Obfuscation shortens the name of classes and members, which results in reduced DEX file sizes.

Setup

So learning this new thing, I want to put my newfound knowledge in play. I started to reverse engineer some applications to see how secure they are and, if they’re not secure enough, how the apps were built and what libraries were used.

To achieve this, I used:

• Visual Studio Code: IDE for opening the project and general coding
• APK LAB: OpenSource Android reverse-engineering Tools
• Dev Tools Pro: To pull APK from installed application

There’s this one application that developed by a startup that got my interest. Let’s call it ABC app.

So I installed the ABC app on my device, use Dev Tools Pro to get the APK from it. Then I moved the APK to my machine, opened Visual Studio Code and ran the APK Lab to decompile the APK.

To my surprise the code was not obfuscated properly, and you can still read most of the code and learn how they work.

Decompiled code

Knowing this, I couldn’t help myself to further browse all their codebase. I learnt everything I could from their code, their infrastructure, and their libraries.

Aha. Libraries. What libraries did they use?

After looking through their code for a while, I happened to read what seemed to be code for dependency injection. And in there, they used OkHttp and Chucker to log their API call. So I started wondering,

“Their released application doesn’t display the Chucker log in the notification bar, but the code is there. Is it possible to display the Chucker log?”

Using APK Lab, you can compile the decompiled APK to APK again (So I guess reverse reverse-engineering). At first, I started the changing the Java files and compiled them again into an APK. But this didn’t seem to work because there was no changes after my modification. My prediction is that the APK Lab doesn’t use the Java files to compile them into an APK again.

So I started looking at the Smali files that were decompiled along with the Java files. And if I’m being honest, I didn’t know a single thing—and still don’t know much—about Smali, let alone coding using it. But I was able to locate the Smali code where the dependency injection was added and the Chucker log is not being implemented.

There was just one small step to enable the Chucker log: Simply add the ChuckerInterceptor to OkHttp in the Smali file. So without any knowledge whatsoever, I started some trial-errors to implement that in the Smali code I found.

Final Smali code used to display Chucker Log

After countless errors, I thought I was starting to recognize the pattern in code for Smali. And voilaaa… the compiling succeeded. I ran the compiled APK from APK Lab to my device. And it was there!

Chucker Log

Using the Chucker log, I was able to see their HTTP requests, responses, and the list of all their APIs.

Sample Response from ABC app

Conclusion

At the time, I didn’t know how big of a security risk if something like this ever happened to a published application with thousands or even millions of active users.

Update: ABC app already patch their app and doing something like this will not give the same result

I strongly believe something like this should not happen in a production application published to end-users. What we can learn is:

• Obfuscate your code properly! You might be already obfuscating your code, but is it already hard enough to read? If you’re using ProGuard or DexGuard as your obfuscation tools, perhaps you might put too much keep configuration that can remove all the advantages that obfuscation brings. You can read this for more information about differentiation in keep configuration.
• Use the library properly. Chucker is very useful when developing, but should not be used in production. Using debugImplementation when declaring dependency like this is a must.

Thanks for reading my story.