Introduction to Android Root Detection

Android’s open-source nature provides unparalleled flexibility, but for sensitive applications like banking, this openness poses significant security challenges. Rooting an Android device grants superuser privileges, allowing users to modify system files, install custom ROMs, and even inject code into running processes. While beneficial for power users, these capabilities can be exploited by malicious actors to bypass security controls, steal data, or manipulate app behavior. Consequently, banking applications universally implement robust root detection mechanisms to protect user data and ensure regulatory compliance. While common root checks are often mitigated by tools like Magisk, custom implementations require a deeper dive into reverse engineering.

Why Banking Apps Implement Root Checks

• Data Integrity: Rooted devices can allow malware to access or tamper with sensitive application data stored on the device.
• Bypass Security Controls: Root access enables circumvention of Android’s sandboxing, allowing one app to interfere with another, or bypass screenshot restrictions.
• Malware Injection: Malicious code can be injected into legitimate app processes, modifying their behavior or exfiltrating data.
• Regulatory Compliance: Financial institutions are often mandated to ensure a secure operating environment for their applications, making root detection a critical component.

Common Root Detection Techniques

Before diving into custom methods, it’s crucial to understand the standard approaches apps use:

1. Checking for su Binary: The presence of the su (superuser) binary in common system paths (e.g., /system/bin/su, /system/xbin/su) is a primary indicator.
2. Checking for Specific Files/Folders: Looking for files like /system/app/Superuser.apk, /data/local/tmp/busybox, or folders created by rooting tools.
3. Reading Build Tags: Inspecting Build.TAGS for test-keys, which often indicate a custom, non-official ROM.
4. Package Name Checks: Searching for packages associated with rooting (e.g., com.noshufou.android.su, eu.chainfire.supersu).
5. SafetyNet Attestation: Google’s API to verify device integrity, checking for root, unlocked bootloader, and other security compromises.
6. Dangerous Properties: Examining system properties like ro.debuggable or ro.secure.

Reverse Engineering Custom Root Checks

Custom root checks go beyond these common patterns, often involving unique file path checks, specific library calls, or obfuscated logic. Our goal is to locate and understand these bespoke implementations.

Step 1: Obtain and Decompile the APK

First, get the APK file of the target banking application. You can extract it from your device or download it from various repositories. Then, decompile it using tools like JADX-GUI or Apktool.

# Using Apktool to disassemble resources and bytecode Ap ktool d your_banking_app.apk -o your_banking_app_decompiled

For Java source code, JADX-GUI is often more convenient for initial analysis:

# Simply drag and drop the APK into JADX-GUI

Step 2: Keyword Searching and Initial Code Analysis

Once decompiled, start searching for keywords that might indicate root detection. Common terms include:

• root
• su
• superuser
• jailbreak
• checkRoot
• isRooted
• magisk
• frida (sometimes apps try to detect instrumentation)
• File paths like /system/bin/su, /data/local/tmp, etc.

Use JADX’s search functionality or grep the decompiled Smali/Java files. Pay close attention to classes and methods containing these keywords, especially those returning a boolean or throwing an exception related to device security.

# Example grep command for Smali files grep -r "/system/bin/su" your_banking_app_decompiled/smali/

Step 3: Analyzing Root Detection Logic (Example Scenario)

Let’s assume our search leads us to a method like com.example.banking.security.RootDetector.isDeviceCompromised(). Inside, we might find custom logic, perhaps checking for a specific file that isn’t commonly associated with root, or executing a native library call.

// Pseudocode representation of a custom Java root check public class RootDetector { private static final String CUSTOM_ROOT_INDICATOR_FILE = "/data/local/secret_root_file"; public static boolean isDeviceCompromised() { try { // Check for common root binaries if (new File("/system/bin/su").exists() || new File("/system/xbin/su").exists()) { return true; } // Custom check for a specific file if (new File(CUSTOM_ROOT_INDICATOR_FILE).exists()) { return true; } // Call to a native method for more advanced checks if (checkNativeRootStatus()) { return true; } } catch (Exception e) { // Log exception } return false; } private static native boolean checkNativeRootStatus(); }

