Skip to the main content.

The Future of Mobile Application Security

 

Static And Runtime Application Protection: How MASC Deploys A Future Proof Mechanism In Protecting Mobile Applications

 

DOWNLOAD YOUR COPY

INTRODUCTION

In “Protecting Mobile Apps in the Age of AI and Quantum Computing”, we saw that modern reverse engineers aided by AI can eventually unravel any purely obfuscated code – “ultimately, the reverse engineer always wins” as OWASP notes. Rapid advances in decompilation and AI de-obfuscation mean that relying on code obfuscation alone is increasingly dangerous. We concluded that a defense-in-depth approach is needed: combining strong cryptographic protection (so that code is encrypted and completely opaque without a key) with active runtime defenses (to thwart attacks during execution).

In this whitepaper, we examine Cryptomathic’s approach to full app protection and how its Mobile Application Security Core (MASC) implements this layered security. We will highlight how MASC uses mobile app encryption (to protect the app at rest), an advanced Confpacker tool (to safeguard secrets and configuration), and unique Runtime Application Self-Protection (RASP) technology (to detect and react to attacks in real time). The result is a comprehensive mobile app security solution that addresses both static and dynamic threats, positioning MASC as one of the most robust offerings in the market for protecting sensitive mobile apps.

 

future of mob apps picture 1

 

CRYPTOMATHIC MASC FULL-APP PROTECTION

 

Cryptomathic’s Mobile Application Security Core (MASC) is an in-app security solution with back-end assurance server designed to turn a mobile application into a “self-defending fortress”. Unlike traditional approaches that rely only on build-time obfuscation or external wrappers, MASC provides in-depth protection throughout the app ’s lifecycle. It combines multiple layers of security including core security features with white box crypto, asset and secret protection for secure in-app processing and external communication with build-time encryption of the app (so that the delivered binary is safe at rest) and runtime self-protection (so that the app can detect and foil attacks as it runs). MASC’s key components include as shown in the image:

Future of mobile apps 2

 

Full App Encryption (Code Hardening): The core code of the mobile app (e.g., Android bytecode) is encrypted before distribution, preventing static reverse-engineering of the app ’s logic.

Asset & Data Encryption (Asset Protection): Sensitive resource files or data packaged with the app are also encrypted, so that an attacker cannot extract secrets or intellectual property from the app bundle.

Confpacker Secure Configuration: All secret keys, credentials, and configuration values are stored in an encrypted form and integrated via an advanced configuration packer (“confpacker ”) at build time. This ensures that no secrets are exposed in the code or files – even the code that handles these secrets is obfuscated and camouflaged.

Runtime Application Self-Protection (RASP): At runtime, MASC continuously monitors the app’s environment and behavior for signs of tampering or reverse engineering (e.g., debugger attachment, code injection, rooted device, malware hooks). If a threat is detected, MASC can actively respond in real time – for example by shutting down or disabling functionality – to thwart the attack immediately, before any compromise occurs.

Secure Communication & Device Binding: MASC also provides secure networking (TLS pinning, encryption of API payloads, etc.) and device binding through an optional server-side Assurance Service. This ensures that backend servers can cryptographically verify that API requests come from an untampered, legitimate app instance. These features complement full app protection by extending security to client-server interactions and preventing API abuse.

By combining these layers, Cryptomathic’s approach mitigates the full spectrum of mobile app threats: from static code analysis to dynamic runtime attacks to network-level interceptions. Below, we dive into each layer of protection, and then summarize the overall value proposition for developers and security evaluators.

 

cloud

BUILD-TIME: HARDEN THE CODE & ENCRYPT ASSETS

Encrypted resources hinders the static analysis attempts.

launch

APP LAUNCH: SECURE INITIALIZATION

Decrypt the protected code and proceed with execution safely.

rasp pic

RUNTIME: REAL-TIME THREAT DEFENSE

Strongest RASP functionality detects threats and responds instantly.

BUILD-TIME APP ENCRYPTION: PROTECTING THE CODE ITSELF

 

One of the most distinctive features of Cryptomathic’s approach is full app-layer encryption – effectively locking down the application’s own code with cryptography. Traditional code obfuscation tries to make the app’s logic hard to understand, but an attacker with time or tools can eventually decode it. In contrast, encrypting the code means that without the correct decryption key, the code is completely unintelligible.

This is a fundamentally stronger protection: modern ciphers like AES are unbroken – no amount of AI or computing power can “magically” decrypt AES ciphertext without the key. By encrypting the app’s code, Cryptomathic ensures that if an adversary obtains the APK/IPA file, they cannot retrieve the app ’s sensitive logic or algorithms through static analysis.

How it works (Android focus)

Cryptomathic’s build tool (Confpacker) processes the compiled app and moves them into encrypted form within the app package. Instead of shipping human-readable or easily disassemble bytecode, these parts of the app are replaced with encrypted blobs.

When the app starts on the user’s device, Core performs an environment check (If a hostile environment is detected at this stage, the loader can decide to abort execution, preventing the real code from ever being decrypted in an unsafe setting) followed by performance optimized decryption for dynamic code loading execution (without ever writing the decrypted bytes to the file system).

Once loaded, the app’s code runs as normal without performance impairment, often observed when pure obfuscation is used.

How it works (iOS focus)

Apps from the AppStore are already encrypted by Apple and are decrypted by iOS as part of the loading process. Additionally, creating custom packing/unpacking for iOS ecosystem is not a sustainable and long-term solution. For that purpose, we provide a combination of Asset Protection (covered in the next section) and Reverse Engineering prevention technique, which when paired with RASP functionality, provides a holistic protection to the overall code base.

The impact of this approach is dramatic in terms of security: if an attacker attempts to disassemble the app file (e.g., using tools like ApkTool or JADX), they will find none of the actual application code. Essentially, static reverse-engineering is thwarted: without spending extraordinary effort to defeat the encryption at runtime, the attacker learns nothing of the app’s internals.

Security vs. Attackers: Encrypting the app code raises the bar significantly for attackers. To get at the code, an attacker would have to somehow extract it at runtime – MASC anticipates this by coupling with RASP, it can detect common hooking frameworks or suspicious instrumentation and terminate before finishing decryption. In practice, an attacker would need advanced skills and likely zero-day exploits to bypass all of these measures and extract any useful code.

Performance considerations: Cryptomathic’s solution was designed such that the encryption and loading process does not degrade the user experience. Tests have shown that this has no noticeable performance impairment on modern devices. Thus, developers get the security benefits without sacrificing app launch speed or functionality.

In summary, app-layer encryption ensures that the app’s critical code stays secret until the moment it’s needed. This addresses the core problem identified in Part 1 – that static attackers always win given time – by denying them any static target to attack. Next, we look at how Cryptomathic extends a similar protection to the app ’s other sensitive components, like assets and data.

PROTECTING ASSETS AND SENSITIVE DATA IN THE APP

Untitled (450 x 200 px)

image 5-1

 

Securing the code is paramount, but many apps also carry sensitive assets and data that need protection. These could be things like proprietary machine learning models, configuration files with secret parameters, license files, third party binaries, or even the JavaScript bundle in a React Native app. If left unprotected, such assets could be extracted from the app package by an attacker, revealing secrets or giving insight into the app’s logic. Cryptomathic’s approach to full app protection includes strong asset encryption to compliment code encryption.

MASC can be configured to encrypt specified files within the app (both Android APK and iOS bundle).


At build time, any file that matches the developer's criteria (for example, anything in an “assets/secure/” folder, or specific file names) is replaced with an encrypted version specific to the device. From the developer’s perspective, using an encrypted asset is nearly as simple as using a normal asset – just one API call to get the data. The decrypted content can then be used directly and Asset Encryption works on both platforms transparently.

 

 

image 10

 

As a rule of thumb, not every asset needs encryption and of which the ones are encrypted, it is sound to not decrypt at startup or altogether. MASC decrypts assets only when needed. This avoids unnecessary overhead. By decrypting on-demand, MASC is both more efficient and more secure.

Protecting confidential data and user data is also paramount to ensure that the app will not leak sensitive data and facilitates GDPR or other privacy law enforcement. The above describes protecting assets that are shipped with the app. MASC also includes a Secure Storage feature for data generated or stored on the device (like user credentials, tokens, or personal data the app saves). Under the hood, it uses strong encryption tied to the device hardware and additional obfuscation, ensuring that even if the device is compromised, stolen local data remains encrypted and bound to that device. MASC covers data at rest both pre-distribution (assets, code) and post-installation (runtime storage).

By encrypting both application code and assets, Cryptomathic’s solution can ensure that virtually nothing of value or secrecy in the static app package is human-readable or directly exploitable. The final piece of the puzzle is how to handle the keys and secrets that make this encryption possible – that’s where MASC Confpacker and secret management come in.

MASC CONFPACKER AND SECRET PROTECTION: SECURING THE KEYS TO THE KINGDOM 

 

Encrypting code and data raises an obvious question: where are the keys and how are they protected? If the encryption keys were simply hard-coded in the app, an attacker could potentially find them (especially if they know where to look), defeating the purpose. Cryptomathic addresses this with a sophisticated build-time tool called Confpacker (Configuration Packer), which not only performs the encryption steps described above, but also manages secret values in a highly secure manner.

Confpacker essentially produces a hardened configuration that ships with the app. This includes amongst other private configuration values– e.g., API keys, credentials, license information, trusted certificate pins, backend hostnames etc. All of this is encrypted and integrity-protected within the configuration.

In essence, Confpacker acts as a secure vault and blueprint for the app ’s protected world, so that developers can focus on the business logic and user experience. Having covered the static protections – code, assets, and config – we now turn to the dynamic protections MASC provides during runtime.

RUNTIME APPLICATION SELF-PROTECTION (RASP): DETECT AND REACT

 

Even with code and data encryption, once the app is running, it must decrypt and use that sensitive code and data. In that state (in-memory execution), a determined attacker with the right tools could attempt to manipulate or inspect the app.

This is where Runtime Application Self-Protection (RASP) comes into play. MASC’s RASP capabilities allow the app to continuously watch for signs of interference or abuse and take action on the spot.

Examples of runtime threats include:

  • An attacker attaching a debugger or instrumentation framework (like Frida) to the app to step through code or alter it on the fly.
  • The app running on a rooted or jailbroken device, where malicious apps or the user have escalated privileges to snoop on or modify other apps.
  • Injection of a hooking library (such as Xposed on Android) that can modify the app ’s behavior or bypass security checks.
  • Use of an emulator or a virtual environment to run the app in an attempt to bypass device-specific checks.
  • Malicious abuse of accessibility services or screen overlay on Android to capture sensitive information (some malware uses these techniques to capture screen content or user inputs).
  • Network manipulation like proxies or MITM tools trying to intercept and alter the app ’s communications (even if the channel is encrypted, a rooted device could have custom certificates installed, etc.).

 

 

 
 
 

MASC is built to detect many of these conditions via its sentinels (sensors) embedded in the app. These hundreds of detection points (“sentinels”) cover a wide range of threat indicators. For instance:

Root/Jailbreak Detection: MASC checks for signs of root access as well as root cloakers. It also detects if system security measures are bypassed through a combination of different techniques.

Debugger/Emulator Detection: MASC can sense if the code is running under a debugger or in an emulator.

Integrity Checks: MASC verifies that the app’s code and libraries haven ’t been modified.

Hooking Framework Detection: MASC looks for loaded libraries and can detect when critical functions are replaced or when unexpected system calls are made.

Screen Security: It can detect if the screen is being shared or if an overlay is present (essential to deliver What You See Is What You Sign) characteristic.

Fake Inputs: MASC monitors for synthetic touch events or other anomalies that suggest an automated tool is controlling the app.

Suspicious environment: MASC can detect unusual network proxies (traffic being diverted indicating potential MITM), or if untrusted accessibility services.

All these detections are done within the app’s process, in real time. They feed into a decision engine that can trigger responses immediately.

Cryptomathic’s system allows for a range of reactions configured by policy:

image 9

Block or Abort: For a serious threat (like active tampering), MASC can block the sensitive operation or even terminate the app on the spot (crash it). For example, if it detects a hooking attempt on the code that handles decryption, it could stop the app to prevent the attacker from proceeding.

Soft Fail (Restrict): Alternatively, the app might continue running but in a restricted mode. For instance, if the device is rooted, the app might decide to disable certain high-risk features (like mobile payments) while still allowing read-only access.

Report and Continue: MASC can simply log the incident. The incident report can trigger a security review or user notification from the backend.

User Warning: In some cases, the app might show a warning or require additional user authentication. For instance, if screen sharing is detected, the app could suspend sensitive transactions and warn the user.

Cryptomathic provides a Reaction Policy Engine (which can be tailored to an organization ’s risk appetite. Out-of-the-box, Cryptomathic supplies recommended reactions for certain categories (e.g., definitely rooted = block service; emulator = block; new untrusted accessibility service = maybe just report). These policies can be refined over time and even updated remotely through the Assurance console.

The key point is that the app defends itself in real time. This fulfills the “self-protecting ” promise of MASC.

Even if an attacker bypassed the static defenses and is now poking at a running instance, the app actively makes their life hard:

  • If they attach a debugger, the app might self-destruct with an error.
  • If they try to change code on the fly, the app notices and reacts.
  • Even if they run the app in a compromised environment, they can ’t easily get it to perform privileged actions or reveal secrets – MASC will sense the environment isn ’t trustworthy.

RASP in action: For example, imagine an attacker uses a tool like Frida to hook the function that checks the device’s root status, hoping to force it to always return “not rooted”. MASC might detect the mere presence of Frida’s server in memory or the action of modifying that function (through integrity checks), and immediately kill the app or trip a fatal error. The attacker ends up with nothing because the app won ’t run normally under those conditions.

Another scenario: A user unknowingly has malware on a rooted phone that uses an accessibility service to capture screen data. MASC can detect that an unauthorized accessibility service is active and continuously reading screen content. The policy might decide to crash the app whenever a sensitive screen is displayed with such a service active, or simply not show the sensitive content until the user disables the suspicious service.

From the developer’s perspective, much of this is handled by MASC internally. However, the developer can also query MASC’s status via APIs (e.g., ask “is the device compromised?” before allowing an in-app transaction) and can define custom actions. The developer or security team sets up the desired policies, and MASC’s built-in reactions will enforce them consistently.

Importantly, RASP provides telemetry that is extremely useful to security teams. Each detection can be logged (without sensitive user data, just the fact and type of threat) either locally or to a server. Over time, this gives insight into how many users are encountering threats and can guide security decisions or incident response.

Combining RASP with the earlier layers, we now have a full picture: MASC first protects the app’s code and data from exposure, and then it protects the running app from interference. This one-two punch significantly reduces both the likelihood and impact of an attack.

WHY MASC STANDS OUT: COMPREHENSIVE SECURITY AND VALUE PROPOSITION

Now that we’ve detailed the components of Cryptomathic’s MASC solution – code encryption, asset encryption, confpacker, and RASP – it’s important to highlight the overall value proposition of this approach, especially compared to other mobile app protection methods on the market. MASC’s multilayered strategy makes it one of the most comprehensive mobile app security offerings available. Here’s why:

CONCLUSION

 

Modern mobile apps that handle sensitive data or transactions face increasingly sophisticated threats – from automated deobfuscation by AI, to real-time tampering by malware and malicious users. In Part 1, we established that solely relying on obscurity is not sufficient; robust encryption and active defenses are needed. Cryptomathic’s MASC exemplifies this philosophy by delivering a multi-layered shield around mobile applications. It brings together the power of encryption (to lock down code and data) with intelligent runtime self-protection (to watch for intruders and react on the fly), all packaged in a developer-friendly SDK.

For mobile app developers and security teams, adopting MASC means gaining peace of mind that the app can defend itself both when at rest and in motion. It means drastically reducing the risk of a catastrophic breach of your mobile channel, which in turn protects your end-users and your organization ’s reputation and assets. From a compliance perspective, it means ticking off security requirements with confidence, knowing that an expert-tested solution has you covered. And from a technical perspective, it means using state-of-the-art cryptography and RASP techniques without having to build them from scratch.

In the competitive landscape of mobile app security providers, MASC’s comprehensive approach — covering everything from code to network, from build-time to runtime — sets it apart as a gold standard, encryption-based security solution. It is the embodiment of “defense in depth” for mobile apps, allowing organizations to embrace mobile innovation (even as they handle critical data on user devices) without leaving the door open to attackers. By integrating MASC, developers can ensure their apps are not only functional and user-friendly, but also resilient against the toughest of attackers; and risk managers can confidently attest that appropriate measures are in place to safeguard against fraud, privacy concern and abuse in the mobile channel.

In summary, Cryptomathic’s approach to full app protection with MASC demonstrates how to encrypt and actively shield a mobile app and it’s assets in unison. It turns the app itself into an active participant in its own defense, effectively neutralizing many of the advances that have given attackers the upper hand. As the threat landscape continues to evolve – with AI and new exploits – such layered security architectures will be increasingly vital. MASC offers a proven, comprehensive way to implement that architecture today, making it a compelling choice for organizations that truly cannot afford to compromise on mobile app security.

cryptomathic_symbol_red_negative_transparent