OWASP polled the industry for the risk in mobile application and came up with the top ten mobile risks. https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks As our assignment, we developed an attack tree for the tenth risk (Lack of Binary Protection) where we did the reverse engineering of the mobile app and stole the code using free available tools like apktool.

1. Wee Kim Wee School Of Communication and Information
Lack of Binary Protection
Loo Chia Feng (G1301352L)
Paudel Sunil (G1400834A)
Rachman Abdul (G1400808F)
Wang Bo (G1301325H)

2. Agenda
• Background
• Objective
• Attack Tree
• Mitigation
• Demo of Reverse Engineering
• Conclusion

3. Background
• Increasing from 7 to 108 billion mobile devices
used by consumers from 2014 to 2017.
• “App Economy” are the most successful at
deepening customer engagement and driving
new revenues in this changing world. (Arxan
Research, 2014)
• Opportunities for attackers as mobile software
applications exposed to binary risks.
• Prevent hacking attacks on code binaries requires
new security practices, binary protections.

4. Objective
• To build the attack tree
• To mitigate the risk of binary theft
• To provide the demo of reverse engineering

5. Attack Tree

6. Mitigation
• Reverse Engineering
– Remove the unused program symbols
(Tools used: ProGuard)
– Change the easy to understand program symbols
to irrelevant names
– Encrypt the part/whole of the application when
not in use and when stored in disk
– Use checksum to see if any code has been
modified
– Use of special logic to sense the use of debuggers

7. Mitigation
• 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

8. Mitigation
• Presentation Layer Modification using
JavaScript
– Use of checksum
• Compare the checksum of the files at build time with
that at the run time
• Perform additional checksum to check the original
checksum is not tampered
• Make sure that both the checksums don’t have unique
binary signature

9. Mitigation
• Cryptographic Key Replacement
– Use dynamic keys all the time
– If the hardcoded key has to be used, then
• Damage the static key after use
• Repair the key just before it is required
• Before the use of the repaired key, perform checksum
to check if the key has been tampered
• After the use, destroy the key again

10. Mitigation
• Method Swizzling
 Avoid using the swizzling whenever possible as these are the exploit areas
 Use the checksum to find out if the code has been tampered
• Rogue Application
 Use of checksum to find out if the code has been tampered
 Avoid using swizzling whenever possible
• Security Control Bypass
 Use the checksum before the application executes this code
 Use another checksum to check if the original checksum is tampered

11. Demo of Reverse Engineering
• App
– Android app – iMilk Free
• Android Emulator
– Genymotion
• Tool
– Apktool

12. Steps Performed
• Dex file converted to smali file using apktool
Command: apktool d iMilk Free.apk
• The icon of the iMilk was changed in the smali
folder
• The app was rebuild again using apktool
Command: apktool b iMilk Free
iMilk_modified.apk

13. Steps Performed
Before After

14. Conclusion
• All software is made up of machine-readable code
• Attacker can locate potential software code
vulnerabilities
• Apply reverse engineering to search for patterns in
the code to perform hidden functionalities
• To endeavor alteration, use of an attack tree
conceptual diagram to break down the security of
systems and subsystems
• Each subsystem is mitigated to explain on the
necessary counter-measures

15. 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.
• IBM. (2014). Securing Mobile Applications in the Wild with Application
Hardening and Run-Time Protection. 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