Bypassing Android Anti Emulation part III

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 place 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 in 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:

It is easy to see that, if we bypass those checks, we could maybe 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 have 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 will use keytool for this purpose.

Now that we have created the certificate, we can use apksigner to finish the process.

jus@saguw/ho/android/Challenges/reverseme/resolution  
╰─/Users/jus/Library/Android/sdk/build-tools/26.0.1/apksigner sign --ks ~/.android/debug.keystore --ks-key-alias signkey ReverzeMe1_modified.apk
Keystore password for signer #1:

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

We can see a WARNING first and then a Success message (for the time being, 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. We can then run the application inside an Android Emulator without any problem.

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 observing 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, it 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 is modify the Boolean condition:

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

1. apktool b
2. zipalign
3. apksigner
4. 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 different applications like: MDM, Secure Vaults and more! Stay tuned on Just Mobile Security — Medium.

If this post was useful for you share it!
Thank you very much to @fel_d and @rieragerman for your help!!

Don’t forget to follow us!

Just Mobile Security | LinkedIn

Juan Urbano Stordeur (@juanurss) / Twitter

This article was written by Juan Urbano Stordeur CEO of Just Mobile Security