RASP That Doesn’t Lock Out Real Customers

Runtime protection, or RASP, is now expected in banking and other money apps. Partner banks, auditors and fraud teams ask for root detection, hooking detection and anti-tampering checks.

The hard part is not detecting threats. It is detecting them without blocking real customers. A check that locks out a genuine user on an unusual device is a support ticket, a bad review and sometimes a lost customer.

In this article, we’ll walk through how we built and verified runtime protection for a retail bank’s Android app, and the design choices that kept false positives down.

---

What the App Needed to Detect

• Hooking frameworks such as Frida, which can change app behaviour at runtime.

• Rooted devices, where the operating system’s protections no longer hold.

• Emulators, often used for automated abuse at scale.

• Repackaged apps, modified and redistributed outside the official store.

• Overlay and accessibility abuse, a common technique of banking malware.

📌 Key Insight:

Every detector has two failure modes: missing an attack, and flagging an honest user. Most RASP discussions only talk about the first.

---

Design Choices That Kept False Positives Down

1. Exact Values, Not Loose Heuristics

Many emulator checks search device properties for suspicious words. That also catches real hardware with unusual names. We switched to exact-value emulator detection, covered by 35 tests, and verified there were no false positives on Chromebooks, which run Android apps and often trip naive checks.

2. Classifiers Tested on Real Apps

For autoclicker detection, we built a classifier and tested it against real apps, not only against lab samples. Behaviour on real software is where a classifier either earns trust or starts blocking honest users.

3. Identity Checks That Don’t Depend on the Device

Anti-repackaging uses a signing-certificate check and an installer check. Both look at the app itself, so they behave the same on every phone.

4. A Kill-Switch for Every Detector

Runtime detection sits behind a remote kill-switch. If a new phone model starts triggering a check, the team does not have to wait for a store release to stop locking people out.

---

How We Verified It

The verification matrix ran each scenario on test builds:

Scenario	Expected Result
Frida attached to the app	Block screen within 5 seconds
App launched on an emulator	Blocked
App launched on a real phone	Passes normally

Testing the “should pass” rows is as important as testing the “should block” rows. That is where false positives are caught before customers find them.

---

What RASP Does Not Do

• It does not make an app unbreakable. A determined attacker can bypass client-side checks with enough time.

• It does not replace server-side controls such as session validation and fraud scoring.

• It does not cover industry-specific requirements such as certified geolocation for gambling.

What it does well is raise the cost of common attacks, stop off-the-shelf tooling and automated abuse, and give the backend signals to act on.

How Mobian Helps

At Mobian, these runtime controls were part of a security remediation for a retail bank that started from a MobSF score of 48/100 and produced 124 tracked fixes. We design detection for the users you have, not just the attackers you fear — with tests for both, and a way to switch a check off if it misbehaves.

Conclusion

Good RASP is measured on two sides: how fast it stops a hooking tool, and how rarely it bothers a real customer. Exact-value checks, classifiers tested on legitimate apps, device-independent identity checks and a remote kill-switch make it possible to block Frida in seconds while a customer on a Chromebook never notices anything at all.

Frequently asked questions

What is RASP in a mobile app?

Runtime Application Self-Protection (RASP) is a set of checks an app runs on itself while it is in use: detecting root, hooking tools such as Frida, emulators, debuggers and repackaged versions of the app. When a check fires, the app can block, limit features or report to the server.

Why do RASP checks cause false positives?

Many detections rely on loose heuristics, such as searching device properties for words associated with emulators. Real devices, including Chromebooks running Android apps, can match those patterns. A false positive locks a paying customer out of their own account.

What is a RASP kill-switch?

A remote setting that lets the team disable or relax a specific detector without releasing a new app version. If a check starts blocking real users on a particular device, the team can switch it off in minutes while a fix is prepared.

Can RASP stop a determined attacker?

No. A skilled attacker with enough time can bypass client-side checks. RASP raises the cost of attacks, stops common tooling and automated abuse, and gives the server signals to act on. It complements secure design and server-side controls; it does not replace them.

Is RASP useful outside banking?

Yes. Emulator farms, autoclickers and repackaged apps drive bonus abuse in gaming and fraud in crypto apps. The same detectors apply, though each industry also has specific requirements, such as certified geolocation, that RASP does not cover.