freeRASP: runtime threat detection for mobile apps, across a dozen platforms

What RASP is, and where freeRASP sits in it

The readme starts by defining the field, and the definition is the one a buyer needs.

In-app protection is a mobile security technology that allows mobile applications to check the security state of the environment they run within, actively counteract attack attempts, and control the integrity of the app. Such technology is also called RASP, Runtime App Self Protection, or App Shielding.

freeRASP is described as a mobile in-app threat detection and security monitoring SDK, and it aims to cover the main aspects of RASP and application shielding. It is a lightweight and easy-to-integrate security library designed to protect apps from potential threats during their runtime, and it contains multiple security checks, each aimed to cover a possible attack vector.

The important word in that last sentence is multiple. A single check, such as a root detection routine, is a well-understood problem with a well-understood set of bypasses, and the value of a library is that it runs a set of them together and keeps them current. The check list in the readme is the concrete expression of that: the checks are grouped by the vector they cover rather than by the API they use, and the groups are rooted devices, a compromised device state, active attack tools, automated input, and the environment.

The key advantages are listed as five items. Reactions to attacks and detected security threats through an API. Simple download and install with clear source code snippets. Insignificant effect on the app performance. A weekly security report by email indicating the security status of devices and app integrity. And fulfilment of the OWASP MASVS V8 Resiliency Against Reverse Engineering requirements.

That last one is a meaningful marker, because MASVS is the mobile application security verification standard, and V8 is the chapter about resisting reverse engineering. A library that claims to fulfil a specified set of requirements is making a claim that can be assessed against the document rather than taken on trust.

The checks, grouped by the thing they detect

The feature list is the most informative part of the readme, and it is worth reading as a taxonomy of mobile attacks rather than as a feature list.

The first group is the compromised device. The library detects the use of rooted or jailbroken devices, and it names the specific tools: su, Magisk, KernelSU, Shamiko, HideMyApplist, unc0ver, checkra1n and Dopamine. Naming those is unusual and useful, because root detection is otherwise a black box and the specific implementations are what determine whether a check works at all. Alongside that it detects an unlocked or compromised bootloader, and it detects unsecured device environments such as Developer Mode and enabled ADB.

The second group is the attack tools themselves. It detects reverse engineering attempts, and it detects running hooking frameworks, naming Frida, LSPosed, Xposed and Shadow. It detects UI automation and driven-input attacks, with Appium given as the example, which covers the case where an attacker drives the interface rather than tampering with the binary.

The third group is the application itself. It detects tampering or repackaging of the application, and it detects installing the app through untrusted methods or unofficial stores, which is the distribution side of the same problem: a modified copy of your application, installed from somewhere you did not authorise.

The fourth group is the data. It prevents data leakage via screen capturing, with screenshots and screen recording named, and this is the one item in the list described as prevention rather than detection, which is a meaningful difference for a developer deciding what a signal is worth.

And the fifth group is the environment and the network. It identifies device spoofing attempts, with location or GPS mocking and time manipulation named, and it monitors for suspicious network connections, with system VPN and unsecure Wi-Fi named.

The distinction between the groups matters operationally. A root detection hit and a GPS spoofing hit are different severities, and a library that reports them all as the same boolean is much less useful than one that reports a category, because the response to each is different.

One umbrella, a dozen platform packages

The repository is a meta-project, and the tree shows it. The top-level directories are Android, Capacitor, Cordova, Flutter, Kotlin Multiplatform, React Native, Unity, Unreal Engine and iOS, alongside a .gitmodules file, a README, a LICENSE, the .github/ directory and a visuals/ folder for the images.

A .gitmodules file in the root with a directory per platform is the mechanism, and it means the platform SDKs are separate repositories checked out alongside:

Android
Capacitor
Cordova
Flutter
Kotlin Multiplatform
React Native
Unity
Unreal Engine
iOS

The readme says you can check platform-specific submodules for the installation guide and specific details, and it links each one: Flutter with a pub.dev package, Capacitor, React Native, Cordova, Android, iOS, Kotlin Multiplatform, and Unity and Unreal Engine.

Two of those are marked differently from the rest. The Unity and Unreal Engine links both end in a POC suffix, which is the readme's own way of saying they are proof of concept, and a reader should treat the engine integrations accordingly.

The list of frameworks is the practical point. A team that ships a Flutter app and a React Native app and a native iOS app can use the same detection library across all three, and the framework-specific packages are wrappers that present the same checks through each ecosystem's idioms, while the checks themselves live in one place. That is the difference between a vendor with many SDKs and a vendor with one SDK and many wrappers, and for a security library it is the difference that matters, because the wrappers are the part that has to track a fast-moving framework and the checks are the part that has to track a slow-moving attack surface.

Kotlin Multiplatform sits in that list too, which is the modern answer to the same problem: one implementation of the checks compiled for several targets rather than several implementations.

The documentation arrangement is worth noting, because the readme points out in two places that the official documentation has moved to a new location, with a docs-and-articles portal and a GitBook page, and the wiki for details about the performed checks and their importance. The repository is therefore the index rather than the manual, which is the right shape for something with a dozen platform packages and a weekly changelog.

freeMalwareDetection, and the reporting side

Two features sit outside the core detection set, and both are documented separately.

The first is freeMalwareDetection, described as a powerful feature designed to enhance the security of an Android application by quickly and efficiently scanning for malicious or suspicious applications, based on various blacklists and security policies. It helps to detect apps with suspicious package names, hashes, or potentially dangerous permissions.

