Android

Mobile Pentest 101

© tsug0d, September 2018
Lecture 4 – Reversing The App
Goal: Got some basic reverse skill on android app
Inside the apk
- APK (Android application package) is an app creator for Android, it contains all the elements that an app
needs to install correctly on mobile device
- Like EXE on windows, you can place APK file on mobile device to install. Manually installing apps using APK
is called sideloading
- Below is a list describing the most prominent files and folders:

• META-INF/: Contains the manifest file, signature, and a list of resources in the archive
• lib/: Native libraries that run on specific device architectures (armeabi-v7a, x86, etc.)
• res/: Resources, such as images, that were not compiled into resources.arsc
• AndroidManifest.xml: Describes the name, version, and contents of the APK file
• classes.dex: The compiled Java classes to be run on the device (.DEX file)
• resources.arsc: The compiled resources, such as strings, used by the app (.ARSC file)
Inside the apk
- APK files are a type of archive file, specifically in zip format-type packages, based on the JAR file format,
with .apk as the filename extension.
- So we first unzip it:

unzip-ing
Inside the apk
- We can see what we said above

- But it’s not good enough for our reversing phase ( because it’s just unzip, and most of the file is in binary
format ).
- Let Decompile it!
Inside the apk
- APKTool is the very first tool you want to use, it is capable of decompiling the AndroidManifest file to its original
XML format, the resources.arsc file and it will also convert the classes.dex ( and classes2.dex if present ) file to an
intermediary language called SMALI, an ASM-like language used to represent the Dalvik VM opcodes as a human
readable language.
- Type command:
apktool d InsecureBankv2.apk
- Once finished, the InsecureBankv2 folder is created and you’ll find all the output of apktool in there ( included smali
code ).

- You can also get java source code using dex2jar (output is jar file)
- Read the java source code in jar using jd-gui

Just inform the basic, no need to follow, we can do all the task with
ByteCode Viewer ( remember? J )
smali
- We will talk about SMALI, let look at some smali code
- Load the apk to ByteCode Viewer
- Choose like this:
smali
- Now open Insecurebankv2.apk/com/android/insecurebankv2/DoLogin$RequestTask.class, we got
smali code in panel 2
smali
- Remember the “devadmin” bypass login? We will take a look at it in java bytecode (smali) J
smali
- So we first find this string in smali code

- What it does is compare our input (v4) with the string “devadmin” (v5) by calling
Java.lang.String.equals() method, if equal return 1, else 0
- Then the result is saved in v4
- The program call the condition if-eqz ( if equal zero ), so if the input is not “devadmin”, it goes to
:cond_11c
smali
- We look the code after if-eqz fail and the code at :cond_11c
Equals to “devadmin”

Not Equals to “dev-admin”

Code Looks the same J

smali
- Evaluate equal condition:

v2=new UrlEncodedFormEntity;
v2(v1 local_list) == new UrlEncodedFormEntity(v1)
v3.setEntity(v2)

HttpClient.execute(v3)

- The above code is equal to in java source

So what v3 is? Next-slide J

smali
v3=“/dev/login”
v1.append(v3) => v1.append(‘/dev/login’)

v3=new HttpPost

v1.toString()

Call HttpPost(v1)

- The above code is equal to in java source

- Basically, if we input “devadmin”, it will do POST request to http://mobile-server/devlogin which

allow us to free login J
smali
- So you may ask why should we have to read the smali code? Why won’t we
read the clear java source code instead?

The answer is, we have to detect it, to patch the program! (talk later)
Patching android app
- Now we will talk about how to patch an android app ( no smali in this talk, great J )
- A patch is a software update comprised code inserted (or patched) into the code of an executable
program.
- Remember apktool? We use it to decompile the apk first
apktool d InsecureBankv2.apk
Patching android app
- So we go to res folder to find something interesting (why? Because this folder contains resource, and
modify it is fun J)
- Quickly found this in InsecureBankv2/res/values/strings.xml

- If you want to be a good pentester, you must keep in your mind:

“If someone say no, punch him, and say yes instead J”
- So modify it to yes
-
Patching android app
- We go back to base folder

- And re-compile the application:

apktool b InsecureBankv2
Patching android app
- Note that the re-compile apk is located in “dist” folder, not the old apk in current folder.

- So install it?

- Oops, Failed! Its because Every new compiled Android .apk needs to be signed if it is going to be
installed on a phone
Patching android app
- We are going to sign it!
- Create key using:
keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000
Patching android app
- Sign using:
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore InsecureBankv2.apk alias_name
Patching android app
- We change its name to make it clearer compare to original apk:
mv InsecureBankv2.apk InsecureBankv2_patched.apk
- Then install

- Still fail? It means the application which you want to install is already installed. just remove the old one and try again.
Patching android app
- Open it again:

Good one, we got Create User

button! That’s admin module J
Detection
- “Life is not easy”, it’s true, at least in this lecture J
- The application can contain detection code, to prevent attacker analysis it, usually are:
1. Root Detection (or anti-root)
2. Emulator Detection (or anti-vm)
- Back to the app, we see this:

It got root detection

code, but the code fail,
so we are safe.
I’ll talk later J Emulator detected, we
are running this app on
galaxy s6 based on
genymotion right?
Detection -> Anti-emu
- So we come to Anti-emu bypass. We saw this alert on PostLogin section, so we check its code
- Or we can search it => Go to Bytecode Viewer, load the apk and search for “Emulator”

Search result!
Detection -> Anti-emu
- We found the code in com/android/insecurebankv2/PostLogin.class

- We can see the checkEmulatorStatus() call checkIfDeviceIsEmulator(), this function find the string
defined in FINGERPRINT, MODEL, MANUFACTURE, BRAND, DEVICE, etc… to detect, in our case:
“Genymotion”
- This time not easy patch like before, because this is code check, if we want to patch, we must modify
SMALI (yes, smali again J).
Detection -> Anti-emu
- So step one is to find the smali code match with anti-emu check in java code
- We already known the check is the function checkEmulatorStatus(), search for it J

- Note that variable name, condition name, etc… is different based on decompile tool.
Detection -> Anti-emu
- If you reverse the app, you don’t really need to understand all the work, you just find
what you need, and hack it J
- Some points:

- if-ne vx, vy, target == “Jumps to target if vx!=vy. vx and vy are integer values.”
- So the code above can be explained:
If v0 != v2, then go to :cond_13 (:cond_13 means the app is running on real device, not emulator), else
continue to “Emulator detect” part
Detection -> Anti-emu
- So we need to find out what v0, v2 is, and do blah, blah, blah, super power, zeronight, 0day xyz to
bypass it?.... Um no, there is a easier way
- Look at this:

If ... not equal … jump to cond_13 (right part)

- So what happens if we remove the “not equal” and force it always go to :cond_13?
=> The flow will always jump to :cond_13 J
- Let try it:
Detection -> Anti-emu
- With this idea, let change it in InsecureBankv2/smali/com/android/insecurebankv2/PostLogin.smali
- Then re-compile to get a new patched apk, sign it.
- Open & see the result J:
Detection -> Anti-root
- So why the anti-root code failed to detect us? We can see the code is here:

- It check if /system/app/Superuser.apk existed?

Yes => detected, else no.

Detection -> Anti-root
- To find out what is happened, we access to our device

- Then find it

That’s why we pass the check by default

- Basically, its located here J: