Cyber security

Contact us

BOOK A PRESENTATION

Mobile App Hardening

Mobile application hardening strengthens your app’s code and binary, making it more resistant to reverse engineering, tampering, and static analysis. It raises the barrier against attackers trying to access your logic, extract sensitive data, or repackage your app.

What is mobile application hardening?

Mobile application hardening is a discipline within mobile application security focused on reducing the attack surface of an app’s code and binary. Its central purpose is to make it materially harder for an attacker to analyse, understand, or manipulate the application, regardless of whether they are working offline (static analysis) or in real time (dynamic analysis).

Key mobile application hardening techniques

Code obfuscation

Code obfuscation transforms an application’s source code into a form that is functionally identical but extremely difficult for a human or automated tool to read. It applies multiple transformations - renaming classes, methods, and variables to meaningless identifiers; inserting dead code that never executes; reordering instructions; and flattening control flow — each making it progressively harder to reverse-engineer the original logic.

Data obfuscation

Data obfuscation applies obfuscation specifically to the parts of code that store or process sensitive data: credentials, API keys, financial information, cryptographic material. Even if an attacker successfully extracts a database or memory dump, obfuscated data appears as a meaningless strings rather than readable values. 

Resource encryption

App components are are decrypted only at runtime when the application needs them, making them unreadable to an attacker who has extracted the binary but is not running the application. 

Anti-tampering and Integrity Check

Anti-tampering and integrity check mechanisms detect whether the application’s binary has been modified after it was originally signed and distributed. A cryptographic signature or hash is derived from the original build. At runtime, the application compares its current state against this stored value. Any modification, including code injection, binary patching, or repackaging, produces a mismatch that triggers the configured response. 

Anti-debugging

Anti-debugging techniques detect when a debugger has been attached to the application’s process and respond accordingly. This is typically done by terminating app execution, altering behaviour, or notifying. Developers use debuggers during development, while attackers use them during runtime to step through execution, inspect memory, and identify bypass opportunities. 
More on debugging and debugger detection

Auto-expiry

Auto-expiry automatically terminates the user’s session after a defined period of inactivity. While simpler than other hardening techniques, it is a recognised control in financial and healthcare application security standards, limiting the window of opportunity for session hijacking or physical access to an unattended device. 

Emulator detection

Emulator detection identifies when an application is running inside a software emulator rather than on a real physical device. Attackers use emulators because they are easier to instrument, snapshot, and automate than real devices. This is waht makes them a preferred environment for large-scale automated analysis, fraud, and testing of bypass techniques.

More on emulators and emulator detection.

Stand-alone keyboards

Keylogging attacks capture every keystroke made by the user, including passwords, PINs, and payment information, by intercepting input before it reaches the application. Implementing a stand-alone secure keyboard, or detecting the presence of third-party keyboard applications that may contain malicious code, prevents keyloggers from recording sensitive input. 

Certificate pinning

Certificate pinning embeds a specific TLS certificate, or its public key, directly into the application at build time. When the app establishes a connection, it verifies that the server’s certificate matches the pinned value rather than trusting any certificate signed by a recognised CA. This prevents an attacker who controls the network from substituting their own certificate to intercept encrypted traffic. 

Rooting and jailbreak detection

Rooting (Android) and jailbreaking (iOS) remove the operating system’s security restrictions, giving processes, including malicious ones, access to the device at a level the manufacturer did not intend. An app running on a rooted or jailbroken device cannot rely on OS-level security guarantees. Rooting/jailbreak detection checks for the presence of known root-granting binaries, modified system files, and abnormal process permissions, then restricts or terminates the app’s sensitive operations accordingly. 
More on jailbreak detection

How secure is your mobile application?

Understand and prevent reverse engineering. 
Watch Webinar

Types of mobile app attacks

In a static analysis attack, the attacker downloads and decompiles the application without running it. Working offline on their own machine, they examine the source code to understand its logic, identify security mechanisms, locate API keys or credentials, and find exploitable vulnerabilities. The goal is often reverse engineering, i.e., reconstructing enough of the original application to clone it, modify it, or derive its intellectual property.
 
Hardening techniques that address static analysis work by making the code difficult or impossible to read even if decompiled: obfuscating identifiers, encrypting strings, altering control flow, and removing metadata that would help the attacker orient themselves within the codebase.
In a dynamic analysis attack, the attacker runs the application, typically on a rooted or jailbroken device, or inside an emulator, and uses debuggers or hooking tools to observe its behaviour in real time. Rather than reading static code, they watch how the app responds to inputs, intercept method calls, and manipulate runtime values to bypass authentication checks or extract data in transit.
 
