Running an application inside an emulator/simulator allows an attacker to hook or trace program execution. For applications running inside an emulator, it is easy to inspect the system's state, reset it to a saved image, or monitor how the app operates. Keep in mind that not every emulator/simulator usage means an ongoing potential threat for the application.

Below are code snippets demonstrating emulator detection across various platforms:

Welcome to the freeRASP wiki page!

This page provides additional information about the product. The main goal is to present clear and easily accessible content that will help you better understand freeRASP. We hope you find it helpful and informative.

What will you find on this Wiki page?

• How to Get the Signing Certificate Hash.

• Details on Callback Delay, Telemetry Impact, and Threat Scanning.

• Information about Threat detection.

• Overview of Code Obfuscation.

We encourage you to explore the different sections of this wiki to gain a more comprehensive understanding of the freeRASP product and its features. If you have any questions or need further assistance, please feel free to reach out to our support team at support@talsec.atlassian.net.

We would like to reflect on a few performance and telemetry-related topics that emerge occasionally.

Common Questions:

• Why does it take too long to finish all the checks?

• How to know when all checks are finished?

• When are telemetry data transmitted?

Key Notes:

• Incidents that are triggered during the development (integration & testing) won't happen to a majority of users in the production.

• Callbacks can be invoked slower if the freeRASP backend endpoint is overloaded. Data collection takes precedence. However, do not worry; the application will function as intended, and only callbacks might be a little delayed.

The Performance

freeRASP works smoothly in production, but it may be tricky to understand all the freeRASP concepts during development. During the integration and testing of the freeRASP, you may have observed that it took longer than expected to get results for all threats (callbacks). You want to get results quickly, respond to threats effectively, and ensure there is no noticeable jankiness in the UI interactions.

freeRASP has to do a lot of work once started. The cold boot is a really intensive moment when all detections must be performed, telemetry data transmitted, and callbacks to your app must be delivered (in this order).

Talsec team efforts and community contributions allow freeRASP to improve the performance and security trade-offs continually by tuning the asynchronous processes, network activity, and internal business logic. Like that time when the internal detector ordering was reworked to significantly speed evaluation based on this reported issue and the telemetry insights about the speed of detectors 👌.

Beware Development vs. Production Environment Bias

Remember the phrase "It is darkest before the dawn"? The integration and testing of freeRASP are inherently accompanied by unintentional threat callbacks invoked by incorrect provisioning of the app's signature (appIntegrity callback), using a simulator for development, an unofficial store (because you haven't published it yet), and others. We've all been there.

It may also seem disconcerting to see that it takes too long until the last expected threat callback invokes. Yet, keep in mind that in production, these incidents won't happen for the genuine unaltered apps run in normal conditions. The performance impact will be negligible. On the contrary, the comfort of a potential attacker and performance degradation in adverse conditions is acceptable.

Cold Boot Telemetry & Best Effort Service

freeRASP collects security diagnostics data (read more in User Data Policies) in accordance with the Fair Usage Policy. Every detected threat is immediately synchronously logged to a common freeRASP backend. Latencies inflicted by the overload of the endpoint are unfortunate, but we continuously improve and scale as much as possible.

Before installation or updating on a device, Android requires that all APKs be digitally signed with a certificate. The signing certificate hash is a unique identifier of the certificate used to sign the application, serving to verify the application's origin.

Application Signing

Developers can sign the application using one of the following methods:

• Manual App Signing.

• Play App Signing.

Manual App Signing

In manual app signing, the developer owns a keystore used to sign the application. You can use tools like keytool or apksigner to retrieve certificate details, including the SHA-256 digest.

Using keytool:

keytool -printcert -jarfile app.apk

Using apksigner:

apksigner verify --print-certs app.apk

Play App Signing

With Play App Signing, Google manages and protects your app's signing key for you and uses it to sign your applications. You can find the SHA-256 fingerprint of the certificate in the Google Play Console:

1. Go to View App.

2. Navigate to Setup > App Signing.

3. Under App Signing Key Certificate, locate the SHA-256 fingerprint.

An example SHA-256 fingerprint looks like this:

88:8c:7f:02:d6:2e:ed:3a:53:bb:9c:a6:6b:82:5c:0d:78:a8:e5:b6:b2:11:28:bc:f5:ac:67:c8:e0:a3:7c:5a

Converting the SHA-256 Hash to Base64

To convert hex string to Base64 form, use an online like Base64 Encode. After conversion, you'll receive a string like this:

iIx/AtYu7TpAu5cma4JdDXio5bayFSi89axnyOCjfFo=

The resulting string is used in the Talsec configuration as a signing certificate hash.

freeRASP performs several security checks to detect potential threats during runtime, each targeting specific attack vectors. Developers and business owners can determine the appropriate response to these incidents, whether by terminating the application, alerting the user, logging the incident details, or choosing to ignore it.

