4 min read

General Concepts of Application Hardening for Mobile Banking Apps

General Concepts of Application Hardening for Mobile Banking Apps

Application hardening for mobile apps refers to implementing security measures to protect apps against reverse-engineering or tampering. In this article, we look at the importance of application hardening for mobile banking applications and explore some of the techniques that can be used to shield an app against such attacks.

The Need for Code and App Hardening

MASC Product sheet Banking apps are a prime target for hackers as they contain sensitive data and secrets that enable privileged access to financial operations.

Hacking an Android or iOS application can be relatively easy if the right measures are not in place to make it more resilient against reverse-engineering or tampering attacks. 

Using disassemblers and/or decompilers, attackers can access and understand how mobile banking & payment applications function, which makes it possible for a broad range of abuse. Attackers could potentially steal valuable code or clone mobile banking & payment applications.

They could also extract sensitive data such as API keys or user credentials.

The following sections describe some of the hardening techniques that should be implemented so that the hardened app becomes resistant to both passive and dynamic analysis.

Data Obfuscation

Data obfuscation (DO) is a way of hiding information, where data is scrambled following specific methods, to prevent an attacker from gaining knowledge from it. The result of obfuscation is confusing and unintelligible data.

Data obfuscation can be done either via encryption or tokenization. With tokenization, symbols are substituted to the initial data in such a way that an attacker cannot reconstruct the original data unless knowing the dictionary used for the substitution. 

Native Code Obfuscation

Code obfuscation will make it difficult, if not impossible, to understand and analyze source code. This results in mobile applications displaying only meaningless, obscure, or incomprehensible code to an attacker. While the program has been obfuscated, it is fully functional and cannot be distinguished from the non-obfuscated version.

Similar to data obfuscation, code obfuscation may involve encrypting some parts of or all the code. It would later be deciphered using a helper auxiliary process or be self-decrypted. Metadata, variables, and function names are also renamed into tokenized labels that are named generically such as ‘_A’,’_B’,’_C’, etc. The execution tree of the program can be scrambled into some sort of “spaghetti,” making it difficult to understand the function of the program.

Some typical examples of obfuscation techniques include the obfuscation of the control flow in such a way that the instruction blocks are ‘re-arranged” using a dispatcher. A good obfuscator will usually prune, rename, encrypt and tokenize as much data as possible from the original program. Obfuscators can also “fool” attackers by injecting wrong and dummy data in many ways.


A debugger is a program that can analyze other programs while it is running. A debugger could attach to the process of a mobile banking application and be used to reverse it or analyze the way it works. Usually, debuggers will do this by calling a debug API in the operating system (OS). They will also set some flag registers. To protect against this, an app should be able to detect and respond to the presence of a debugger.

The main technique used to perform anti-debugging involves using specific functions provided by the mobile OS to check the presence of a debugger. It’s also possible to detect specific files, processes and messages indicating the presence of an active debugger. Heuristic detection using a timing method is also possible.


Tampering the application consists of trying to enter the system, copying, and cloning the mobile application. Cloning the application enables an attacker to modify a legitimate banking/payment application and then attempt to re-distribute it so that it will perform fraudulent transactions.

Some mobile OSs may provide native frameworks to detect tampering and to check the identity and integrity of applications (for example Safetynet provided for Android). Additionally anti-tampering may search for an installed instrumentation framework and known debugging tools (such as the Frida instrumentation framework). Finally anti-tampering can use various ways to 'bind' the application to some cryptographic secrets and some identification values (PUF variables, identifiers provided by the hardware or cryptographic hashes). 

Emulator Detection

An attacker will want to run the mobile banking and payment application inside a controlled environment, so that the application can be analyzed and modified. This would usually be a virtual machine (VM) or an emulator. An app must be able to detect and respond accordingly (e.g. disable operations) if it is run on an emulator.

While emulators are supposed to mimic the original operating system, they do leave some artifacts (files, processes, etc.) that can be used to detect their presence.

The main methods for anti-emulators, anti-VMS, and anti-sandboxes are based on checking some CPU instructions, looking for artifacts (for example, known emulator MAC addresses), registry keys or processes. It is also possible, in some cases, to use other heuristic detection systems.

Root and Jailbreak Detection

For security reasons, mobile OSs are supposed to prevent the user from having administrative rights. A “rooted” or “jailbroken” device could be a sign that an attacker is attempting to lower the protections provided by the OS and the application. Thus, this must be prevented.

The main techniques to detect a rooted or jailbroken device involves detecting write access by the application to parts of the file system which should be normally protected. It is also possible to search for known values which are typical of rooted or jailbroken devices, this includes - but is not limited to - custom builds, specific files, specific processes or specific packages, which indicate the presence of a known rooting (or jailbroken) package.


There are numerous techniques available to harden banking and payment applications. Their use makes it difficult for an attacker to make attempts to reverse, analyze, tamper, and clone the applications because it is extremely costly in time, effort and resources.

App hardening techniques are critical components of building secure and resilient applications. Despite their importance, such techniques are supposed to complement, not replace, other defense mechanisms and security controls. It is critical that, in addition to the methods mentioned above, the app is able to respond appropriately to defend itself against the unwanted activity that application hardening can help detect.


Read White Paper

References and Further Reading

  • Read more articles about application security for mobile banking applications (2018 - today), by Martin Rupp, Stefan Hansen and more