Bypassing Custom Root Checks

Once identified, custom root checks can be bypassed using dynamic instrumentation (Frida) or static patching (Smali modification).

Method 1: Dynamic Instrumentation with Frida

Frida allows you to inject JavaScript code into running processes to hook functions, modify arguments, and change return values on the fly. This is ideal for quick testing and when static patching is too complex or time-consuming.

Frida Setup

1. Install Frida on your host machine: pip install frida-tools
2. Download the Frida server for your device’s architecture (e.g., frida-server-16.x.x-android-arm64) from Frida GitHub releases.
3. Push the server to your Android device and run it as root:

   adb push frida-server /data/local/tmp/ adb shell "chmod 755 /data/local/tmp/frida-server" adb shell "/data/local/tmp/frida-server &"

Frida Script for Bypassing our Example

Let’s bypass com.example.banking.security.RootDetector.isDeviceCompromised() by forcing its return value to false.

Java.perform(function() { var RootDetector = Java.use('com.example.banking.security.RootDetector'); RootDetector.isDeviceCompromised.implementation = function() { console.log('Hooked isDeviceCompromised and returning false!'); return false; }; console.log('RootDetector.isDeviceCompromised hook applied!'); // If there's a native method, we might need to hook that too // var nativeClass = Java.use('com.example.banking.security.NativeRootCheck'); // nativeClass.checkNativeRootStatus.implementation = function() { // console.log('Hooked checkNativeRootStatus and returning false!'); // return false; // }; });

Run this script with Frida:

frida -U -f com.example.banking.appname -l bypass_root.js --no-pause

-U targets the USB device, -f spawns the app, -l loads the script, and --no-pause starts the app immediately.

Method 2: Static Patching (Smali Modification)

For a permanent bypass or when Frida isn’t an option, modify the Smali code directly. This involves changing the bytecode to alter the app’s logic. After decompiling with Apktool, navigate to the relevant Smali file (e.g., com/example/banking/security/RootDetector.smali).

Locate the isDeviceCompromised method:

.method public static isDeviceCompromised()Z .locals 2 .prologue .line 10 // Original check for /system/bin/su ... .line 20 // Original check for /data/local/secret_root_file ... .line 30 // Original call to native method ... .line 40 // If all checks pass, returns true .const/4 v0, 0x1 .goto :root_detected :not_rooted .const/4 v0, 0x0 :root_detected .return v0 .end method

To bypass it, we simply force it to return false immediately. Replace the method’s content with:

.method public static isDeviceCompromised()Z .locals 1 .prologue .line 10 .const/4 v0, 0x0 .return v0 .end method

This snippet loads the integer 0 (representing false in boolean context) into register v0 and returns it, effectively bypassing all original checks.

Rebuild and Sign

After modifying the Smali file, rebuild the APK and sign it:

# Rebuild the APK apktool b your_banking_app_decompiled -o your_banking_app_patched.apk # Generate a debug keytool -genkey -v -keystore debug.keystore -alias androiddebugkey -keyalg RSA -keysize 2048 -validity 10000 # Sign the APK apksigner sign --ks debug.keystore --ks-key-alias androiddebugkey your_banking_app_patched.apk # Verify the signature apksigner verify your_banking_app_patched.apk

Finally, uninstall the original app and install the patched version:

adb uninstall com.example.banking.appname adb install your_banking_app_patched.apk

Conclusion

Bypassing custom root checks in Android banking applications requires a methodical approach, combining reverse engineering techniques with dynamic or static patching. While challenging, understanding the underlying mechanisms of these checks is crucial for both security researchers aiming to test application robustness and developers seeking to enhance their security posture. Always ensure you have legal authorization before performing such actions on applications you do not own or have permission to test.