Photo by Ferenc Almasi on Unsplash

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

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:

class SomethingImportant : SomeInterface {
  private val userCredential = "someUserCredential"
  
  fun authenticateUser(token : String) {
    if (userCredential==token) {
      doLogin()
    } else {
      forceLogout()
    }
  }
}

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:

class b1 implements c {
  private final String h = "someUserCredential";
  
  public void a(String j) {
    if (h==j) {
      vh();
    }else {
      we();
    }
  }
}

Code After Obfuscation

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.

This article was previously published on proandroiddev.com