Security Features

Certain features of Mobile Application Shielding require deeper integration inside the application, or changes to the build.

Phases of an application to be enabled:

• Callbacks

• Activity Guard

Root detection

Rooting is the process of circumventing security measures of the operating system. This is usually performed by the device user to customize the device beyond of what the manufacturer allows.

Attackers can 'root' a device to bypass the Android application sandbox. This can grant attackers access to data that is stored on the device, which would otherwise be restricted. Similarly, malware can exploit known weaknesses within Android to gain elevated permissions on a device while it is running.

Since a rooted device has a higher risk of being compromised, it is important to know about this. Even if the application can be configured to allow execution on rooted devices, detecting whether the device is rooted or not is essential for further security measures.

Root detection can be performed in several ways, such as checking for well-known indicators of root files, processes, and other anomalies. Root detection is inherently a "cat-and-mouse" game between new rooting techniques and rooting detection methods.

App Shielding implements several layers and levels of root detection mechanisms to handle most well-known approaches as well as more heuristics type indicators that are looking for symptoms of a rooted device rather than conclusive evidence. Newer versions of Android restrict the ability to detect certain types of rooting due to a stricter app security sandbox being enforced on the detection mechanism itself.

Repackaging detection

Repackaging has become a common practice on Android in recent years and means that an attacker can obtain a copy of the application, add malicious functionality, and then offer it to users who presume that they are using the original application.

This type of attack is made possible since there are many alternative distribution platforms in addition to the official Google Play Store. The act of repackaging the application can also be used when attempting to reverse-engineer an application.

App Shielding offers the possibility to detect and react when an application has been repackaged. Furthermore, App Shielding creates a strong binding between the app and App Shielding. With this, the security features provided by App Shielding cannot be bypassed easily.

Code injection protection

To gain control of an application, attackers may inject code into the application to control it from within its own process. This can, for example, be used to read encrypted SSL communication or intercept user input such as passwords.

This type of threat is more common on rooted devices since injecting code into another application would otherwise have been prevented by the operating system sandbox.

App Shielding can detect the presence of code hooks, as well as typical code injection frameworks such as Xposed or Cydia Substrate. In most cases it can also block injection of code into the process.

Debugger protection

During application runtime, debuggers can be used to extract sensitive information, perform code injection, alter the program flow, and help attackers to reverse-engineer the application. By actively blocking debuggers, App Shielding can prevent them from attaching themselves to the application.

This is implemented by launching a trusted guard process that will act as the App Shielding-specific debugger. App Shielding supports advanced debugger protection by executing a security handshake with the guard process. If the guard component has been circumvented by an attacker, this feature can block further usage of third-party debuggers.

Emulator detection

Emulators can be used to analyze an application to determine how it works and to extract sensitive information that is available while the application is being executed. App Shielding can detect that the application is being executed in an emulator or typical virtual environment.

For more information about exiting the app and displaying a web page, see Exit URL Launching.

Block emulated input

Non-physical inputs (motion events) are known as emulated input. Emulated input might originate from the Android Debug Bridge (ADB), autoclick applications, screen-mirroring applications, screen reader applications, etc.

If you enable this feature, you can block emulated inputs from being injected to the screen. When enabled, App Shielding performs a security check to determine if the input is emulated or physical, and blocks input originating from all sources except physical input. The type of input can be touch and/or swipe events.

You can also define an emulated input threshold. App Shielding assigns a score value for each input to determine if the input might be emulated. Input scores above this threshold will be considered as emulated inputs.

For information how to configure this feature, see OneSpan Customer Portal.

Keylogger protection

Android offers its users the possibility to install custom software keyboards. These keyboards naturally track every input information the user makes, thus allowing an attacker to obtain this information and using these keyboards as keyloggers.

App Shielding allows to configure a list of trusted software keyboards to determine if the used software keyboard is trustworthy or not.

Screenshot protection

Applications often display sensitive information that should not be easy to exfiltrate from the application. One easy way to extract information from an application is in the form of a screenshot.

