Mobile App Resiliency: Reverse Engineering tools & techniques

Recently, we completed a thorough study on the protections of 120 mobile apps in Europe, from different countries. For this, we referred to the OWASP Mobile Security Testing Guide (MSTG) and selected tests from OWASP L2 + R(esiliency), the recommendation for banking apps.

The resiliency tests are concerned with a mobile app’s ability to defend against reverse engineering and tampering the mobile app at runtime. In detail, we analysed an app, among others, for root detection and code tampering detection using our automated Mobile Application Security Testing Tool: esChecker. ⬅️

The somehow staggering result is that only 16% of all 120 banking apps triggered a protection mechanism. 83% of the apps don’t implement any root detection mechanism which means that they do not react against any of the 14 automated tests we launched. (Read our latest article about how none of the Top 120 Banking Apps complies with OWASP recommendations.)

This raised the question: “Why?”.

One possible explanation is the assumption that lack of anti-root protection does not cause a vulnerability. Like with other resiliency protections, the “only” purpose of the root-detection is to increase the app's resilience against reverse engineering and specific client-side attacks on the mobile app.

Another explanation we are thinking of is that it is not well understood how Reverse Engineering techniques in general could impact mobile apps, what the real threats are and what attackers actually do when “playing” with a mobile app.

So let us shed some light into the resiliency of a mobile app and how it is related to reverse engineering.

Definition of “Resiliency”

The concept of resiliency in the context of mobile apps may not be very clear or obvious. Merriam-Webster defines resiliency as “an ability to recover from or adjust easily to adversity or change". For mobile apps, we can consider the resiliency as the ability of a mobile app to deal with the adversities caused by an attacker.

OWASP establishes the important link between mobile app resiliency and reverse engineering:

“Traditional secure coding techniques [...] are completely irrelevant to preventing reverse-engineering and tampering attacks. Even if an organisation produces ‘perfect’ code that employs secure coding techniques at all times, the organisation cannot apply these same techniques to prevent an adversary from applying reverse engineering techniques on an application that physically resides within the adversary’s phone. The compiled mobile application code, no matter how unreadable to human eyes, is reversible and modifiable by an adversary using many easily accessible reverse engineering tools.”

In other words: secure coding of a mobile app and absence of vulnerabilities alone are not able to protect mobile apps and its data. Resilient mobile apps have to add a protection layer and defend against attacks like reverse engineering and tampering.

Why should we worry about a rooted device?

We would like to start with a short recap of what a rooted device means. Wikipedia offers some good explanation:

“Rooting is the process of allowing users of the Android mobile operating system to attain privileged control (known as root access) over various Android subsystems. As Android is based on a modified version of the Linux kernel, rooting an Android device gives similar access to administrative (superuser) permissions as on Linux or any other Unix-like operating system such as FreeBSD or macOS.”

Having root access or running a mobile app on a rooted device actually removes all core security functions of the Android platform, such as isolation of mobile apps, provision of secure communication channels, and many others.

As we have seen, gaining full control over their devices may be a desirable objective for a few mobile device users. However, taking full control over a device is one of the main objectives for malware and attackers, as being a “root” user grants the attacker full and unlimited access to all information and components on the device.

Because a mobile app cannot distinguish between a legitimate friendly “root” user and an adversarial “root” user on the device, almost every app should check if a device is rooted or not. If the result is positive, then it is reasonable to assume the mobile device as compromised and consider the platform as untrustworthy.

This clearly shifts the responsibility for detecting a rooted device to the mobile app or, to put it correctly, to the mobile app developer. It can be only his duty to manage the risks of running on a rooted device.

Basically, there are various options available how to respond to detection of a rooted device:

• Keep calm and carry on, i.e. do nothing: this is a very reasonable (non-)reaction, e.g. if the app does not contain or process any critical assets. This is basically the same as if the app has no root detection at all.
• Modification of mobile app features at runtime, i.e. some (non-critical) functions of the mobile app continue to be available, others are disabled;
• Sending a (non-visible) message to the backend system so that decisions about mobile app functionalities take place in the backend. Example: a backend system continues to process a low value transaction on a rooted device because it is considered as a low risk transaction, while a high-value transaction is blocked because of assumption of high risk.
• Informing/warning the user, i.e. the decision to continue or stop the mobile app is passed over to the user:
• Stopping/crashing: the mobile app stops operations and crashes as soon as it detects that the underlying platform is a rooted device.