Hardening techniques that address dynamic analysis detect and respond to the attacker’s tooling: identifying debugger attachment, recognising instrumentation frameworks, detecting emulated environments, and responding to the presence of a jailbroken or rooted device.


Types of mobile application hardening:
 passive and active

Mobile application hardening techniques fall into two categories depending on when and how they operate:

Passive mobile
application hardening

Operates at build time. Transforms the application binary to resist static analysis attacks.

  • Makes source code difficult or impossible to read after decompilation
  • Introduces misleading or meaningless code to misdirect analysis
  • Encrypts sensitive strings, assets, and resources within the binary
  • Removes metadata that would help an attacker navigate the codebase
  • Does not change the application’s runtime behaviour or performance

Active mobile 
application hardening

Operates at runtime. Enables the application to detect and respond to dynamic analysis attacks.

  • Detects debugger attachment and halts or alters execution in response
  • Identifies rooted or jailbroken devices and restricts sensitive operations
  • Recognises emulator environments used for automated analysis
  • Detects hooking frameworks intercepting method calls
  • Responds automatically: terminating the session, alerting the owner, or returning false values
The two types are complementary. Passive hardening raises the cost of static reverse engineering; active hardening raises the cost of dynamic analysis. Relying on one without the other leaves an exploitable gap: an attacker who cannot read the decompiled code will simply run it instead.

Mobile application security toolkit

Learn about the current state of the mobile application security ecosystem, as well as present and evolving threats to mobile.
Download eBook

Mobile Application Hardening vs.
Mobile Application Shielding

Mobile application hardening and mobile application shielding are related but distinct disciplines that address different stages of the attack lifecycle. They are frequently confused, or used interchangeably, but serve different purposes and should be understood as complementary.

Mobile application hardening

  • Strengthens the app’s code and binary
  • Makes reverse engineering and static analysis significantly harder
  • Passive techniques: obfuscation, encryption, metadata removal
  • Active techniques: anti-debugging, emulator/root detection
  • Protection is embedded before the app is distributed

Mobile application shielding

  • Monitors and protects the app during execution
  • Detects and responds to active attacks in real time
  • RASP: runtime application self-protection
  • Integrity checking: detects tampered binaries at launch
  • Protection continues on-device throughout the user session

The two approaches are most effective when combined: hardening makes the application’s code difficult to analyse before an attack begins; shielding detects and responds to attacks that succeed in reaching the runtime environment. A determined attacker who can not read the decompiled code will attempt dynamic analysis, which is where runtime shielding provides coverage hardening alone cannot.

Mobile Application Hardening vs. Mobile Application Shielding

For a detailed breakdown of how hardening and shielding differ and when to use each, go to our blog.
Read more

Benefits of mobile application hardening

1.

Reverse engineering prevention

Without hardening, any attacker who can download your application can decompile it and read its logic. Code obfuscation, string encryption, and control flow manipulation make this process prohibitively difficult.
2.

Tampering and repackaging protection

Integrity checking and anti-tampering controls prevent attackers from modifying your application and redistributing it as a trojanised version. Repackaging attacks, where a legitimate app is cloned with malicious code inserted, are among the most common vectors targeting mobile banking applications
3.

Sensitive data protection

Data obfuscation and resource encryption protect credentials, API keys, financial data, and cryptographic material stored within the application binary. Even in the event of a partial breach, obfuscated and encrypted data is unreadable to the attacker without the means to reverse the transformation.
4.

Protection in zero-trust and BYOD environments

Enterprise applications deployed on employee-owned (BYOD) or unmanaged devices cannot rely on device-level security controls. Mobile application hardening ensures the application protects itself regardless of the security posture of the device it runs on.
5.

Brand and reputational protection

Anti-tampering methods, such as integrity checks, disable the attacker from manipulating the app anA successful reverse engineering or repackaging attack can result in cloned applications that steal user credentials, fraudulent versions distributed via unofficial stores, or public exposure of proprietary business logic. The reputational damage from any of these events is disproportionate to the cost of the hardening controls that would have prevented them.d extracting sensitive data.
6.

Brand and reputational protection

Several regulatory frameworks and industry standards explicitly address mobile application security controls:
PCI DSS v4.0 — Requirement 6.3 states that mobile payment-acceptance applications must be hardened to prevent unintended logical access or tampering.
PSD2 — requires that mobile banking and payment apps detect and respond to compromise, including on tampered or compromised devices.
OWASP MASVS — the Mobile Application Security Verification Standard defines resilience controls (MASVS-RESILIENCE) covering anti-tampering, anti-reverse-engineering, and device integrity checks.
DORA — the Digital Operational Resilience Act requires financial entities to protect the integrity of their digital services, including mobile applications.
7.

