Three Important Tips To Help You Select App Shielding for Your Mobile Banking App

Where demand is, supply shortly follows. Many smaller mobile app protection solutions emerged, resulting in a market that is not very comprehensive. How could it be? At first glance, all the products look the same. The list of value propositions is very similar, and — yes — very often copied from various sources across the web. After all, websites and PowerPoint slides can absorb anything.

To help you ask the right questions during the App Shielding vendor evaluation, we prepared several useful and important, yet not clearly apparent tips.

App Shielding is For The App Security, Not For App Audits

Before we elaborate on the features you should look for, we would like to ask you this:

Why do you consider investing in the App Shielding? Is it because you want to tick green checkmarks in your annual security audit report, or because you want to do this AND stop attackers threatening your app users?

If you are in the first category and your motivation is just formal, read no further. You can probably pick any solution that works for you from the cost perspective, create an information fog around the auditor, and pass with flying colors despite providing weak protection from actual cyber threats.

If, on the other hand, you are in the second category who deploys App Shielding to actually stop the attackers, you probably understand that the technology must work under extreme conditions. The mobile device is already heavily compromised, and with a proactive malicious actor in place, who attacks your banking app on purpose. As a result, the App Shielding solution must itself use hacks at the very edge of iOS and Android platform capabilities. These advanced approaches are often related to the way mobile OS works on a very low level. App Shielding development is an ongoing, research-heavy activity, and the technology must be updated with each major mobile OS version.

Now, we can move to the specific features to look for…

Tip 1: Low-Level Implementation In a Native Module Is a Must-Have

Mobile programming languages compile into fragile high-level executables. The code that is written in Swift on iOS is compiled into a somehow hardened executable bundle. However, the Objective-C code that results in dynamic dispatch after compilation, or the Java or Kotlin code on Android that compile into bytecode / .dex, can be easily decompiled into a source code that is not very hard to read. Code obfuscation provides a partial remedy. But for a trained hacker’s eye, obfuscation represents just a minor inconvenience. It is not only analysis “at rest” that is problematic, but also dynamic analysis “in runtime” (examining a running app). Code written in a high-level mobile programming language results in an executable that is weak from a memory management and runtime resilience perspective.

This is why the best App Shielding solutions use an implementation in the native core written in C/C++ to achieve absolute control over the memory management, and provide higher resilience against runtime tampering, better resistance against reverse engineering, and — as a side-effect — better performance (with advanced App Shielding, speed also matters).

Recommendation: Select vendors who implement RASP in C/C++ and bundle the solution as a native library (*.a, *.so) present in the shielded app.

Tip 2: Automated App Bundle Processing and No Code Delivery

In case the App Shielding solution pitch stats with “Integrate with just a couple lines of code,” you should probably stop listening. In case you need to integrate an SDK and launch it manually, you have already lost the battle. The protection happens too late in the mobile application lifecycle.

Opposite to that, by automatically modifying the app bundle either during build time (as a compilation step) or after it (modifying existing *.ipa or *.apk files), you gain the advantage of changing the actual app bundle. This allows hooking into the narrow time slot during which an app is loading, for example, while the Zygote process fork occurs. This means that the protection is active before the attacker can perform any malicious activity that would draw your app protection pointless.

Of course, many advanced App Shielding solutions have an optional SDK as an add-on that allows a bit more fine-grained handling of some particular cases and security-sensitive situations. However, the automated implementation is still at their core.

As a positive side-effect, you will get a more streamlined delivery as a part of your DevSecOps principles, by simply plugging the App Shielding in your CI/CD pipeline.

Recommendation: We suggest preferring vendors who allow implementing App Shielding through automation rather than programming, connecting App Shielding to the build process or CI/CD pipeline.

Tip 3: Excludes Some Mobile App Users in Well-Defined Scenarios

A vendor who promises no users will be excluded from using the app after App Shielding deployment is probably doing App Shielding wrong. Such a promise is usually caused by the lack of in-depth knowledge, especially in the most critical areas that cover security corner cases. Assuming a device is heavily modified, there is nothing any app protection can do besides terminating the mobile app, hence excluding some app users.

We learned that about 5 in 100k app users have their mobile device modified so heavily that no security measures can be guaranteed to work. Usually, this is a combination of device jailbreak/rooting and other hacks, such as installed hacker tooling (Frida, Cydia Substrate) with active injection scripts.

Recommendation: Instead of selecting a vendor who promises zero impact on the end users, you should seek a vendor who clearly defines scenarios under which the app is terminated and can estimate and manage the expected impact on your users.