This paper proves that the mobile app's binary code is at risk. Anyone can retrieve the binary source code using the free tool like apktool. In the paper, the authors have come up with an attack tree to steal the binary code of the android mobile app doing the reverse engineering and have given the mitigation as well. The paper also has a demo where the authors have exposed the binary codes using the tool named apktool. Just for an educational purpose, the authors changed the icon of the mobile app, rebuild it using their own private key and installed it back in the android phone.

1. Lack of Binary Protections
Loo Chia Feng G1301352L
Sunil Paudel G1400834A
Abdul Rachman G1400808F
Wang Bo G1301325H

2. Table of Contents
Introduction ....................................................................................................................................... 3
Attack Tree ......................................................................................................................................... 3
Directly steal original code: .............................................................................................................. 5
Analyze and reverse engineer a compiled mobile application code downloaded from store................. 5
Code modification/injection............................................................................................................. 6
Cryptographic key replacement .................................................................................................... 6
Method swizzling ......................................................................................................................... 6
Rogue application ........................................................................................................................ 6
Presentation layer modification using JavaScript............................................................................ 6
Mitigation........................................................................................................................................... 7
Reverse Engineering ........................................................................................................................ 7
Cryptographic key Replacement ....................................................................................................... 7
Method Swizzling: ........................................................................................................................... 7
Rogue Application ........................................................................................................................... 8
Presentation Layer modification using JavaScript .............................................................................. 8
Demo of Reverse Engineering .............................................................................................................. 8
Conclusion ........................................................................................................................................ 10
Bibliography ..................................................................................................................................... 11

3. Introduction
We live in a mobile powered world, where nearly 7 billion mobile devices are expected to be in use by
the end of 2014 and 108 billion mobile downloads are anticipated by 2017. Businesses that are most
efficiently adapting to today’s “App Economy” are the most successful at deepening customer
engagement and driving new revenues in this changing world. (Arxan Research, 2014)
However, where business opportunities abound, opportunities for attackers abound as well. Unlike web
applications, mobile software is uniquely exposed to binary risks, since application must be released to
public. Attackers can directly download the application and access, compromise, and exploit binary
code. For example, analyze or reverse-engineer sensitive code, modify code to change application
behavior, or inject malicious code.
Traditional application security practices are alone no longer sufficient to protect mobile assets from
new binary vulnerabilities, since even “flawless code” can be reversed, modified, repackaged and
distributed. (Arxan Research, 2013) To prevent hacking attacks on code binaries requires new security
practices, binary protections.
This document will define the possible hacking attacks on the code binaries and develop mitigating
strategies to deal with the possible attack scenarios.
Attack Tree
Attack trees provide a formal, methodical way of describing the security of systems, based on varying
attacks. Basically, you represent attacks against a system in a tree structure, with the goal as the root
node and different ways of achieving that goal as leaf nodes. (Schneier, Schneier on Security, 1999)
An attack tree (Schneier, Attack trees, 1999) is constructed by following:
 Define the goal of the attack.
 Check all the possibilities to achieve that goal.
 Break down the possibilities in the tree diagram hierarchically.
 Specify the possibilities of the path that can be followed.
The main objective of our attack tree as shown in Figure 1 is to show attackers attempting alteration and
obtaining of binary code. The three different possible approaches are:
 Directly steal original code
 Analyze and reverse engineer a mobile app downloaded from store or backup to SD card using
APKoptic or Astro File Manager
 Code modification/injection

4. Figure 1: Attack tree of binary theft protection

5. Directly steal original code:
It can be achieved through bribery, threatening/blackmailing or hacking into the source code versioning
server.
Analyze and reverse engineer a mobile app downloaded from store or backup
to SD card using APKoptic or Astro File Manager
It can be achieved by reverse engineering using various tools which can be downloaded from the
internet free of cost. The below are the steps that can be followed for reverse engineering:
1. Install the application in the device
2. Bypass the jailbreak or root detection
The developer who develops the app like mobile banking may not want his app to run in jail
broken or rooted devices. They might have special logic embedded in the app to detect if the
device is jail broken/rooted or not. This logic has to be bypassed if we want to do reverse
engineering by the use of tools such as xCon. (IBM, 2014)
3. Reverse engineering
o For IOS:
 If we feed the mobile app into Reverse Engineering Tool, an error is thrown
saying: "The file is encrypted. The disassembly of it will likely be useless. Do you
want to continue?"
So first of all we have to bypass this security of apple and decrypt the content.
The same can be achieved by using the tool clutch. (IBM, 2014)
Clutch takes the decrypted snapshot from memory and writes it to the disk.
Once we get that snapshot, we can feed into the tool (IDA PRO) and we can get
the decrypted code.
o For Android:
The android app can be reverse engineered in two different ways:
 Disassembling
Transform binary Dalvik byte code (Dex) into smali (assembly code) source code
using the tool such as apktool.
 Decompile
 Dex  Jar  Java (Tools used: Dex2jar, JDGUI)
 Dex  Java (Tools used : Androguard)