App Shielding can be configured to block screenshots, so the screenshot appears as a black rectangle with no information leaked. As of Android 15, the App Shielding screenshot blocking feature also protects against partial screen sharing. For more information about this, refer to the Android Developers article.

It is also possible to exclude an activity from screenshot protection with the Shielding Tool rule Allow screenshots for activity. For more information about this, see the descriptions for the Block screenshots option in Block screenshots.

Screen mirroring protection

Another way to export screen data from the application is through screen mirroring, which may be used in different ways, such as casting the screen to ChromeCast, MiraCast or a similar type of vendor-specific mechanism.

App Shielding can detect and block such screen mirroring by displaying a customized screen or a black screen on the mirrored display.

A customized screen can be used to inform users regarding your security objectives. Such layouts can and should be implemented as a layout by the application developer. For more information about integrating the customized screen feature, see App Shielding screen mirroring.

Screen reader protection

Screen readers use Android Accessibility APIs to interact with the application. These APIs were created to provide accessibility aids, such as text-to-speech and other types of accessibility tools,

Malware can also be installed and activated as a screen reader, meaning that it can potentially interactively and remotely control the device and application.

App Shielding can detect if any untrusted screen reader is active, and actively block it from receiving app data. Trusted screen readers may be allowlisted, ensuring the accessibility functionality is retained for specific screen readers.

Since version 3.3.7, App Shielding protects applications from a malware called eventBot. This malware asks for several permissions that allow it to access the user's messages or read screen content. Shielded applications are protected from malware reading the screen content, however the malware can still read the user's messages, collect device specification data and information about installed applications, or read external storage. For this reason, OneSpan recommends not using external storages (such as a memory card) to keep application-sensitive data directly in the application.

Private Space and Work Profile detection

Android devices can be set up to have Work Profiles (i.e., managed profiles), where the available functionality is controlled by an IT admin. Android 15 also introduced Private Spaces that allow users to create their own similarly controlled environments.

However, an app that is launched in a Private Space or Work Profile cannot query details about the keyboard and/or screen reader in use on the device. Thus, App Shielding does not trust any keyboard or screen reader when running in these environments, because they could potentially be malware and cannot be verified otherwise. If App Shielding is configured to block screen readers (i.e., using the Block untrusted screenreaders option), and the app is running in a Private Space or Work Profile, all text-to-speech access to the app is blocked.

App Shielding can detect if the protected app was launched in a Private Space or Work Profile and can be configured to exit the app (using the Exit on Private Space option) if you do not want to support these environments.

Tapjacking protection

Tapjacking is an attack vector where a user is tricked into selecting a security-relevant control from an overlay that obscured the intended button. See the Developer documentation for more details.

To prevent tapjacking, App Shielding can be configured to block all inputs to the application when a non-system overlay is detected on the screen. For Android 12 and later , this configuration also blocks and removes non-system overlays when the protected app is running. However, if your app uses a legitimate overlay window, we recommend keeping this configuration option disabled and implement the event blocking yourself to allow for exceptions.

If you use the blockTapjacking feature, and your app targets Android 12 (API level 31) or later, your app will need permission to hide overlay windows.

Android Developer Bridge status

Certain apps require that the Android Developer Bridge (ADB) is not active. App Shielding can detect the if ADB is active on the device.

Developer Mode status detection

Although it is not a security risk from an application perspective, app publishers may need/want to know whether a device has Developer Mode enabled. App Shielding can detect if a device has Developer Mode enabled.

Detecting apps from untrusted sources

Although it is not a security risk from an application perspective, app publishers may need/want to know whether a device has apps installed from third-party app stores, or sources other than the main app store for the device.

App Shielding can detect whether apps are installed on a device from sources that are not included in the allowlist.

Binding

The main purpose of binding is to intrinsically bind together the app and App Shielding, so that the app will depend on App Shielding being present to function normally.

The binding process modifies classes. This modification consists in extracting values and constants from the application code, and then rewriting them so that these values will be invalid in the application without App Shielding. When the app is launched, App Shielding will only initialize these values correctly or provide them for the app, if the security policy is satisfied.

