M9: Reverse Engineering

Threat Agents

Application 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.

Attack Vectors

Exploitability EASY

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.

Security Weakness

Prevalence COMMON
Detectability EASY

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.

Technical Impacts

Impact Moderate

An attacker may exploit reverse engineering to achieve any of the following:

  • Reveal information about back end servers;
  • Reveal cryptographic constants and ciphers;
  • Steal intellectual property;
  • Perform attacks against back end systems; or
  • Gain intelligence needed to perform subsequent code modification.

Business Impacts

Application / Business Specific

The business impacts from reverse engineering are quite varied. They include the following:

  • Intellectual Property theft;
  • Reputational Damage;
  • Identity Theft; or
  • Compromise of Backend Systems.

Am I Vulnerable To ‘Reverse Engineering’?

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:

  • Clearly understand the contents of a binary’s string table
  • Accurately perform cross-functional analysis
  • Derive a reasonably accurate recreation of the source code from the binary 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.

How Do I Prevent ‘Reverse Engineering’?

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:

  • Narrow down what methods / code segments to obfuscate;
  • Tune the degree of obfuscation to balance performance impact;
  • Withstand de-obfuscation from tools like IDA Pro and Hopper;
  • Obfuscate string tables as well as methods

Example Attack Scenarios

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.

References

“Adversaries have hacked 78 percent of the top 100 paid Android and iOS apps in 2013.”

“86 percent of applications tested lacked binary hardening, leaving applications vulnerable to information disclosure, buffer overflows and poor performance. To ensure security throughout the life cycle of the application, it is essential to build in the best security practices from conception.”

“Our results show that 86.0% of them (Android Malware) repackage legitimate apps to include malicious payloads; 36.7% contain platform-level exploits to escalate privilege; 93.0% exhibit the bot-like capability.”

“While Apple is known for screening apps before they are allowed to sprout up in its walled garden, clearly fake apps do get in. Once they do, getting them out depends on developers who raise a fuss.”

“It’s not uncommon to search the Google Play app store and find a number of knock-off or “fake” apps aiming to trick unsuspecting searchers into downloading them over the real thing.”

“The site offers apps for free that would otherwise cost money, including big-name titles.”

“For critical applications, such as transactional ones and sensitive enterprise applications, hardening should be used.”

  • [9] Gartner report: Emerging Technology Analysis: Mobile Application Shielding, March 26th, 2013:

“As more regulated and sensitive data applications move to mobile platforms the need to increase data protection increases. Mobile application shielding presents the opportunity to security providers to offer higher data protection standards to mobile platforms that exceed mobile OS security.”

  • [10] Gartner report: Proliferating Mobile Transaction Attack Vectors and What to Do About Them, March 1st, 2013:

“Use mobile application security testing services and self-defending application utilities to help prevent hacking attempts.”

  • [11] Gartner report: Select a Secure Mobile Wallet for Proximity, March 1st, 2013:

“Application hardening can fortify sensitive business code against hacking attempts, such as reverse engineering”

  • [12] Forrester paper: Choose The Right Mobile Development Solutions For Your Organization, May 6th 2013:

“5 Key Protections: Data Protection, App Compliance, App-Level Threat Defense, Security Policy Enforcement, App Integrity”

“In most cases, the 2,140 copycat developers that were found reassembled the apps almost identically, adding new advertising SDKs to siphon profits away from the original developers.

“But one of his more worrying findings came from disassembling the apps themselves … what he found was hardcoded development credentials within the code. An attacker could gain access to the development infrastructure of the bank and infest the application with malware causing a massive infection for all of the application’s users.”

“Number of mobile malware samples is growing at a rapid clip, increasing by 20-fold in 2013… It is trivial for an attacker to hijack a legitimate Android application, inject malware into it and redistribute it for consumption. There are now binder kits available that will allow an attacker to automatically inject malware into an existing application”

Watch Star