For a detailed explanation of each security check and guidance on selecting an appropriate response, please refer to the individual threat descriptions in the subsections. Remember, the ideal response will depend on your application's specific security needs and use cases.

Rooting/jailbreaking is a technique of acquiring privileged control over the operating system of an Android/iOS device. While most users root their devices to overcome the limitations put on the devices by the manufacturers, it also enables those with malicious intent to abuse privileged access and steal sensitive information. Many different attack vectors require privileged access to be performed. Tools such as , or can hide privileged access and are often used by attackers.

freeRASP uses various checks to detect whether the device is rooted or jailbroken. It detects not only rooted/jailbroken devices but also looks for the presence of their hiders (e.g., Magisk, Shad0w, Dopamine).

From our data, around 0.5% - 1% of devices have traces of rooting and jailbreaking. Keep that in mind when choosing the appropriate reaction type.

Below are code snippets demonstrating root and jailbreak detection across various platforms:

While most developers use debuggers to trace the flow of their program during its execution same tool can be attached to an application in an attempt to reverse engineer, check memory values, and steal confidential information. This method looks for specific flags to determine whether the debugger is active and offers the option to disable it.

Below are code snippets demonstrating debugger detection across various platforms:

The application can be analysed or modified even though its source code has not been changed, applying a technique known as hooking. This technique can be used to intercept system or application calls and then modify them. An attacker can exploit this by inserting new (often malicious) code or by altering existing one to obtain personal client data. The most well-known hooking frameworks are , , or .

Below are code snippets demonstrating hook detection across various platforms:

Every application can be easily modified and then resigned by an attacker. This process is known as application repackaging. There may be many reasons for application repackaging, whether it's adding new code, removing app protections, or bypassing app licensing. A modified/tampered application is often distributed using third-party stores or other side channels.

Talsec uses various checks to detect whether the application was tampered (e.g., changed package name, signing hash).

Below are code snippets demonstrating app tampering detection across various platforms:

Detecting a running VPN service on mobile devices is critical for security-sensitive applications, as it can indicate potential privacy and security risks. VPNs can obscure the user’s actual IP address and route data through servers potentially under external control, which might interfere with geographical restrictions and bypass network security settings intended to protect data integrity and confidentiality. Such anonymising features could be exploited to mask illicit activities, evade compliance controls, or access services from unauthorised regions. FreeRASP checks whether the system VPN is enabled.

Below are code snippets demonstrating system VPN detection across various platforms:

// Android system VPN detection
override fun onSystemVPNDetected() {
    TODO("Not yet implemented")
}

// iOS system VPN detection
case systemVPN

// Flutter system VPN detection
onSystemVPN: () => print("System VPN detected")

// Cordova system VPN detection
systemVPN: () => {
    // Place your reaction here
}

// React Native system VPN detection
systemVPN: () => {
    // Place your reaction here
}

// Capacitor system VPN detection
systemVPN: () => {
    // Place your reaction here
}

Saving any sensitive data on a device without a lock / passcode makes them more prone to theft. With no user authentification device can be accessed and modified with minimal effort. freeRASP checks if the device is secured with any type of lock.

Below are code snippets demonstrating passcode detection across various platforms:

// Android lock check
override fun onUnlockedDeviceDetected() {
    TODO("Not yet implemented")
}

// iOS lock check
case passcode

// Flutter unlocked device and passcode detection
onPasscode: () => print("Passcode not set")

// Cordova unlocked device and passcode detection
passcode: () => {
    // Place your reaction here
}

// React Native unlocked device and passcode detection
passcode: () => {
    // Place your reaction here
}

// Capacitor unlocked device and passcode detection
passcode: () => {
    // Place your reaction here
}

Device binding is attaching an application instance to a particular mobile device. This method detects a transfer of an application instance to another device. A new install of the application (e.g. in case of buying a new device and transfer the apps) is not detected.

The deviceID detects, whether the device identifier has been changed. It is triggered after reinstallation of the application if there are no other applications from the same vendor installed. The value can also change when installing test builds using Xcode or when installing an app on a device using ad-hoc distribution.

Below are code snippets demonstrating device binding detection across various platforms:

// Android device binding check
override fun onDeviceBindingDetected() {
    TODO("Not yet implemented")
}

// iOS device binding methods
case deviceChange
case deviceID

// Flutter 
// device binding and device change detection
onDeviceBinding: () => print("Device binding")

// device ID 
onDeviceID: () => print("Device ID")  // iOS only

// Cordova 
// device binding and device change detection
deviceBinding: () => {
    // Place your reaction here
}

// device ID 
deviceID: () => {  // iOS only
    // Place your reaction here 
}

