The following article will explain how to test mobile applications against any implemented screenshot prevention mechanism and then it will try to propose mitigations to such problem according to the context.
TLDR; None of the proposed solutions will provide a full protection against screenshotting. Therefore all of them shall be considered as mitigations.
In this section we will focus on testing and preventing mobile screenshot via static (e.g. perform a secure code review or a mobile application reverse engineering task) and dynamic (e.g. test a mobile application in its execution environment) contexts.
First things first: anyone approaching mobile application security should carefully read the OWASP Mobile Security Testing Guide (MSTG)[1][2].
Assuming we have the source code of a mobile application and we have to check if the app implements any mitigation against screenshot attacks, either user or system generated.
What should we look for?
Usually the common remediation is to set FLAG_SECURE to LayoutParam, hence the first step is to search for it in the codebase.
But, if we have access to the source code of an application somehow decompiled from a packaged application, it might be possible that the FLAG_SECURE keyword could have been obfuscated or replaced with its integer value.
Therefore, the values to search for, are:
If any of those values are found, it must be checked whether it is used as parameter set to the WindowManager LayoutParams.
It should be noted that this flag must be set in all the Android Activities involved in the application and it would be effective for both user and system generated screenshots.
Since in iOS it is not possible to prevent user generated screenshots, we have to search for any code related to the notification system which can be used to provide awareness about the taken screenshot.
It is then possible to search for the following keywords:
If any of the following keywords is found, it would be possible to then observe a function callback being executed after a user generated screenshot has been created.
On the other hand, for system generated screenshots, it would be necessary to analyze pieces of code which are responsible to handle the transitions between foreground and background application statuses.
Since the system generated screenshots are generated just before the application has been put in the background status, in these portions of code, if any remediation has been implemented, we are expecting to find some mechanism which would hide or obfuscate sensitive parts of the UI just before the screenshot has been generated.
It would then be possible to search for the possible values:
TLDR; Let's try to generate a screenshot of the application and let's check if the application UI is shown in the device task manager.
First of all, let's focus on how we can generate a screenshot of our running application. Basically it will depend on which OS and device type we are testing.
On a variety of Android devices, it is possible to generate a screenshot by using device specific combo keys. The most common combinations are:
It would be also possible to generate a screenshot by using the function tile in the system tray, but it strongly depends on the OS customizations.
If we are using the Android emulator, we can use the specific button on the emulator toolbar:
On iOS it depends on which physical keys are available on the target device. The two possible combo keys are:
Finally, if we are using the iOS simulator, we can use the combo key CMD + S or we can use the drop down menu entry under File -> New Screen Shot.
In all the above cases, the positive probe is the successful generation of a screenshot containing the same views actually on the device's screen, without any kind of modification and without any kind of notification generated on the device.
If the running application is properly secured, we will see the following notification being generated on Android:
On the other hand, since in iOS it is not possible to prevent a user to generate a screenshot of the application, if the running app is implementing a mitigation against screenshot generation it is not actually possible to define which behavior a pentester would see.
Some possible mitigations are:
Beware that also a transparent and invisible mechanism could be implemented on iOS in order to warn the user about the screenshot generation, so dynamic analysis could not be sufficient in order to fully understand if an app is implementing some mitigation mechanism.
On both the operating systems, the test is the same and is pretty straightforward:
At this point, if an application screenshot is shown identical as it was possible to observe when the app was in foreground, it means that no prevention mechanism was implemented.
On the other hand, if a blank screen is shown or if the image is partially obfuscated, it does mean that the app is actually implementing some sort of full or partial prevention mechanism against system generated screenshots.
Which APIs are provided to prevent or mitigate the issue?
One flag to rule them all.
Basically Android offers the LayoutParam FLAG_SECURE [3] which can be used to prevent both user and system generated screenshots.
Simple and straightforward.
On iOS the developer is not provided the ability to prevent user generated screenshots. This is due to the strict UI/UX guidelines provided by Apple which are preventing developers from interfering with the standard OS behavior.
Two kinds of APIs are interesting from the security point of view, when talking about screenshot prevention mechanisms.
For user generated screenshots it is possible to use the userDidTakeScreenshotNotification [4] system wide notification. In this way, it would be possible to run code just after a screenshot was generated.
The most common approach is to generate a notification or an alert which warns the user about the generated screenshot. This would inform the user and will raise a red flag in case of the screenshot was not explicitly and voluntarily generated.
On the other hand, for system generated screenshots, it is possible to refer to the applicationWillResignActive [5] application's lifecycle callback. This callback is invoked just before any application is moved from the foreground to the background and enables developers to execute code just before the system generated screenshots are created.
These operations can include:
This section is intentionally left without any comment, since explanations have been provided in the above sections.
Just the source code that can be used in various scenarios and situations.
Pro tip: If some data is VERY sensitive, such as the combination of a credit card PAN, its PIN code and the CVV2 code, don't put it in your views. If some data is not displayed on the screen, it can't be screenshotted!
But since in the real world such approach is very often not applicable, let's dig into some mitigation implementations.
Protects from:
import android.os.Bundle
import android.support.v7.app.AppCompatActivity
import android.view.WindowManager
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
window.setFlags(
WindowManager.LayoutParams.FLAG_SECURE,
WindowManager.LayoutParams.FLAG_SECURE
)
}
}
import android.os.Bundle;
import android.view.WindowManager;
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
getWindow().setFlags(
WindowManager.LayoutParams.FLAG_SECURE,
WindowManager.LayoutParams.FLAG_SECURE
);
}
}
References: [6]
Protects from:
NotificationCenter.default.addObserver(
forName: UIApplication.userDidTakeScreenshotNotification,
object: nil,
queue: .main) { notification in
//Notify the user, log the action, etc...
}
NSOperationQueue *mainQueue = [NSOperationQueue mainQueue];
[[NSNotificationCenter defaultCenter] addObserverForName:UIApplicationUserDidTakeScreenshotNotification
object:nil
queue:mainQueue
usingBlock:^(NSNotification *note) {
//Notify the user, log the action, etc...
}];
Protects from:
- (void)applicationWillResignActive:(UIApplication *)application {
// hide main window
self.window.hidden = YES;
}
- (void)applicationDidBecomeActive:(UIApplication *)application {
// show window back
self.window.hidden = NO;
}
References: [8]
Protects from:
import android.os.Bundle;
import com.facebook.react.ReactActivity;
import android.view.WindowManager;
public class MainActivity extends ReactActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
getWindow().setFlags(
WindowManager.LayoutParams.FLAG_SECURE,
WindowManager.LayoutParams.FLAG_SECURE
);
}
}
import React from 'react'
import { AppState, Platform, View } from 'react-native'
const SecurityScreen = () => <View />
const showSecurityScreenFromAppState = appState =>
['background', 'inactive'].includes(appState)
const withSecurityScreenIOS = Wrapped => {
return class WithSecurityScreen extends React.Component {
state = {
showSecurityScreen: showSecurityScreenFromAppState(AppState.currentState)
}
componentDidMount () {
AppState.addEventListener('change', this.onChangeAppState)
}
componentWillUnmount () {
AppState.removeEventListener('change', this.onChangeAppState)
}
onChangeAppState = nextAppState => {
const showSecurityScreen = showSecurityScreenFromAppState(nextAppState)
this.setState({ showSecurityScreen })
}
render() {
return this.state.showSecurityScreen
? <SecurityScreen />
: <Wrapped {...this.props} />
}
}
}
const withSecurityScreenAndroid = Wrapped => Wrapped
export const withSecurityScreen = Platform.OS === 'ios'
? withSecurityScreenIOS
: withSecurityScreenAndroid
Then, in your App component:
import { withSecurityScreen } from './withSecurityScreen'
...
export default withSecurityScreen(App);
Pre bundled libraries are also available on NPM [10].
There are many Cordova plugins which can help on achieving the goal.
A good place to start is the cordova-plugin-prevent-screenshot-coffice open source repository.
Protects from:
Several commercial solutions are available on the market, however since there was no easy way to test any of them, this blog post will not promote or endorse any commercial tool.
TLDR; None of the proposed solutions will provide a full protection against screenshotting, therefore all of them should be considered as mitigations.
Since all the OSs handle the application status transitions in a different way, and different versions of OSs behave in a different way, it will always be possible to generate some sort of bypass of any implemented mitigation mechanism.
Moreover, let's say that if an application is running on an untrusted - jailbroken or rooted - device environment it is easy for an attacker to hook and bypass any kind of protection with some effort.
The chosen mitigation should then be biased on which data the application is showing on the screen and how much sensitive is this data.
Examples of such mitigation bypass are available in literature, such as [12].