ECSC 2018: Do Androids Dream?

- 2 minutes read - 390 words

Getting started & challenge overview

The first thing to do when looking at an application is determining whether you need to tackle it dynamically or can simply analyze it statically. To do this, I simply decompiled the apk using jadx and noticed that there was no (real) attempt at obfuscation, and decided to go forward without even running the app.

This challenge had multiple stages:

  • What message does the application show when root is detected?
  • Find the root check, and patch it out.
  • What are the admin credentials?
  • What is the secret word displayed in a hidden activity?

What did you say?

To find out what message the app shows, why not start looking at the app’s MainActivity.

The AlertDialog being build in the activity’s onCreate method.

Bingo! Line 29 is where the dialog’s message is set: “Rooted device found. Cannot run app.” Plus, we get some good hints as to where to continue…

Who needs patches anyway…

After seeing the check being called in the MainActivity by a class called RootCheck, I decided to look at what this class does exactly.

The RootCheck class, showing it’s three checks.

It’s actually some rather simple methods that check some known locations of the su binary, an older SuperUser management apk, and the device’s buildtags. If the buildtag check fails, it goes through to a slightly better detection method, which-ing for the su binary.

I decided not to run the app, so there was no need to actually remove the check from the MainActivity and rebuild.

Getting to the next base

Going back to the MainActivity, we see the isValidLogin method at the very end. The first thing it does is decode two Base64 strings, uname and pass. Guess what’s in those…

The admin credentials (techPals:cyberSecurityCTF), Base64-encoded.

Obfuscated business

There are only a few unexplored files left in this app, Hello and Registration.

Opening up Hello, we see a variable called mySecretWord, comprised of three separate strings. The last one of them is right there in the class, but for the other two we have to hunt around a bit.

The _challenge variable, which is the end of mySecretWord.

The first one is in the SharedPreferences, so it must be set somewhere. The second one is defined in the app’s resources.

When we take a look at Registration, we get very lucky:

Our instance of SharedPreferences where putString is being called.

Next up is simply opening up the app’s resources, and more specifically the app’s string values:

The variable security is right at the top of res/values/strings.xml.

The only thing left to do is concatenate our strings and Base64 decode it.