The detection of suspicious package names, hashes and dangerous permissions is a different technique from everything else in the library. Root detection, hooking detection and tamper detection all look at the state of the running process. This looks at the other applications installed on the device, which means it is a signal about the device rather than about the app, and it is only available on Android, where the installed package list is readable.

The implementation is in a separate repository, and the readme is explicit that after integrating freeRASP you should visit that repository to learn more about the feature. Splitting it out is sensible, because it is a distinct capability with distinct dependencies, and a team that does not want it does not have to take it.

The second is the reporting side, in the key advantages list: a weekly security report by email indicating the security status of devices and app integrity.

That is the part of the design that a developer should think about before integrating, because it is the only item in the list that involves data leaving the device. The checks themselves are local, but a weekly report about the security status of your devices and the integrity of your app is a telemetry channel, and whether it is opt-in, what it contains and where it is sent are questions the integration guide will answer and the readme does not.

So the library has three layers: local detection with a reaction API, a device-level malware scan on Android, and a reporting service. A team that wants only the first can take only the first, and knowing that the other two exist is what makes it possible to decide.

The project process, and the licence question

The readme describes how the project is run, and it is a process designed for outside contributions.

If you have ideas for improvements, you are asked to raise an issue and mark it with an enhancement label, and the enhancements are tracked using GitHub Projects to keep tasks organized and connected to relevant issues or pull requests, with the project board linked. A public board rather than a list in the readme is a reasonable choice for a project with many platform packages and a stream of incoming issues.

The documentation links are extensive, and they point at an integration guide, a wiki describing the performed checks and their importance, and a What's New and Changelog page that the readme says covers new features, enhancements and bug fixes across Android, iOS, Flutter, React Native, Capacitor, Cordova, Kotlin Multiplatform, Unity and Unreal Engine. The changelog being per-platform matters, because a change in one wrapper can break a build without touching the others.

Then there is the licence section, and it is where the material gets interesting. The readme says this project is provided as freemium software, that is, there is a fair usage provision, and the sentence is cut off there in the visible text. The licence field in the repository metadata, on the other hand, says MIT.

Those two statements are not obviously compatible, and a freemium model with a fair usage provision is not the same thing as an MIT licence with no conditions. It is entirely normal for a commercial security vendor to publish its SDK under terms that let small and evaluation use through for free and require a commercial licence above a threshold, and the repository metadata can be set to a permissive identifier by convention or by tooling while the actual terms live in the LICENSE file.

So the practical advice is to read the LICENSE file rather than the badge. For a security SDK, the fair usage provisions are usually about volume or about what you are allowed to do commercially, and those are the terms that decide whether the library is free for your product or is a paid dependency, and a badge on the repository is not a reliable guide to that.

The rest of the metadata is modest. The primary language is recorded as unknown, which is consistent with a meta-repository of native and cross-platform submodules rather than a single code base, the default branch is master, the last push was on 2026-08-26, and there are no GitHub releases, so the versions live in the per-platform packages and the changelog.

Where freeRASP is the wrong tool

The first limit is that detection is not prevention, and the readme is mostly careful about this even where a reader might not be. The feature list says that screen capture leakage is prevented, and everything else is described as detection, monitoring or identification. A library that tells you a device is rooted is not a library that stops the attack, and a product whose security claim rests on the SDK will have to build the reaction itself, from the API that reports the threats.

The second is the false positive problem, and it is the reason this category of library is hard to deploy. Root detection in particular is a set of heuristics about files, processes and system properties, and a developer with a legitimate debugging setup, an emulator, a corporate management profile or a device with a bootloader unlocked for a reason will trip it. A check that fires on every corporate phone is a check that gets switched off, and the library is only as good as the policy around when to react and when to log.

The third is that the umbrella structure means the SDK you use is not the code in this repository. Each platform lives in its own submodule with its own installation guide, its own version and its own release cadence, and a team integrating the Flutter package is depending on a different artefact from a team integrating the native iOS one. That is normal for a cross-platform vendor and it means version pinning has to be done per platform.

The fourth is the platform coverage of the checks themselves. Several detections are inherently Android or inherently iOS: Magisk and the rooted-device list are Android concepts, checkra1n and unc0ver are jailbreaks, and the emulator and developer-mode signals differ. A team with both platforms will get different threat categories on each, and a security dashboard that expects the same event names on both will need a mapping.

And the fifth is that a security SDK is code you ship to attackers. It runs on a device that somebody is trying to break, it reports on that device, and a determined analyst can read it. Some checks are therefore inherently advisory, and a team that treats a detection as a strong signal is over-reading it.

Editorial conclusion

freeRASP is worth evaluating if you ship a mobile app and need evidence about how it is being attacked, because the checks cover the attack vectors that matter in practice, from Magisk and Frida to Appium-driven input and GPS mocking, and because the same library is available for the platforms teams actually use, so the detection logic does not have to be reimplemented per framework. It is the wrong tool if you need to stop an attack rather than detect one. Before you adopt it, check three things: the licence, because the licence field in the repository metadata says MIT while the readme describes the project as freemium software with a fair usage provision, and those two statements do not obviously agree, so read the LICENSE file before you build a commercial product on it; which platform package you need, because this repository is the umbrella and the actual SDKs live in separate submodules with their own installation guides, and the Unity and Unreal Engine entries are marked as proof of concept; and that you understand what you get, since the SDK detects and reports rather than prevents, and the readme is explicit that screen capture leakage is prevented while the rest is threat detection with reactions through an API.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. talsec/Free-RASP-Community on GitHub