This approach makes it extremely difficult for an attacker to attempt to remove App Shielding from the app, because without it, the app will be missing key pieces of information.

All extracted values are encrypted and stored in the application’s APK in the assets/file_name.dat file, where file_name is a random name.

The variables used in a class initializer are excluded from binding.

Two types of binding mechanisms are used:

• Push binding. Values are extracted and removed from the app. After App Shielding has been initialized, these values will be injected (pushed) into the relevant static class variables (fields). The app code is rewritten to fetch this value from the static class field.

• Pull binding. Values are also extracted and removed from the app, but the app code has been modified to fetch the values by calling a native method provided by App Shielding. The SDK will only return this value if the security policy is met. All extracted values are encrypted and stored in the application’s APK file.

  Push binding can impact the performance of the application at startup. You can switch on Disable push binding to optimize the app's startup performance.

Special considerations

There are several considerations that need to be taken into account when extracting the constants that will be used for binding.

• Performance. The number of bindings that have been extracted affects both startup and runtime performance. Adding push bindings increases the startup time to load the application, while adding pull bindings increases the runtime of algorithms that need to call a method to retrieve a value rather than using a local variable.

• Distribution. Constants should be distributed evenly in the application, so that pull bindings are called regularly during code execution. This enables App Shielding to perform runtime checks during the lifetime of the application execution, rather than only performing checks at startup.

Task hijacking protection

An essential element of Android is multitasking between applications.

A task is essentially the back-stack of activities, and it is closely related to the Recents screen (also known as the Overview screen or recent apps).

On Android, activities from different apps are allowed to reside in the same task, such as opening a link from your email app, which will open a browser in the same task. When pressing the back button, the user will return back to their email application view.

These tasks have an internal ID that is referred to as taskAffinity. This is a string value which is by default set to the same as the app PackageName.

Malware can set the taskAffinity of an activity to the PackageName of a target app and, by doing so, can hijack tasks belonging to the target app. In practice, this means that the user may click the target app icon in the launcher, but instead of seeing the target app’s activity, malware activity is shown. Apps can define several distinct activities with distinct taskAffinity values which allows malware to target a wide suite of applications.

App Shielding can detect and block such hijacking attempts.For more information about implementing this feature, see Activity Guard.

Obfuscation

Attackers will commonly try to reverse-engineer an application to identify weaknesses, secrets, or other sensitive information. App Shielding can obfuscate an application's Java code, either in part or in whole, making it much more difficult for an attacker to analyze the code. By default, only the App Shielding namespace will be obfuscated, but it can be enabled for the entire application.

Obfuscation is not the primary function of App Shielding, but an effective complementary feature to make it more difficult for an attacker to analyze the application. From an efficacy point of view, App Shielding will perform comparably to other commercially available obfuscation tools, and better than ProGuard (which is included with the official Android SDK).

For more information, see App obfuscation.

Jailbreak detection

Jailbreaking is the process of circumventing security measures of the operating system. This is usually performed by the users of a device to customize the device beyond what the manufacturer allows.

However, attackers can also jailbreak a stolen device by bypassing the device's protection mechanisms to gain access to the data stored on the device. Similarly, some of the available jailbreak techniques can be used by malware to gain extended permissions on a device.

Since a jailbroken device has a higher risk of being compromised, it is important to know about it. Even if the vendor of an application chooses to allow execution on jailbroken devices, detecting whether the device is jailbroken or not is essential for further security measures to determine the threats to which an application may be exposed.

Jailbreak detection can be performed in several ways. Simplistic approaches only test for the existence of files in the file-system that are associated with a jailbroken device. However, the existence of several 'jailbreak hider' tools that are available on iOS shows how easy it is to bypass these detection tools. Jailbreak detection is inherently a "cat-and-mouse" game between new jailbreak techniques and jailbreak detection methods.

