Your app runs on the attacker's hardware
Every other post in this series assumes the device is a trusted — or at least neutral — platform. The app encrypts data, the OS protects memory, the hardware secures keys. That model works when the threat is an external attacker who doesn't control the device.
This post addresses the other case: the device is hostile territory. The user has rooted their phone, installed Frida, attached a debugger, and is actively trying to reverse-engineer, modify, or abuse your app. Maybe they want to bypass a paywall. Maybe they want to extract your proprietary API protocol. Maybe they want to cheat in your game. Maybe they're a security researcher testing your defenses.
Binary protection is the set of techniques that make this harder. Not impossible — nothing running on an attacker-controlled device is impossible to reverse — but expensive, time-consuming, and requiring real expertise rather than a five-minute tutorial.
Let's be clear about what binary protection is and isn't. It is not a substitute for server-side security. If your server trusts whatever the client sends, no amount of binary protection saves you. Binary protection raises the cost of attacking the client, buying time and discouraging casual attackers. It works in combination with server-side validation, certificate pinning, and the hardware security from the Secure Enclaves post.
Understanding the Flutter binary
Before protecting the binary, you need to understand what's in it.
A Flutter release build on Android produces:
app-release.apk
├── lib/
│ ├── arm64-v8a/
│ │ ├── libflutter.so ← Flutter engine (Skia/Impeller, Dart VM runtime)
│ │ └── libapp.so ← YOUR compiled Dart code (AOT-compiled)
│ └── armeabi-v7a/
│ ├── libflutter.so
│ └── libapp.so
├── assets/
│ └── flutter_assets/ ← fonts, images, asset bundles
├── classes.dex ← minimal Java/Kotlin code (platform channels)
├── AndroidManifest.xml
└── res/ ← Android resourceslibapp.so is where your Dart code lives. It's compiled to native ARM machine code by Dart's AOT compiler. Unlike Java/Kotlin (which compiles to Dalvik bytecode that's trivially decompilable), Dart's AOT output is actual machine code — similar in structure to compiled C. This is a natural advantage: decompiling machine code to readable source is significantly harder than decompiling JVM bytecode. For a detailed view, refer to our article on how your app becomes apk
However, libapp.so still contains:
- String literals: Every hardcoded string in your Dart code
- Symbol names: Class names, method names, field names (unless obfuscated)
- Type information: Dart's runtime type system metadata
- Snapshot data: The Dart heap snapshot that initializes your app's state
An attacker with a disassembler (Ghidra, IDA Pro) can read string literals, identify function boundaries, and trace program flow. With Dart-specific tools (darter, reFlutter), they can recover class structures and method names.
On iOS, the equivalent is the compiled binary inside the .app bundle. Same principles apply — AOT-compiled machine code with embedded strings and type metadata.
Layer 1: Dart obfuscation
Flutter has built-in obfuscation. It renames classes, methods, and fields to meaningless identifiers.
# Build with obfuscation enabled
flutter build apk --release --obfuscate --split-debug-info=debug-info/
# iOS
flutter build ipa --release --obfuscate --split-debug-info=debug-info/--obfuscate replaces human-readable names:
Before obfuscation:
class UserAuthService {
Future<AuthToken> loginWithCredentials(String email, String password) { ... }
Future<void> refreshToken(AuthToken token) { ... }
bool isTokenExpired(AuthToken token) { ... }
}
After obfuscation:
class aB {
Future<cD> eF(String a, String b) { ... }
Future<void> gH(cD a) { ... }
bool iJ(cD a) { ... }
}--split-debug-info extracts the mapping between original and obfuscated names into a separate directory. Keep this directory secure and don't include it in the APK/IPA. You need it to symbolicate crash reports — without it, stack traces show obfuscated names.
What obfuscation doesn't protect
- String literals:
"https://api.yourapp.com/v2/auth/login"is still plaintext in the binary - Control flow: The logic of your code is unchanged; an attacker can still trace execution
- API endpoints: Every URL your app calls is readable
- Business logic: The algorithm is the same, just with renamed variables
Obfuscation slows down a reverse engineer. It does not stop them. Think of it as removing road signs — someone can still navigate, it just takes longer. This connects directly to our article about R8 (formerly ProGuard) on android .
Layer 2: String encryption
String literals are the first thing an attacker searches for. API URLs reveal your backend. Error messages reveal logic. Hardcoded constants reveal algorithms. Encrypting sensitive strings removes this low-hanging fruit.
The approach: encrypt strings at build time, decrypt at runtime.
// lib/security/encrypted_strings.dart
/// Strings that are encrypted at compile time and decrypted at runtime.
/// This prevents trivial string extraction from the binary.
class SecureStrings {
// The "encrypted" values here are base64(XOR(plaintext, key))
// In production, use a build-time encryption step, not manual encoding
static final String apiBaseUrl = _decrypt(
'GhkbHBcXExYCFwUXHAMcAhcHFBwRHBIaFR0V', // encrypted at build time
);
static final String apiSecretHeader = _decrypt(
'EhcUBxIOFBsQFBcbHBIaFQ==',
);
static String _decrypt(String encoded) {
final key = _deriveKey(); // key is computed, not stored as a literal
final bytes = base64Decode(encoded);
final result = Uint8List(bytes.length);
for (var i = 0; i < bytes.length; i++) {
result[i] = bytes[i] ^ key[i % key.length];
}
return utf8.decode(result);
}
static Uint8List _deriveKey() {
// Build the key from non-obvious computations
// This makes it harder to find the key by searching for constants
final seed = DateTime(2024, 1, 1).millisecondsSinceEpoch;
final a = (seed >> 16) & 0xFF;
final b = (seed >> 8) & 0xFF;
final c = seed & 0xFF;
return Uint8List.fromList([a, b, c, a ^ b, b ^ c, a ^ c, a ^ b ^ c, ~a & 0xFF]);
}
}A more robust approach is to use a build-time code generator that encrypts strings during the build process and generates the decryption code automatically. The key and the encryption method can change with each build, making static analysis harder.
Important caveat: The decrypted string will exist in memory at runtime. An attacker with Frida can hook the _decrypt method and log every decrypted string. String encryption defeats static analysis (examining the binary without running it), not dynamic analysis (examining the running app). You need both layers.
Layer 3: Root and jailbreak detection
A rooted Android device or jailbroken iPhone gives an attacker capabilities that break your app's security assumptions: installing Frida, bypassing the sandbox, reading other apps' data, modifying system libraries.
Detecting root/jailbreak lets your app respond — by warning the user, disabling sensitive features, or refusing to run.
Android root detection
// android/app/src/main/kotlin/com/yourapp/RootDetector.kt
class RootDetector {
fun isRooted(): Boolean {
return checkSuBinary()
|| checkRootManagementApps()
|| checkDangerousProps()
|| checkRWPaths()
|| checkTestKeys()
}
private fun checkSuBinary(): Boolean {
val paths = listOf(
"/system/bin/su", "/system/xbin/su", "/sbin/su",
"/system/su", "/system/bin/.ext/.su",
"/system/usr/we-need-root/su-backup",
"/system/app/Superuser.apk",
)
return paths.any { java.io.File(it).exists() }
}
private fun checkRootManagementApps(): Boolean {
val packages = listOf(
"com.topjohnwu.magisk", // Magisk
"eu.chainfire.supersu", // SuperSU
"com.koushikdutta.superuser", // Superuser
"com.noshufou.android.su", // Superuser
"com.thirdparty.superuser",
)
val pm = context.packageManager
return packages.any {
try {
pm.getPackageInfo(it, 0)
true
} catch (e: Exception) {
false
}
}
}
private fun checkDangerousProps(): Boolean {
return try {
val process = Runtime.getRuntime().exec("getprop ro.debuggable")
val reader = java.io.BufferedReader(java.io.InputStreamReader(process.inputStream))
val value = reader.readLine()
value == "1"
} catch (e: Exception) {
false
}
}
private fun checkRWPaths(): Boolean {
return try {
val process = Runtime.getRuntime().exec("mount")
val reader = java.io.BufferedReader(java.io.InputStreamReader(process.inputStream))
val output = reader.readText()
// /system mounted as read-write is suspicious
output.contains("/system") && output.contains("rw,")
} catch (e: Exception) {
false
}
}
private fun checkTestKeys(): Boolean {
val buildTags = android.os.Build.TAGS ?: ""
return buildTags.contains("test-keys")
}
}For production, use a tested library like RootBeer (Android) rather than rolling your own checks. RootBeer includes native checks that are harder to bypass than pure Java/Kotlin checks.
iOS jailbreak detection
// ios/Runner/JailbreakDetector.swift
class JailbreakDetector {
static func isJailbroken() -> Bool {
return checkCydia()
|| checkSuspiciousPaths()
|| checkWriteAccess()
|| checkFork()
|| checkDYLD()
}
private static func checkCydia() -> Bool {
return UIApplication.shared.canOpenURL(URL(string: "cydia://")!)
}
private static func checkSuspiciousPaths() -> Bool {
let paths = [
"/Applications/Cydia.app",
"/Library/MobileSubstrate/MobileSubstrate.dylib",
"/bin/bash",
"/usr/sbin/sshd",
"/etc/apt",
"/private/var/lib/apt/",
"/usr/bin/ssh",
"/var/lib/cydia",
"/var/cache/apt",
"/var/lib/dpkg",
"/usr/libexec/sftp-server",
]
return paths.contains { FileManager.default.fileExists(atPath: $0) }
}
private static func checkWriteAccess() -> Bool {
let path = "/private/test_jb_write"
do {
try "test".write(toFile: path, atomically: true, encoding: .utf8)
try FileManager.default.removeItem(atPath: path)
return true // should not be writable on non-jailbroken device
} catch {
return false
}
}
private static func checkFork() -> Bool {
// fork() is restricted on non-jailbroken iOS
let result = fork()
if result >= 0 {
if result > 0 {
kill(result, SIGTERM) // kill child process
}
return true
}
return false
}
private static func checkDYLD() -> Bool {
// Check for suspicious injected dylibs
let count = _dyld_image_count()
for i in 0..<count {
guard let name = _dyld_get_image_name(i) else { continue }
let path = String(cString: name)
if path.contains("MobileSubstrate") || path.contains("cycript")
|| path.contains("frida") || path.contains("libhooker") {
return true
}
}
return false
}
}How attackers bypass root detection — and what to do about it
Root detection is a cat-and-mouse game. Attackers bypass it by:
- Hooking detection functions: Frida can intercept
isRooted()and returnfalse - Hiding root: Magisk Hide conceals root from specific apps
- Patching the binary: Modify the APK to remove detection code, re-sign
Each bypass has a counter:
- Anti-Frida detection (covered in the next section)
- Multiple detection vectors: Don't rely on one check. Use 10+ different signals. MagiskHide can hide the
subinary but often misses other indicators - Integrity verification (covered below) detects binary modification
The goal isn't to make bypass impossible, but to make it require significant effort and expertise — most casual attackers won't go beyond installing a "root hider" app.
Layer 4: Frida and debugger detection
Frida is the primary tool for dynamic analysis of mobile apps. Detecting it running on the same device is a critical defense layer.
Detecting Frida
// android/app/src/main/kotlin/com/yourapp/FridaDetector.kt
class FridaDetector {
fun isFridaRunning(): Boolean {
return checkFridaPort()
|| checkFridaLibraries()
|| checkFridaServerProcess()
|| checkFridaNamedPipes()
}
/// Frida's default communication port
private fun checkFridaPort(): Boolean {
return try {
val socket = java.net.Socket()
socket.connect(java.net.InetSocketAddress("127.0.0.1", 27042), 100)
socket.close()
true // connection succeeded — frida-server is likely running
} catch (e: Exception) {
false
}
}
/// Check for Frida libraries loaded into our process
private fun checkFridaLibraries(): Boolean {
return try {
val mapsFile = java.io.File("/proc/self/maps")
val content = mapsFile.readText()
content.contains("frida") || content.contains("gadget")
} catch (e: Exception) {
false
}
}
/// Check for frida-server process
private fun checkFridaServerProcess(): Boolean {
return try {
val process = Runtime.getRuntime().exec("ps -A")
val reader = java.io.BufferedReader(java.io.InputStreamReader(process.inputStream))
val output = reader.readText()
output.contains("frida-server") || output.contains("frida-agent")
} catch (e: Exception) {
false
}
}
/// Frida uses named pipes for communication
private fun checkFridaNamedPipes(): Boolean {
val dir = java.io.File("/proc/self/fd")
return try {
dir.listFiles()?.any { fd ->
try {
val link = java.nio.file.Files.readSymbolicLink(fd.toPath())
link.toString().contains("frida") || link.toString().contains("linjector")
} catch (e: Exception) {
false
}
} ?: false
} catch (e: Exception) {
false
}
}
}Detecting debuggers
// Debugger detection
class DebugDetector {
fun isDebuggerAttached(): Boolean {
return android.os.Debug.isDebuggerConnected()
|| checkTracerPid()
|| isDebuggable()
}
/// Check if another process is tracing us (ptrace)
private fun checkTracerPid(): Boolean {
return try {
val statusFile = java.io.File("/proc/self/status")
val content = statusFile.readText()
val tracerLine = content.lines().find { it.startsWith("TracerPid:") }
val tracerPid = tracerLine?.split(":")?.get(1)?.trim()?.toIntOrNull() ?: 0
tracerPid != 0 // non-zero means someone is tracing us
} catch (e: Exception) {
false
}
}
/// Check if the app is built as debuggable
private fun isDebuggable(): Boolean {
return (context.applicationInfo.flags and android.content.pm.ApplicationInfo.FLAG_DEBUGGABLE) != 0
}
}Self-ptrace: a defensive technique
On Linux (Android), a process can only be traced by one debugger at a time. If your app traces itself, no external debugger can attach:
// native/anti_debug.c
// Compiled and loaded via FFI or JNI
#include <sys/ptrace.h>
#include <unistd.h>
// Call this at app startup
int anti_debug_init() {
// Trace ourselves — blocks external debuggers
if (ptrace(PTRACE_TRACEME, 0, NULL, NULL) == -1) {
// Already being traced — a debugger is attached
return -1; // COMPROMISED
}
return 0; // OK
}Layer 5: Runtime integrity verification
Even with all the above protections, an attacker can modify the APK (change code, remove protections), re-sign it, and install the modified version. Runtime integrity verification detects this by checking the app's own binary at runtime.
APK signature verification (Android)
// Verify the APK is signed with YOUR certificate
class IntegrityChecker(private val context: Context) {
// SHA-256 of your release signing certificate
// Get this from: keytool -printcert -jarfile app-release.apk
private val expectedSignature = "A1:B2:C3:D4:..." // your cert fingerprint
fun verifySignature(): Boolean {
return try {
val packageInfo = if (android.os.Build.VERSION.SDK_INT >= 28) {
context.packageManager.getPackageInfo(
context.packageName,
android.content.pm.PackageManager.GET_SIGNING_CERTIFICATES
)
} else {
@Suppress("DEPRECATION")
context.packageManager.getPackageInfo(
context.packageName,
android.content.pm.PackageManager.GET_SIGNATURES
)
}
val signatures = if (android.os.Build.VERSION.SDK_INT >= 28) {
packageInfo.signingInfo.apkContentsSigners
} else {
@Suppress("DEPRECATION")
packageInfo.signatures
}
signatures.any { sig ->
val digest = java.security.MessageDigest.getInstance("SHA-256")
val hash = digest.digest(sig.toByteArray())
val fingerprint = hash.joinToString(":") { "%02X".format(it) }
fingerprint == expectedSignature
}
} catch (e: Exception) {
false
}
}
/// Verify critical native libraries haven't been replaced
fun verifyNativeLibraryIntegrity(): Boolean {
val nativeLibDir = context.applicationInfo.nativeLibraryDir
val libapp = java.io.File("$nativeLibDir/libapp.so")
if (!libapp.exists()) return false
val digest = java.security.MessageDigest.getInstance("SHA-256")
val hash = digest.digest(libapp.readBytes())
val currentHash = hash.joinToString("") { "%02x".format(it) }
// Compare against expected hash (embedded during build)
return currentHash == BuildConfig.LIBAPP_HASH
}
}To embed the hash at build time, add to your Gradle build:
// android/app/build.gradle
android {
defaultConfig {
// Calculate libapp.so hash during build and embed it
buildConfigField "String", "LIBAPP_HASH",
"\"${calculateLibappHash()}\""
}
}
def calculateLibappHash() {
// This runs during build — before the APK is signed
// In practice, use a two-pass build or pre-calculated hash
return "placeholder" // replaced by CI pipeline
}Google Play Integrity API
For a server-verified approach, use the Play Integrity API (Android) or App Attest (iOS). These provide a server-verifiable token that proves:
- The app binary is unmodified (matches the version on the Play Store)
- The device passes basic integrity checks
- The app is running on a genuine Android device
// Dart-side: request an integrity token
class PlayIntegrityService {
static const _channel = MethodChannel('com.yourapp/integrity');
/// Request a Play Integrity token for server-side verification.
/// The server validates this token with Google's API.
static Future<String> getIntegrityToken(String requestHash) async {
final token = await _channel.invokeMethod<String>(
'getIntegrityToken',
{'requestHash': requestHash},
);
return token!;
}
}The server sends the token to Google's API and receives a verdict:
{
"requestDetails": { "requestPackageName": "com.yourapp" },
"appIntegrity": { "appRecognitionVerdict": "PLAY_RECOGNIZED" },
"deviceIntegrity": { "deviceRecognitionVerdict": ["MEETS_DEVICE_INTEGRITY"] },
"accountDetails": { "appLicensingVerdict": "LICENSED" }
}If appRecognitionVerdict is not PLAY_RECOGNIZED, the APK has been modified. If deviceRecognitionVerdict doesn't include MEETS_DEVICE_INTEGRITY, the device may be rooted or emulated.
Layer 6: RASP — Runtime Application Self-Protection
RASP combines all the above layers into a continuous runtime monitoring system. Instead of checking once at startup and trusting the result, RASP continuously monitors for threats throughout the app's lifecycle.
// lib/security/rasp.dart
/// Runtime Application Self-Protection
/// Continuously monitors for security threats and responds.
class RASP {
static const _channel = MethodChannel('com.yourapp/rasp');
Timer? _monitorTimer;
/// Start continuous monitoring
void start({required Function(RaspThreat) onThreat}) {
// Initial check
_performCheck(onThreat);
// Continuous monitoring — check every 30 seconds
_monitorTimer = Timer.periodic(
const Duration(seconds: 30),
(_) => _performCheck(onThreat),
);
}
void stop() {
_monitorTimer?.cancel();
}
Future<void> _performCheck(Function(RaspThreat) onThreat) async {
final results = await _channel.invokeMapMethod<String, bool>('checkAll');
if (results == null) return;
if (results['rooted'] == true) {
onThreat(RaspThreat.rootDetected);
}
if (results['debugger'] == true) {
onThreat(RaspThreat.debuggerAttached);
}
if (results['frida'] == true) {
onThreat(RaspThreat.fridaDetected);
}
if (results['tampered'] == true) {
onThreat(RaspThreat.binaryTampered);
}
if (results['emulator'] == true) {
onThreat(RaspThreat.emulatorDetected);
}
if (results['hookingFramework'] == true) {
onThreat(RaspThreat.hookingFramework);
}
}
}
enum RaspThreat {
rootDetected,
debuggerAttached,
fridaDetected,
binaryTampered,
emulatorDetected,
hookingFramework,
}
/// How the app responds to threats — configurable per client
class RaspPolicy {
static void handle(RaspThreat threat) {
switch (threat) {
case RaspThreat.debuggerAttached:
case RaspThreat.fridaDetected:
// Critical — immediately lock the app
_lockApp('Security violation detected');
_reportToServer(threat);
break;
case RaspThreat.binaryTampered:
// Critical — the app binary has been modified
_lockApp('App integrity check failed');
_reportToServer(threat);
break;
case RaspThreat.rootDetected:
// Warning — allow with reduced functionality
_showWarning(
'This device appears to be rooted. '
'Some security features may be unavailable.',
);
_disableSensitiveFeatures();
_reportToServer(threat);
break;
case RaspThreat.emulatorDetected:
// Depends on context — legitimate for testing
_reportToServer(threat);
break;
case RaspThreat.hookingFramework:
// A hooking framework is loaded — likely an attack
_lockApp('Unauthorized code modification detected');
_reportToServer(threat);
break;
}
}
}The native side of RASP
// android/app/src/main/kotlin/com/yourapp/RaspPlugin.kt
class RaspPlugin : FlutterPlugin, MethodChannel.MethodCallHandler {
private val rootDetector = RootDetector()
private val fridaDetector = FridaDetector()
private val debugDetector = DebugDetector()
private val integrityChecker by lazy { IntegrityChecker(context) }
override fun onMethodCall(call: MethodCall, result: MethodChannel.Result) {
when (call.method) {
"checkAll" -> {
result.success(mapOf(
"rooted" to rootDetector.isRooted(),
"debugger" to debugDetector.isDebuggerAttached(),
"frida" to fridaDetector.isFridaRunning(),
"tampered" to !integrityChecker.verifySignature(),
"emulator" to isEmulator(),
"hookingFramework" to checkForHookingFrameworks(),
))
}
}
}
private fun isEmulator(): Boolean {
return (android.os.Build.FINGERPRINT.startsWith("generic")
|| android.os.Build.FINGERPRINT.startsWith("unknown")
|| android.os.Build.MODEL.contains("google_sdk")
|| android.os.Build.MODEL.contains("Emulator")
|| android.os.Build.MODEL.contains("Android SDK built for x86")
|| android.os.Build.MANUFACTURER.contains("Genymotion")
|| android.os.Build.BRAND.startsWith("generic")
&& android.os.Build.DEVICE.startsWith("generic")
|| android.os.Build.PRODUCT == "google_sdk")
}
private fun checkForHookingFrameworks(): Boolean {
// Check for Xposed
try {
Class.forName("de.robv.android.xposed.XposedBridge")
return true
} catch (e: ClassNotFoundException) { }
// Check for LSPosed, EdXposed
val stackTrace = Thread.currentThread().stackTrace
for (element in stackTrace) {
if (element.className.contains("xposed", ignoreCase = true)
|| element.className.contains("lsposed", ignoreCase = true)) {
return true
}
}
// Check loaded libraries
try {
val mapsFile = java.io.File("/proc/self/maps")
val content = mapsFile.readText()
if (content.contains("xposed") || content.contains("substrate")
|| content.contains("edxposed") || content.contains("lsposed")) {
return true
}
} catch (e: Exception) { }
return false
}
}Commercial RASP solutions
For enterprise clients who need certified protection, commercial RASP providers offer hardened implementations that go beyond what you'd build in-house:
- Guardsquare (DexGuard / iXGuard): Industry standard for Android/iOS. Code hardening, string encryption, RASP, root detection. Used by major banks and payment processors.
- Promon SHIELD: Runtime protection with environment detection. Strong in Nordic banking.
- Zimperium zDefend: ML-based threat detection, device-level protection.
- Talsec freeRASP: Open-source baseline RASP for Flutter. Good starting point; not as hardened as commercial options.
The commercial tools provide:
- Obfuscation that goes beyond symbol renaming (control flow obfuscation, opaque predicates, code virtualization)
- Anti-tamper checks that are deeply integrated into the binary rather than called from a single function
- Detection techniques that are updated as new bypass methods are published
- Certification for compliance frameworks (PCI-DSS, for example, requires code obfuscation)
For a $120k enterprise app, budgeting $5k-$15k annually for a commercial RASP solution is reasonable and expected by clients in regulated industries.
The layered defense model
No single protection is sufficient. The value is in layering:
Layer 6: RASP (continuous runtime monitoring)
↓ detects runtime attacks
Layer 5: Integrity verification (signature + hash checks)
↓ detects binary modification
Layer 4: Frida / debugger detection
↓ detects instrumentation
Layer 3: Root / jailbreak detection
↓ detects hostile environment
Layer 2: String encryption
↓ hides sensitive constants
Layer 1: Dart obfuscation
↓ hides code structure
Layer 0: Server-side validation (the real security)
↓ NEVER trust the clientEach layer defeats a class of attack. An attacker who bypasses root detection still faces Frida detection. An attacker who bypasses Frida detection still faces integrity checks. An attacker who patches the binary to remove all client-side protections still faces server-side validation that doesn't trust anything the client says.
Layer 0 is the most important. Every critical business rule must be enforced server-side. Binary protection raises the cost of client-side attacks, but the server is the actual security boundary.
The honest trade-offs
False positives. Root detection flags some legitimate custom ROMs. Emulator detection flags legitimate test environments. Your RASP policy needs nuance — blocking legitimate users is worse than accepting some risk.
Performance. Continuous RASP checks consume CPU and battery. A 30-second polling interval is a balance between responsiveness and resource usage. Adjust based on your app's sensitivity.
Maintenance. Bypass techniques evolve. Magisk updates its hiding mechanism. Frida adds new injection methods. Your detection code needs updates. Commercial RASP solutions handle this; in-house solutions need ongoing investment.
User experience. Locking the app because it detected root is aggressive. Many power users run rooted devices for legitimate reasons. Consider a graduated response: warn, reduce functionality, then block — rather than immediate termination.
Security theater vs real security. Binary protection without server-side validation is security theater. A perfectly protected client talking to a server that trusts everything is still insecure. Build from the server outward, not from the client inward.
This post complements Secure Enclaves for hardware-backed key protection and Security Audit Artifacts for the MASVS-RESILIENCE compliance requirements that binary protection satisfies.