Introduction to Frida and Non-Rooted Android Penetration Testing

Frida is an invaluable toolkit for dynamic instrumentation of applications, widely utilized in security research, reverse engineering, and penetration testing. It allows security professionals to inject custom scripts into running processes, hook into functions, modify behavior, and inspect memory. While Frida offers immense power, its deployment strategies differ significantly depending on the target environment, particularly whether the Android device is rooted or non-rooted.

On rooted Android devices, the standard approach involves running the `frida-server` binary directly on the device with root privileges. This server then listens for connections from your host machine, allowing you to attach to any process and inject scripts. However, many real-world scenarios involve non-rooted devices, often due to corporate policy, lack of root availability, or a desire to simulate user environments more accurately. In such cases, `frida-server` cannot be run with the necessary permissions, rendering this traditional method ineffective. This is where Frida Gadget becomes the indispensable tool for non-rooted Android app penetration testing.

Frida Server Limitations on Non-Rooted Devices

The primary hurdle for `frida-server` on non-rooted Android devices is its need for elevated privileges. `frida-server` requires permissions to:

• Inject into other processes.
• Access raw memory.
• Bind to privileged ports for communication.

Without root access, these operations are severely restricted by Android’s security model (SELinux, user separation). While it’s theoretically possible to run `frida-server` in a limited capacity by pushing it to a world-executable path and executing it, it won’t be able to attach to arbitrary processes, which is its core functionality. It would only be able to instrument its own process, which isn’t useful for targeting other applications.

Understanding Frida Gadget: The In-Process Solution

Frida Gadget, unlike `frida-server`, is not a standalone executable. Instead, it’s a shared library (.so file) that is loaded directly into the target application’s process. When the application loads the Gadget library, Frida’s instrumentation engine becomes active within that specific process. This ‘in-process’ execution model is the key to its effectiveness on non-rooted devices because it operates within the security context of the target application itself.

Key advantages of Frida Gadget:

• Non-Rooted Compatibility: Operates entirely within the user’s application context, bypassing the need for root privileges.
• Stealth: Can be harder to detect than a running `frida-server` process, as it simply appears as another loaded library.
• Targeted Instrumentation: Specifically instruments the application it’s embedded in, rather than providing system-wide hooking capabilities.

When to Choose Frida Gadget for Injection

Frida Gadget is your go-to solution in the following scenarios:

• Penetration Testing on Non-Rooted Devices: This is its most common and crucial use case.
• Targeting a Specific Application: When you only need to instrument a single application and not the entire system.
• Evading Anti-Frida Measures: Some applications implement checks for the presence of `frida-server` processes or common Frida ports. Gadget can sometimes bypass these.
• Offline Analysis: Gadget can be configured to run a script entirely offline without a host connection, though this is less common for dynamic analysis.

Step-by-Step Guide: Injecting Frida Gadget into an Android APK

Injecting Frida Gadget involves repackaging the target APK with the Gadget library and ensuring the application explicitly loads it. We’ll use apktool for decompilation and recompilation, and apksigner for signing.

Prerequisites:

• Java Development Kit (JDK) installed.
• apktool installed and configured.
• Android SDK Platform-Tools (adb, apksigner) installed.
• Frida tools (frida-tools Python package) installed.

1. Identify Target Architecture and Download Frida Gadget

First, determine the native architectures supported by your target APK. You can do this by inspecting the lib directory inside the APK. Common architectures include armeabi-v7a (arm), arm64-v8a (arm64), x86, and x86_64.

Download the appropriate frida-gadget shared library for your target architecture from the Frida releases page. Look for files named frida-gadget-<version>-android-<arch>.so.xz. Decompress it (e.g., unxz frida-gadget-*.so.xz) and rename it to libfrida-gadget.so.

# Example for arm64-v8a
wget https://github.com/frida/frida/releases/download/16.1.4/frida-gadget-16.1.4-android-arm64.so.xz
unxz frida-gadget-16.1.4-android-arm64.so.xz
mv frida-gadget-16.1.4-android-arm64.so libfrida-gadget.so

2. Decompile the Target APK

Use apktool to decompile the application. This will extract its resources, manifest, and SMALI code into a directory.

apktool d target_app.apk -o target_app_repacked

3. Place the Frida Gadget Library

Navigate into the decompiled application’s directory and create the necessary library path if it doesn’t exist. Then, copy your libfrida-gadget.so into it.

cd target_app_repacked
mkdir -p lib/arm64-v8a  # Adjust architecture as needed
cp /path/to/your/libfrida-gadget.so lib/arm64-v8a/

4. Inject System.loadLibrary() into the Application Entry Point

For Frida Gadget to activate, the application must explicitly load libfrida-gadget.so. The most reliable way is to inject a System.loadLibrary("frida-gadget"); call into the application’s earliest execution path, such as the Application.onCreate() method or the main activity’s onCreate().

First, identify the application’s main entry point:

• Check AndroidManifest.xml for the <application android:name=".MyAppClass"> tag. If present, MyAppClass is your Application class.
• If no custom Application class is specified, find the main Activity (usually marked with <intent-filter><action android:name="android.intent.action.MAIN" /><category android:name="android.intent.category.LAUNCHER" /></intent-filter>).

Let’s assume your Application class is com.example.app.App. Navigate to its SMALI file:

nano smali/com/example/app/App.smali

Find the .method public onCreate()V method. Insert the following SMALI code at the beginning of the method, right after .locals (if any) and before any other instructions, or just before the `return-void` if it’s a simple method:

.method public onCreate()V
    .locals 0 # Or whatever locals count is present

    # Inject Frida Gadget load here
    const-string v0, "frida-gadget"
    invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V

    .line 1234 # Existing line number
    invoke-super {p0}, Landroid/app/Application;->onCreate()V

    # ... rest of the original onCreate method ...

    return-void
.end method

Important: If the original method already uses `v0`, you might need to adjust the register number (`v0` to `v1`, `v2`, etc.) to avoid conflicts, or increment the `.locals` count if you introduce new registers.

5. Recompile the APK

After modifying the SMALI code and placing the Gadget library, recompile the APK using apktool:

apktool b target_app_repacked -o target_app_frida.apk

6. Sign the Repackaged APK

Android requires all APKs to be digitally signed. Use apksigner from the Android SDK Build-Tools. You’ll need a debug keystore; if you don’t have one, `keytool` can create it.

# Create a debug keystore if you don't have one
keytool -genkey -v -keystore debug.keystore -alias androiddebugkey -keyalg RSA -keysize 2048 -validity 10000 -dname "CN=Android Debug,O=Android,C=US"

# Sign the APK
apksigner sign --ks debug.keystore --ks-key-alias androiddebugkey target_app_frida.apk

7. Uninstall Original and Install Repackaged APK

If the original application is installed on your device, uninstall it first to avoid conflicts. Then, install your new Frida-enabled APK.

adb uninstall com.example.app.packagename
adb install target_app_frida.apk

8. Interact with Frida Gadget

By default, Frida Gadget operates in a