Security Features on Android

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.

Unlocked bootloader detection

The device’s bootloader is responsible for loading the operating system. App Shielding can detect if this bootloader has been "unlocked", which allows the device to then be flashed and rooted. An unlocked bootloader also suggests that the device might be running a custom and/or malicious operating system. Even though an unlocked bootloader on its own is not a security threat, it is often a first step to other potential attacks.

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 on Android.

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 Configuration options for Android.

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 Configuration options for Android.

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.

Overlay 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. For more information, refer to the Android Developer documentation.

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, the blockNonSystemOverlays configuration option can also be used to block and remove all non-system overlays when the protected app is running.

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.

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.