The mobile app response shall be determined by the issuer after careful analysis: he should perform a comprehensive risk analysis and consider the assets available in the mobile app (e.g. PIN, login, password, account or card numbers, cryptographic keys), the attacker and threats, the users, the potential impact of an attack and its likelihood.

Note that in our mobile banking app white paper, we launched the root tests during the authentication step, i.e. at login and password entry. Bear in mind that if the mobile detects a rooted device then this may be a strong indicator to a successful attack, since only few people actually root their device deliberately. Then an attacker has taken full control of the device which has become a dangerous place to be (from app perspective).

To better understand why root detection is an important but not sufficient protection, we look at two other “weapons ”used by attackers.

Reverse Engineering and Tampering

Even if these two terms are often used interchangeably, we prefer to stay with the definition of the OWASP Mobile App Security Testing Guide (MSTG):

“Reverse engineering a mobile app is the process of analysing the compiled app to extract information about its source code. The goal of reverse engineering is comprehending the code. Tampering is the process of changing a mobile app (either the compiled app or the running process) or its environment to affect its behaviour.”

Let us have a look at a simplified example to better see what that means in practice: let us assume that a mobile app has a protection to detect and respond to a rooted device. Since this anti-root functionality adds some complications to the attacker, they decide to disable this function. He analyzes the mobile app and changes the app's behaviour using reverse engineering tools so that the app does not either detect the rooted device or respond to the detection. In essence, the attacker disables the anti-root functionality so that he can run the mobile app with a (disabled) root detection on a rooted device and gains full access and control.

One of the most popular reverse engineering tools is Frida that helps reverse engineers in both phases, during the analysis (identification) and for modification of the code or the data (exploitation).

Even more, Frida not only allow to modify (“instrument”) the code of a mobile app running on an attacker’s phone, it can be also be used to execute scripts and change the app at runtime on the attacker’s target = user’s phone, e.g. to extract a cryptographic key out of the memory of a user’s mobile app and copy them to the attacker’s device. And: Frida does not require root access to the attacked mobile phone.

All this is not an easy job, but neither is it rocket science. Today, powerful tools like frida and alike (e.g. Ghidra, Cydia Substrate, Xposed, angr) are publicly available and open-sourced to researchers, security testers, mobile app developers, and, of course, attackers. Additionally, user communities have grown significantly and knowledge about reverse engineering and tampering techniques has become commonplace and grows daily.

As we have seen in the introduction, it is impossible to finally defend against reverse engineering and tampering. This is very much in line with the statement of the great philosopher Jean-Jacques Rousseau who said back in the 18th century: “Everything made by man may be destroyed by man”.

The battle already lost and over, then?

Not completely, because there are good and bad ways to implement the mobile app protections. Protection mechanisms shall not be simply available or implemented, they must be difficult to deactivate or circumvent to be effective protections.

The developer may consider protection mechanisms to improve mobile app’s resiliency like anti-instrumentation, anti-hooking, root detection, anti-emulation, anti-debugging, obfuscation, device binding, white-box cryptography and tamper detection.

It is of key importance for a mobile app developer to:

• Identify the mobile app assets and determine what is at risk;
• Understand how attackers work and what the threats are;
• Educate and train developers not to focus on secure programming only;
• Analyse the potential impact of an successful attack to a mobile app;
• Implement the desired protections and last, but not least;
• Assess the resiliency of your mobile app and jump in the shoes of an attacker by performing a mobile app penetration test.

What Rousseau did not look at is the question of how easy or difficult it is to get around all protections. With proper implementation of all state-of -the-art protections, attackers (and experts) will start sweating and experience pains, and it may take many weeks to defeat a well-protected mobile app. So it is important to understand and take care of the attacker’s “business case”: mobile app security (and IT security) is all about raising the bar and making an attacker’s life as complicated as needed so that he finally turns away and gives up.

In our whitepaper, we assume that lack of awareness about the latest attack techniques and powerful tools available on one hand, and the lack of mobile app compromises have a significant impact on the perception of the real risk.

In 1736, one of the founding fathers of the US, the famous Benjamin Franklin, advised Philadelphians threatened by fire: “An ounce of prevention is worth a pound of cure.”

We fully agree with him and recommend making mobile app developers aware of the real threats of reverse engineering.

To conclude with some good news: there are so-called runtime application security protection (RASP) tools available that help developers to enhance the resiliency of a mobile app. Like any other tool, they are hardly a silver bullet, but they can be a great aid to keep adversaries off your mobile app and your or your customer’s data.