// React Native 
// device binding and device change detection
deviceBinding: () => {
    // Place your reaction here
}

// deviceID
deviceID: () => {  // iOS only
    // Place your reaction here 
}

// Capacitor 
// device binding and device change detection
deviceBinding: () => {
    // Place your reaction here
}

// deviceID
deviceID: () => {  // iOS only
    // Place your reaction here 
}

The freeRASP SDK contains public API, so the integration process is as simple as possible. Unfortunately, this public API also creates opportunities for the attacker to interrupt freeRASP SDK operations or modify the custom code in threat callbacks. All internal freeRASP classes are already obfuscated, so it is simple to distinguish freeRASP sources from the rest of the application code during the static analysis. In order for freeRASP to be as effective as possible, it is highly recommended to apply obfuscation to the final package/application, making the public API more difficult to find and also to make it partially randomized for each application so it cannot be automatically abused by generic hooking scripts.

Please follow the integration guide of your platform for more information about how to obfuscate the app.

Below are code snippets demonstrating missing obfuscation detection across various platforms:

// Android
override fun onObfuscationIssuesDetected() {
    TODO("Not yet implemented")
}

// Flutter
onObfuscationIssues: () => print("Obfuscation issues")

// Cordova
obfuscationIssues: () => {
    // Place your reaction here
},

// React Native
obfuscationIssues: () => {
    // Place your reaction here
},

// Capacitor
obfuscationIssues: () => {
    // Place your reaction here
},

The freeRASP contains public API so that the integration process is as simple as possible. Unfortunately, this public API also creates opportunities for the attacker to use publicly available information to interrupt freeRASP operations or modify your custom reaction implementation in threat callbacks. In order for freeRASP to be as effective as possible, it is highly recommended to apply obfuscation to the final package/application, making the public API more difficult to find and also partially randomized for each application so it cannot be automatically abused by generic hooking scripts.

The majority of Android projects support code shrinking and obfuscation without any additional need for setup. The owner of the project can define the set of rules that are usually automatically used when the application is built in the release mode. For detailed guidance, explore the official documentation through these links: and .

Android developer mode allows deeper system access and debugging capabilities that can bypass app security measures. Developer mode can enable settings that facilitate the installation of uncertified applications and the execution of potentially harmful code, posing significant risks to data integrity and app functionality. FreeRASP detects whether the developer mode is enabled.

Below are code snippets demonstrating developer mode detection across various platforms:

The Secure Enclave and the Android Keystore system make it very difficult to decrypt sensitive data without physical access to the device. In that order, these keys need to be stored securely. freeRASP checks if the keys reside inside secure hardware.

Below are code snippets demonstrating missing hardware detection across various platforms:

ADB (Android Debug Bridge) Enabled is a power-user feature activated through the "USB Installation" option in the Developer settings. This state can signal potential security risks, such as apps being installed via USB, the device being connected to a man-in-the-middle (MiTM) proxy, or the device running as an emulator. When ADB is enabled, it allows extensive access to the device, including pulling and pushing files, issuing shell commands, working with the activity manager (e.g., starting activities, broadcasting intents, modifying hidden Android settings, attaching a profiler to a process, or making an app debuggable), and managing packages. Additionally, it enables capturing screenshots, recording the screen, and other actions that can compromise app security and user privacy. FreeRASP detects whether the USB debugging is enabled.

Below are code snippets demonstrating ADB enabled detection across various platforms:

Users can share a copy of the application on unofficial stores or various pirate forums. While some users download these copies to avoid paying for the product, they can include unknown and possibly dangerous modifications. Verifying an official installation consequently protects both the users and the owner. This reaction is also triggered, if you install the application through alternative ways like unofficial store or Xcode build.

Below are code snippets demonstrating detection of unofficial installation across various platforms:

// Android
override fun onUntrustedInstallationSourceDetected() {...}

// iOS
case unofficialStore

// Flutter
onUnofficialStore: () => print("Unofficial store")

// Cordova 
unofficialStore: () => {
    // Place your reaction here 
}

// React Native
unofficialStore: () => {
    // Place your reaction here 
}

// Capacitor
unofficialStore: () => {
    // Place your reaction here 
}

Define alternative supported stores

If you want to define which applications can install the application, insert its package name in the supportedAlternativeStores (or supportedStores on Flutter) parameter. If you publish on Google Play, Huawei AppGallery, App Store (iOS), and TestFlight (iOS), you don't need to assign anything, as they are already supported out of the box.

The application can also be installed by "cloning" apps, which users employ to transfer apps between devices. The following list comprises popular examples of such apps. By default, freeRASP categorizes them as installations from an unofficial store .

Finally, it's very common application gets installed through browser, file manager, cloud storage or various messaging apps. By default, freeRASP categorizes them as installations from unofficial store.