Closing the App Security Gap: Moving Beyond Basic Security Practices

When we talk with security professionals about application protection, we get a variety of feedback ranging from

“We have architected our systems with separation of concerns, we use secure coding practices, and we do SAST/DAST testing, so we’re good.”

to

“In spite of all the other protections we had in place, when we realized that modified versions of our mobile apps posed a threat to our back-end systems, we implemented new measures to mitigate that threat and to raise our overall security posture.”

If your sentiments are closer to the first statement, we’d like to point you to this article describing how apps—even securely developed and tested apps—can be weaponized to attack the very back-end systems that provide your greatest customer value. If you already think that applications need to be protected beyond those necessary good practices, please continue reading here.

There are a few main ways to protect applications against reverse engineering and tampering. In this article, we will consider protections that are applied after applications are built and otherwise ready to be submitted to the corresponding app store. The methods we’re considering here are wrappers, SDKs, and code injection. We’ll start with a quick introduction to a standard security framework against which we can measure the techniques.

OWASP MASVS Resilience Overview

The OWASP Mobile Application Security Verification Standard (MASVS) outlines four resilience categories that aim to fortify mobile applications against various security threats. These categories focus on ensuring that an application remains secure even when facing attacks. And while these categories are mobile-specific, they serve as a good framework for all apps that run on the internet on end-user devices. By adhering to these resilience guidelines, developers can create applications that are more resistant to reverse engineering and are better equipped to protect user data.

• MASVS-RESILIENCE-1: The app validates the integrity of the platform.
• MASVS-RESILIENCE-2: The app implements anti-tampering mechanisms.
• MASVS-RESILIENCE-3: The app implements anti-static analysis mechanisms.
• MASVS-RESILIENCE-4: The app implements anti-dynamic analysis techniques.

Now, let’s dive into the protection techniques.

Wrappers

Wrappers are a type of application protection that provide a single line of defense to applications. When applying a wrapper, one encodes the application, adds a corresponding decoding routine, and then runs the decoding routine before the original application. Since the code is being rewritten, this type of protection is only available on platforms where self-modifying code is allowed.

The benefit of this type of protection is that static analysis cannot be performed directly. Disassemblers, decompilers, and humans cannot understand the code underneath the wrapper because it has been converted to a meaningless sequence of bytes. Wrappers, then, fulfil the OWASP MASVS-RESILIENCE-3 control. However, the decoding routines that are triggered by the wrapper are themselves normal code, which can be disassembled, decompiled, and generally understood, and their very presence is a clue to threat actors that indicate that a wrapper has been used.

And even though static analysis cannot be performed on the application, threat actors only need to start (“run”) the application and wait for the original code to be restored. They can then copy and disassemble or decompile the original code. Such protections are thus easy for even novice threat actors to subvert.

So why do companies sell wrappers, and why do app creators use wrappers? Wrappers are very easy to implement and provide a hurdle against static analysis. Ease of implementation allows companies to get into the application protection market very quickly and cheaply. Those companies can then target customers who only need the barest skin of security for their apps.

The time it takes to protect an app is minimal, and there is usually nothing that needs to be configured. However, such protections are usually susceptible to BORE (Break Once Run Everywhere) attacks because all protections use the same decoding routine.

Some protection is better than no protection, but we can do better.

SDKs

As we work our way from least secure to more secure solutions, the next step in the application security progression is the protection SDK model. In this context, an SDK is an independent code module that contains protections against and detections for one or more threats. For example, a protection SDK could contain logic for ensuring platform integrity by detecting rooted or jailbroken devices and preventing dynamic analysis by detecting debuggers or analysis tools like Frida.

At build/protection time, a protection SDK is bound to the app being protected. Like the wrapper solution, the SDK inserts itself at the application’s entry point so that it can start one or more threads that perform the detections in the background. After that, the original code runs without interaction with the SDK.

Generally, no modifications are made to the original code at runtime—so variations of this solution can be used on any platform. But since the original code is not modified, it is susceptible to static analysis by disassemblers and decompilers, even though it may be resilient to dynamic analysis. The weakness in this case is that if the protection SDK can be removed, then the rest of the app can be run without the benefit of any protection mechanisms.

Since there is more logic involved, companies generally require more time and cost to develop protection products based on SDKs—but not as much as is required for code injection products. In this case, the protection step is also simple and usually requires no configuration.

SDKs thus satisfy MASVS-RESILIENCE-1, 2, and 4. However, like wrappers, protection SDKs also often suffer from susceptibility to BORE attacks. And while it is possible to bind the SDK to the app with extra mechanisms, that generally requires some application analysis, which makes the development of the product harder and introduces the possibility of binding errors.

Code Injection

Code injection security products are the pinnacle of this trio of techniques. Note that in both previous cases, the protection code runs at the very beginning of the app execution, which makes it easiest to find, analyze, and subvert.

The main idea in the code injection scenario is not just to wrap or add an SDK but to analyze the application to fully understand the control flow and then to add protection mechanisms throughout the application so that they run in the background while the protected app itself is running. The protection mechanisms can include platform integrity checks to prevent the code from running on jailbroken or rooted devices, anti-static analysis mechanisms like obfuscations, anti-dynamic analysis mechanisms to detect debuggers and dynamic instrumentation toolkits, and anti-tamper mechanisms to ensure that the running app is the same as the shipped app.

And since these techniques are scattered throughout the code, they are much harder to find, ensuring that threat actors must spend much more time and effort – often in vain – to try to defeat them.

Another benefit of this technique is that once the protection mechanisms are injected into the code, they can protect themselves repeatedly as deeply as one wants. By making a large enough network of protection mechanisms, app owners can significantly bolster the security of their apps by making a puzzle that is self-aware and that reacts with visible and invisible actions to thwart would-be threat actor puzzle solvers.

Also, because the protection code is scattered throughout the application, it is effectively hidden, which means that some detections can take stealthy, custom actions—if the security product allows it—so that subtle changes can be made to the behavior of the app that threat actors may completely miss, thus adding to their frustration and keeping them away from their goal.

Building threat actor frustration can drive them away from strongly protected applications and turn them to look for unprotected or more lightly protected applications. You don’t need to checkmate your adversary; you just need them to surrender and go elsewhere.

To complete the comparative analysis, code injection protection tools provide the most comprehensive protections, protections that resist static AND dynamic analysis, thus fulfilling all 4 of the MASVS Resilience requirements.

The Digital.ai Difference

Comparing these protection techniques makes one thing clear: no single method can provide complete protection. Building real application resilience takes coordinated defenses and automation across the entire software lifecycle. Digital.ai Application Security delivers that solution.

• One platform that automates release pipelines and integrates complex toolchains. Unify app delivery, integrate existing tools & scale across any environment.
• Automated mobile app testing and security designed to scale. Provide secure, high-quality apps through better automated testing & app protection techniques.
• Built-in AI, intelligence, compliance, and governance across all software delivery workflows. Centralize data, optimize processes, and gain augmented insights for faster, safer software delivery