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)

Agenda

• Background• Objective• Attack Tree• Mitigation• Demo of Reverse Engineering• Conclusion

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.

Objective

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

Attack Tree

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

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

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

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

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

Demo of Reverse Engineering

• App– Android app – iMilk Free

• Android Emulator– Genymotion

• Tool– Apktool

Steps Performed

• Dex file converted to smali file using apktoolCommand: apktool d iMilk\ Free.apk

• The icon of the iMilk was changed in the smali folder

• The app was rebuild again using apktoolCommand: apktool b iMilk\ Free

iMilk_modified.apk

Before AfterSteps Performed

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

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