App Shielding, while also implementing these simplistic detection mechanisms performs detection on multiple levels ranging from these well-known approaches to cutting edge low-level mechanisms that are targeted more towards detecting the essence of a jailbreak.

Emulator detection

Emulators can be used to analyze an application to determine how it works and to extract sensitive information that is available while the application is being executed. App Shielding can detect that the application is being executed in an emulator or typical virtual environment.

Repackaging detection

Repackaging means that an attacker can obtain a copy of an application, add malicious functionality such as a keylogger, and then offer it to users who believe that they are using the original application.

This type of attack is made possible since Apple has an alternative distribution mechanism apart from the App Store called enterprise distribution.

The act of repackaging the application can also be used when attempting to reverse-engineer an application.

App Shielding offers the possibility to detect and react when an application has been repackaged. Furthermore, App Shielding creates a strong binding between the app and App Shielding. With this, the security features provided by App Shielding cannot be disabled by simply removing App Shielding from the app.

Code injection protection

To gain control of an application, attackers may inject code into the application to control it from within its own process. This can, for example, be used to read encrypted SSL communication or intercept user input such as passwords.

This type of threat is more common on jailbroken devices, as injecting code into another application would otherwise have been prevented by the operating system sandbox.

On iOS, there are two known ways to inject code into an application: either during load time (which is done by tools like MobileSubstrate) or during runtime (which is done by tools like Cycript).

Load-time injection is only prevented if the app is being shielded. This is because the feature will otherwise cause problems when running the app during development.

Hooking framework detection

In the rare case that the code injection protection can be bypassed by an attacker, App Shielding is also able to detect actions that the attacker performs inside the process (usually in form of a hooking framework).

Debugger protection

During application runtime, debuggers can be used to extract sensitive information, perform code injection, alter the program flow, and help attackers to reverse-engineer the application. By actively blocking debuggers, App Shielding can prevent them from attaching themselves to the application.

Keylogger protection

Most keyloggers on iOS are implemented using code injection. App Shielding protects against these with its code injection prevention feature. In addition, App Shielding also prevents the unwanted leak of data from the application in form of the keyboard cache that the iOS keyboard uses.

Screenshot and screen recording protection

Applications often display sensitive information that should not be easily extracted from the application. A screenshot or screen recording, however, would compromise this information.

Screenshots are taken in different ways. They can be initiated by the user, taken by the system for various reasons (e.g., the task manager when changing between running apps), and captured by screen mirroring.

App Shielding is able to block all three use cases. When enabled, this feature renders any screenshot of the protected app as a plain black image. If a screenshot is taken when switching between apps on the device, then only the window that contains the protected app is obscured.

Similarly, a screen recording of the protected app results in a plain black video. Because screen sharing uses screen recording, this feature also blocks screen sharing apps like TeamViewer.

Shielding

Shielding an application with App Shielding renders the application useless if App Shielding is prevented from running. App Shielding provides an application that offers protection from various forms of attacks. Much of this protection is dependent on App Shielding itself running. For example, an attacker could try to circumvent some of the App Shielding protections by running the application without invoking App Shielding. Shielding the application will protect against such an attack.

App Shielding does not currently support shielding on x86 architectures. When building for x86, shielding is automatically disabled. This is typically only used when building for a simulator, so normally it is not important, but it does mean that simulator builds are much easier to attack. We strongly recommend not to ship simulator builds to potential attackers.

Static security features

In addition to the security functions that result in a callback, App Shielding can be configured to provide the following supplementary security features:

• Prevent user input made to the application from being recorded in the iOS keyboard cache.

• Prevent iOS from saving a screenshot of the application when the application is no longer in foreground.

• Prevent attachment of debuggers to the application. This feature will also prevent debugging using Xcode, so it should be deactivated during development/testing.

• Prevent libraries from being injected when the application is loaded. This is the only feature which cannot be configured and is hardcoded into the static App Shielding library. Since this feature also hampers testing and debugging, it is deactivated in the Debug version of App Shielding.

• Prevent external screens (connected through an adapter or AirPlay) from mirroring the application window.