4. After getting the source code, we can modify the codes for our own benefits such as:
o Redirect original code methods to call other malicious code
o Modify the GUI layer
o Replace cryptographic key
o Change the security control flows
5. Then recompile the code back and sign the application

6. Code modification/injection
Cryptographic key replacement
Applications use cryptographic key to encrypt/decrypt sensitive data. Attackers may replace the
cryptographic key in order to decrypt and steal the sensitive data. Attackers may perform dataflow
analysis of an application in order to identify a particular key in use.
Method swizzling
Method swizzling is a technique to replace or extend methods in classes that you don’t own. The
attacker can take an advantage of this method to call his malicious code.
Rogue application
Rogue application is a malicious application which shares the same execution environment and memory
resources as a target application. By the use of rogue application, the binary code of the target app can
be modified.
Presentation layer modification using JavaScript
Presentation layer can be modified using the JavaScript to inject the malicious code and modify the
binary code.

7. Mitigation
(Carter) Review the risks to integrity and confidentiality of mobile apps from binary-level attacks and
suggest few solutions to code modification and injections via the various methods below.
Reverse Engineering
The below steps can be incorporated to prevent the app from reverse engineering:
 Remove unused program symbols (which usually convey sensitive information) from the
application binaries.
 Use the tool like ProGuard which shrinks, optimizes, and obfuscates the code by removing
unused code and renaming classes, fields, and methods with semantically obscure names. The
result is the smaller sized .apk which is difficult to do reverse engineering.
 Change the easy to understand program symbol names to irrelevant names.
 Encrypt the part or whole of the application when not in use and when stored in disk. Also
encrypt the data within the application.
 Use some special logic that can sense the use of debuggers and take appropriate action.
 Use checksum to see if any cod has been tampered.
Jail Break/Root Detection
 Detect the existence of Cydia; Cydia is an IOS app required to install app in jail broken devices
 Detect the existence of the path /private/var/stash
 This is the folder created on jail broken devices
 Detect non-sandboxed behavior
Cryptographic key Replacement
 Use dynamic keys all the time. Otherwise, the application's complier will store hardcoded keys in
their raw form within the final binary. An attacker will be able to find any such key looking at the
associated method calls.
 If in case hardcoded key is to be used, then
o Damage the static key
o Repair the key just before the key is required
o While using the repaired key, perform the checksum to check that the key is not
tampered
o After the use of the key, destroy it again
Method Swizzling:
 If the application is intentionally performing the swizzle, an adversary will exploit this design
decision and swizzle this particular method as it will be a reliable entry point into the application.
Avoid using the swizzling method.
 Use of special logic that can identify the change in the code and that can take appropriate action.

8. Rogue Application
 Use of checksum to find out if the code has been tampered
 Avoid using swizzling whenever possible
Presentation Layer modification using JavaScript
 Perform the checksum. Compare the checksum of the files at build time to the values found at
runtime.
 Perform additional checksum to check if the first checksum has been tampered.
 Make sure that both the checksums don't have a unique binary signature.
Demo of Reverse Engineering
Using the apktool, we decompiled the android apk file into snail files. For the testing purpose, we
changed the icon of the android app (iMilk) and recompiled back.
Steps:
1. Install the original apk in virtual android device
 Command: adb install iMilk Free.apk
2. Transform the binary Dalvik byte code to smali file (it converts the apk file into the folder)
 Command: apktool d iMilk Free.apk
3. Modify the codes
4. Rebuild the smali file back to apk
 Command: apktool b iMilk Free iMilk_modified.apk
5. Generate the private key using keytool
 Command: keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg
RSA -keysize 2048 -validity 10000
This example prompts you for passwords for the keystore and key, and to provide the
Distinguished Name fields for your key. It then generates the keystore as a file called my-release-
key.keystore. The keystore contains a single key, valid for 10000 days. The alias is a name
that you will use later when signing your app.
6. Sign your app with your private key using jarsigner:
 Command: jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.
keystore iMilk_modified.apk alias_name
Reverse
Engineering.mp4

10. Conclusion
In conclusion, all software is made up of machine-readable code. In fact, code is what makes every
program function the way it does. The code defines the software and the decisions it will make. Attacker
can locate potential software code vulnerabilities and apply reverse engineering to search for patterns in
the code to perform hidden functionalities.
To build the binary theft protection, we examine on the conceivable methodologies for an attacker to
endeavor alteration to the binary code by utilizing a within profundity examination of an attack tree
conceptual diagram to break down the security of systems and subsystems. Furthermore, each
subsystem is mitigated to explain on the necessary counter-measures.

11. Bibliography
Arxan Research. (2013). State of Security in the App Economy. Arxan Research.
Arxan Research. (2014). Securing Mobile Applications in the Wild with Application Hardening and Run-
Time Protection. Arxan Research.
Carter, J. (n.d.). Threats to Mobile Apps in the Wild. Arxan.
Schneier, B. (1999). Attack trees. Dr. Dobb’s journal, 21-29.
Schneier, B. (1999). Schneier on Security. Retrieved September 23, 2014, from Schneier on Security:
Attack Tree: https://www.schneier.com/paper-attacktrees-ddj-ft.html