Financial data loss prevention

For mobile banking, payment, and fintech applications, data obfuscation and secure storage techniques mask financial data within the application binary and in memory. In the event that an attacker gains partial access, obfuscated financial data is rendered useless without the means to reverse the transformation.

Your app deserves more than just basic protection.

Take the first step with our free trial.
Start Free Trial

Mobile Application Hardening FAQ

1. What is mobile hardening?
Mobile application hardening is the process of strengthening a mobile application’s code and binary during development to make it significantly more resistant to reverse engineering, tampering, and analysis. It applies a combination of passive techniques (which operate at build time to make code difficult to read) and active techniques (which operate at runtime to detect and respond to attacker tooling). The goal is to increase the technical effort required for an attacker to understand or manipulate the application to the point where the attack becomes impractical.
2. What is the difference between passive and active mobile application hardening?
Passive hardening operates at build time and focuses on static analysis resistance: making the application’s code difficult to read after decompilation through obfuscation, encryption, and code transformation. Active hardening operates at runtime and focuses on dynamic analysis resistance: detecting the tools attackers use to observe and manipulate a running application (i.e., debuggers, emulators, hooking frameworks, and rooted devices), and responding to their presence automatically.
3. What are the main mobile application hardening techniques?
The core techniques are: code obfuscation (making source code unreadable after decompilation), data obfuscation (protecting sensitive data within the binary), resource encryption (encrypting strings, classes, and assets), anti-tampering and integrity checking (detecting binary modification), anti-debugging (detecting and responding to debugger attachment), emulator detection (identifying automated analysis environments), jailbreak and root detection (identifying compromised devices), certificate pinning (preventing man-in-the-middle attacks on encrypted traffic), stand-alone secure keyboards (preventing keylogging), and white-box cryptography (protecting cryptographic keys embedded in the application).
4. What is mobile application tampering?
Mobile application tampering is the act of modifying an application’s code or binary without authorisation. Attackers tamper with apps to bypass authentication checks, remove licence enforcement, inject malicious code, or repackage the app with additional capabilities. The tampered version may then be redistributed via unofficial app stores. Anti-tampering controls, particularly integrity checking, detect these modifications and prevent the altered application from running.
5. What is the difference between mobile application hardening and mobile application shielding?
Hardening strengthens the application at build time, before it is deployed. Shielding adds runtime defences that operate while the application is running on a device. Hardening makes static reverse engineering harder; shielding detects and responds to active attacks during execution. The two are complementary: hardening raises the cost of static analysis, and shielding covers the runtime attack surface that hardening cannot address. A complete mobile security strategy uses both.
6. Does mobile application hardening affect app performance?
Well-implemented hardening techniques are designed to have minimal performance impact. Passive techniques such as obfuscation and encryption operate at build time and add no runtime overhead. Active techniques such as emulator and root detection run as lightweight background checks and are not on the critical path of user-facing operations. Performance should be validated during integration, but for most applications the impact is negligible.
7. Which regulations require mobile application hardening?
PCI DSS v4.0 explicitly requires that mobile payment-acceptance applications be hardened to prevent tampering and unintended access. OWASP MASVS defines resilience controls (MASVS-RESILIENCE) that map directly to standard hardening techniques. PSD2 requires that mobile banking and payment applications detect and respond to compromise on tampered devices. DORA requires financial entities to protect the integrity of their mobile-delivered digital services. For EU-regulated industries in finance and critical infrastructure, hardening is an expected baseline control rather than an optional enhancement.
8. Is code obfuscation the same as mobile application hardening?
No. Code obfuscation is one technique within mobile application hardening, focused specifically on making source code difficult to read after decompilation. Mobile application hardening is a broader discipline that includes obfuscation alongside resource encryption, anti-tampering, anti-debugging, emulator detection, root/jailbreak detection, certificate pinning, and other controls. Relying on obfuscation alone provides partial protection against static analysis but offers no defence against dynamic analysis or tampering.
9. How is mobile application hardening implemented?
Mobile application hardening is typically implemented during the build phase, before the application is signed and distributed. Passive hardening transformations are applied to the compiled binary automatically as part of the build pipeline. Active hardening components, which need to execute at runtime, are integrated via an SDK or library that is included at build time. Neither passive nor active hardening requires changes to the application’s source code. For most implementations, integration is completed within a single development sprint.

Mobile security suite by ASEE

APP PROTECTOR

CyberSecurityhub

chevron-down linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram