|Join hundreds of other Developers and InfoSec professionals for Training, Sessions and Community at our first conference of 2019|
[AppSec Tel Aviv, May 26-30th]
Mobile Top 10 2016-M9-Reverse Engineering
|Threat Agents||Attack Vectors||Security Weakness||Technical Impacts||Business Impacts|
|Application Specific||Exploitability EASY||Prevalence COMMON||Detectability EASY||Impact MODERATE||Application / Business Specific|
|An attacker will typically download the targeted app from an app store and analyze it within their own local environment using a suite of different tools.||An attacker must perform an analysis of the final core binary to determine its original string table, source code, libraries, algorithms, and resources embedded within the app. Attackers will use relatively affordable and well-understood tools like IDA Pro, Hopper, otool, strings, and other binary inspection tools from within the attacker's environment.||Generally, all mobile code is susceptible to reverse engineering. Some apps are more susceptible than others. Code written in languages / frameworks that allow for dynamic introspection at runtime (Java, .NET, Objective C, Swift) are particularly at risk for reverse engineering. Detecting susceptibility to reverse engineering is fairly straight forward. First, decrypt the app store version of the app (if binary encryption is applied). Then, use the tools outlined in the "Attack Vectors" section of this document against the binary. Code will be susceptible if it is fairly easy to understand the app's controlflow path, string table, and any pseudocode/source-code generated by these tools.||An attacker may exploit reverse engineering to achieve any of the following:
||The business impacts from reverse engineering are quite varied. They include the following:
Generally, most applications are susceptible to reverse engineering due to the inherent nature of code. Most languages used to write apps today are rich in metadata that greatly aides a programmer in debugging the app. This same capability also grealy aides an attacker in understanding how the app works.
An app is said to be susceptible to reverse engineering if an attacker can do any of the following things:
Although most apps are susceptible to reverse engineering, it's important to examine the potential business impact of reverse engineering when considering whether or not to mitigate this risk. See the examples below for a small sampling of what can be done with reverse engineering on its own.
In order to prevent effective reverse engineering, you must use an obfuscation tool. There are many free and commercial grade obfuscators on the market. Conversely, there are many different deobfuscators on the market. To measure the effectiveness of whatever obfuscation tool you choose, try deobfuscating the code using tools like IDA Pro and Hopper.
A good obfuscator will have the following abilities:
Scenario #1: String Table Analysis:
The attacker runs 'strings' against the unencrypted app. As a result of the string table analysis, the attacker discovers a hardcoded connectivity string that contains authentication credentials to a backend database. The attacker uses those credentials to gain access to the database. The attacker steals a vast array of PII data about the app's users.
Scenario #2: Cross-Functional Analysis:
The attacker uses IDA Pro against an unencrypted app. As a result of the string table analysis combined with functioanl cross-referencing, the attacker discovers Jailbreak detection code. The attacker uses this knowledge in a subequent code-modification attack to disable jailbreak detection within the mobile app. The attacker then deploys a version of the app that exploits method swizzling to steal customer information.
Scenario #3: Source Code Analysis:
Consider a banking Android application. The APK file can be easily extracted using 7zip/Winrar/WinZip/Gunzip. Once extracted, the attacker has manifest file, assets, resources and most importantly classes.dex file.
Then using Dex to Jar converter, an attacker can easily convert it to jar file. In next step, Java Decompiler (like JDgui) will provide you the code.
 Arxan Research: State of Security in the App Economy, Volume 2, November 2013:
 HP Research: HP Research Reveals Nine out of 10 Mobile Applications Vulnerable to Attack, 18 November 2013:
 North Carolina State University: Dissecting Android Malware: Characterization and Evolution, 7 September 2011:
 Tech Hive: Apple Pulls Ripoff Apps from its Walled GardenFeb 4th, 2012:
 Tech Crunch: Developer Spams Google Play With RipOffs of Well-Known Apps… Again, January 2 2014:
 Extreme Tech: Chinese App Store Offers Pirated iOS Apps Without the Need To Jailbreak, April 19 2013:
 OWASP: Architectural Principles That Prevent Code Modification or Reverse Engineering, January 11th 2014.
 Gartner report: Avoiding Mobile App Development Security Pitfalls, 24 May 2013:
 Gartner report: Emerging Technology Analysis: Mobile Application Shielding, March 26th, 2013:
 Gartner report: Proliferating Mobile Transaction Attack Vectors and What to Do About Them, March 1st, 2013:
 Gartner report: Select a Secure Mobile Wallet for Proximity, March 1st, 2013:
 Forrester paper: Choose The Right Mobile Development Solutions For Your Organization, May 6th 2013:
 Publisher Unannounced: Android Hacker's Handbook, To Be Published April 2014.
 Software Development Times: More than 5,000 apps in the Google Play Store are copied APKs, or 'thief-ware', November 20 2013:
 InfoSecurity Magazine: Two Thirds of Personal Banking Apps Found Full of Vulnerabilities, January 3 2014:
 InfoSecurity Magazine: Mobile Malware Infects Millions; LTE Spurs Growth, January 29 2014: