Mobile Application Secure Architecture

Modern mobile operating systems are arguably more secure than traditional desktop operating systems, but problems still appear when security isn’t carefully considered during development. Some key areas in mobile application security that should be considered during development include local data storage, obfuscation, emulation detection, application integrity check, root detection, runtime integrity check, and debug detection. Let’s take a brief look at each one.

Local Data Storage

The protection of sensitive data, such as credentials and PHI data, is crucial to mobile security. The local database or data in the database used by the application should be encrypted at rest. Storage of the decryption key and access to it can be tightly controlled using KeyChain on iOS and KeyStore on Android.


Obfuscation is the process of transforming code and data to make it more difficult to comprehend. It is an integral part of the software protection scheme. Obfuscation is not something you can just turn off or on, but it can be used to make the application, or parts of it, harder to decipher to various degrees. Tools like Pro-Guard and R8 on Android can be used as part of the compilation process to rename variables, methods, and classes so it will be much harder to read and understand the application.

Emulator Detection / Device Binding

The goal of emulator detection or device binding is to increase the difficulty of running the application on an emulated device or transferring the application in its current state to a different device. This impedes some tools and techniques that reverse engineers like to use. In some use cases, the application is already bound to specific hardware and will not function without it. In other cases, binding can be achieved using specific device identifiers or by adding a device-specific key to the encryption chain of critical application data.

Application Integrity Check

Reverse engineers can try to decompile and patch the application to alter its behavior. An effective way to make this process more involved is to implement validation on the application's bytecode. The idea is to have additional controls in place so that the application only runs correctly in its unmodified state, even if the code signature is valid. In our workflow example (Figure 1), the compiled application tamper detection runs at the start of the application and will exit if any modifications in its bytecode are detected.

Root Detection

In the context of anti-reversing, the goal of root detection is to make running the application on a rooted device more difficult. This, in turn, blocks some of the tools and techniques reverse engineers like to use. There are libraries recommended by OWASP Mobile Security that can be used to detect a jailbroken/rooted device and then alert the user. In the example application workflow (Figure 1), the user will not be allowed to continue the use of the application when the device is detected to be rooted/jailbroken.

Figure 1: Workflow Diagram

Runtime Integrity Check

Controls in this category verify the integrity of the application’s memory space to defend against memory patches applied during runtime. These patches include unwanted changes to binary code, function pointer tables, and important data structures, as well as rogue code loaded into the process memory. In the example application workflow (Figure 1), the application executes the runtime tampering detection throughout its use and will exit if any tampering is detected.

Debug Detection

Debugging is a highly effective way to analyze runtime application behavior. It allows the reverse engineer to step through the code, stop application execution at arbitrary points, inspect the state of variables, read and modify memory, and a lot more. Various checks to detect a debug state can be implemented. In addition to not allowing debug states, the device can also be prohibited to run in developer mode. Blocking the developer mode might not always be appropriate, but it can be when the application comes preinstalled on a dedicated device. In the example application workflow (Figure 1), the user will not be allowed to continue the use of the application when any debug configuration or the developer mode is detected.

Example Application Workflow

All detection techniques and ways in which further use of the application is blocked are depicted in Figure 1. The compiled application tamper detection and root detection are run after the application starts, and if any anomalies are detected, the application either closes or shows a blocking alert. Both runtime tamper detection and debug/developer mode detection are run not only at the start, but throughout the use of the application.


It’s important to keep security in mind when developing mobile applications. This is especially true in the medical device space where there is a stronger need for parts of the technology and data to remain confidential. Some key topics to consider were discussed and should serve as a guide to building more secure mobile applications.


OWASP Mobile Application Security Testing Guide (MASTG), 2021, Bernhard Mueller, Sven Schleier, Jeroen Willemsen, Carlos Holguera.

Need help on this topic?
Contact Us
Joost Mulders

Joost is Director of Engineering at Promenade Software with a strong background in backend engineering, computer vision, and software/data architecture. He has worked extensively on (f)MRI data analysis software early on in his career and has now been in the medical device space for over 6 years. During this period he has worked as a tech lead, gaining expertise in all aspects of software development and providing valuable contributions to cross-functional decision making. In his management role at promenade software, Joost enjoys helping other engineers grow, as well as working on any technical challenges that come his way.

linkedin logo
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Promenade Software, Inc. specializes in software development for medical devices and other safety-critical applications.
Promenade is ISO 13485, and CypherMed Cloud is SOC2 Type II certified.