TL; DR: In this third and final post we will see the final resolution of the challenge, using apktool to achieve the protection of anti emulation! Here you can access Part I and Part II

Apktool resolution:

First we need to decode our application, and put all the code inside a folder. I called mine “reverseme_apktool:

We can find the method we are interested in, by looking for the “checkIfDeviceIsEmulator” string inside the “ReverzeMe1” folder.

As we can see there are different “const-string” declarations, having as the second argument a descriptive string such as “generic”, “unknown”, “google_sdk”, “Emulator”, “Android SDK built for x86”, and so on. So, remembering the Java’s implementation of the validation function:

Is easy to see that, if we bypass those checks “maybe” we could bypass the DeviceEmulator protection. So, let’s do that!

First I searched all the const-strings validations and I did some modifications:

After the modifications, we have to re-build the application.

After this step, you should have the modified application already built inside the /dist folder.

Now we’ve created the “ReverzeMe1_modified.apk”.

The next step is signing the application with “apksigner”, but before doing that we need to create a singkey. We’ll use “keytool” for this purpose.

Now that we’ve created the certificated, we can use “apksigner” to finish the process.

Of course the last step is installing the application in our Emulator.

We can see a “WARNING” first and then a “Success” message(for now don’t worry about the Warning). Let’s run the application on the Emulator.

And now we have a different message!! We passed the first validation, the message changed from “The Device is not supported” to “Wrong Password”. Now we can run the application inside an Android Emulator without any problems.

To solve the “password validation”, we can go back to analyze the decompiled code.

We can see the password validation is done against the “pass” variable. It should be easy to see that if we change the condition in which the “editTextPassword” value is compared to the “pass” string, we can obtain the flag. Searching inside the apktool folder, we find the “pass” declaration.

After seeing this I asked myself, what is the use of “const v4, 0x7f0c0053”? When I converted the hex code to decimal I obtained “0x7f0c0053 = 2131492947”, and by searching that I could find “public static final int editTextPassword = 2131492947;”

Basically is the identifier of editTextPassword. Now we can look for the smali code the implementation of the “if” condition, that determines whether our password is right or wrong.

The next step,modify the Boolean condition:

After that I repeated the manual patching steps, but since modifying an application can be a repetitive process I’ve developed a simple tool called “signing_tool” for which I might write something about in the future.

apktool b zipalign apksigner adb install modified_apk

Here we’ve some screenshot of the process:

We used -i in order to install the necessary apps.

After that we can use “All steps in one” option (-a):

And voila! no matter what the input is, the login application is bypassed!

Future challenges:

Like I mentioned at the beginning of this post, I will be writing about some other Android protections and about validation in differents applications like: “MDM”, “Secure Vaults” and more! Stay tuned on @juanurss.

If this post was useful for you share it!

Thank you very much to @fel_d and @rieragerman for your help!!