Introduction to Android SharedPreferences and Its Vulnerabilities

Android applications frequently utilize SharedPreferences to store small amounts of primitive data, such as user preferences, session tokens, or even sensitive user information. While convenient for developers, this local storage mechanism often falls short in terms of security. Data stored in SharedPreferences is typically saved as XML files in the application’s private data directory (/data/data/<package_name>/shared_prefs/) and is readable by the application itself. However, in a rooted device environment or through improper file permissions, this data can become accessible to other malicious applications or attackers.

This article delves into how security researchers and penetration testers can leverage Frida, a dynamic instrumentation toolkit, to monitor and intercept access to SharedPreferences in real-time. By hooking relevant Android API calls, we can unmask sensitive data being written to or read from these files, even if the application employs basic obfuscation or encryption layers that are handled within the application logic itself.

Setting Up Your Android Reverse Engineering Lab

Before we dive into the Frida magic, ensure your lab environment is properly configured. You’ll need:

• A rooted Android device or an emulator (e.g., AVD, Genymotion)
• Android SDK with ADB installed on your host machine
• Frida client (frida-tools) installed on your host machine (pip install frida-tools)
• Frida server binary compatible with your device’s architecture (e.g., arm64, x86). Download it from Frida’s GitHub releases page.
• A target Android application for testing. For this tutorial, we’ll assume an application that stores a username and an API key in SharedPreferences.

Frida Server Setup:

# Push frida-server to the device
adb push /path/to/frida-server /data/local/tmp/

# Grant executable permissions
adb shell "chmod 755 /data/local/tmp/frida-server"

# Start frida-server in the background
adb shell "/data/local/tmp/frida-server &"

# Forward the Frida server port (default 27042) to your host
adb forward tcp:27042 tcp:27042

Understanding SharedPreferences Interaction in Android

Applications interact with SharedPreferences primarily through two methods:

1. Context.getSharedPreferences(String name, int mode): Used to create or access a specific SharedPreferences file by a given name.
2. PreferenceManager.getDefaultSharedPreferences(Context context): Accesses the default SharedPreferences file for the application package.

Once an SharedPreferences object is obtained, data is read using methods like getString(), getInt(), etc., and written via an Editor object using methods like putString(), putInt(), followed by commit() or apply() to save changes.

Frida Hooking Strategy for SharedPreferences

Our goal is to intercept both read and write operations. We’ll focus on the following key methods:

• android.app.ContextImpl.getSharedPreferences(java.lang.String name, int mode): To identify which preference file is being accessed.
• android.content.SharedPreferences.getString(java.lang.String key, java.lang.String defValue): To log data being read.
• android.content.SharedPreferences$Editor.putString(java.lang.String key, java.lang.String value): To log data being prepared for writing.
• android.content.SharedPreferences$Editor.commit(): To log when changes are committed.
• android.content.SharedPreferences$Editor.apply(): To log when changes are applied asynchronously.

Implementing the Frida Hook Script

Let’s create a Frida script (e.g., frida_prefs_hook.js) to achieve this.

Java.perform(function() {
    console.log("[*] Starting SharedPreferences monitor...");

    // Hooking getSharedPreferences to identify which file is being accessed
    var ContextImpl = Java.use("android.app.ContextImpl");
    ContextImpl.getSharedPreferences.overload('java.lang.String', 'int').implementation = function(name, mode) {
        console.log("[+] getSharedPreferences called for file: " + name);
        return this.getSharedPreferences(name, mode);
    };

    // Hooking PreferenceManager.getDefaultSharedPreferences
    var PreferenceManager = Java.use("android.preference.PreferenceManager");
    PreferenceManager.getDefaultSharedPreferences.overload('android.content.Context').implementation = function(context) {
        console.log("[+] getDefaultSharedPreferences called.");
        return this.getDefaultSharedPreferences(context);
    };

    // Hooking SharedPreferences.getString for read operations
    var SharedPreferences = Java.use("android.content.SharedPreferences");
    SharedPreferences.getString.overload('java.lang.String', 'java.lang.String').implementation = function(key, defValue) {
        var value = this.getString(key, defValue);
        console.log("[READ] SharedPreferences -> Key: " + key + ", Value: " + value + ", Default: " + defValue);
        return value;
    };

    // Hooking SharedPreferences.Editor.putString for write operations
    var Editor = Java.use("android.content.SharedPreferences$Editor");
    Editor.putString.overload('java.lang.String', 'java.lang.String').implementation = function(key, value) {
        console.log("[WRITE] SharedPreferences.Editor -> Key: " + key + ", Value: " + value);
        return this.putString(key, value);
    };

    // Hooking commit() to confirm data persistence
    Editor.commit.overload().implementation = function() {
        console.log("[PERSIST] SharedPreferences.Editor.commit() called. Data saved.");
        return this.commit();
    };

    // Hooking apply() for asynchronous persistence
    Editor.apply.overload().implementation = function() {
        console.log("[PERSIST] SharedPreferences.Editor.apply() called. Data saved asynchronously.");
        return this.apply();
    };

    console.log("[*] SharedPreferences monitor active.");
});

Executing the Attack and Analyzing Output

Now, let’s inject this script into our target application. Replace com.example.targetapp with your application’s package name.

frida -U -l frida_prefs_hook.js --no-pause -f com.example.targetapp

The -f flag spawns the application and immediately attaches Frida. The --no-pause flag ensures the application continues execution after injection. Once Frida is attached, interact with your target application. For instance, log in, change a setting, or trigger any action that involves reading from or writing to SharedPreferences.

You will see output in your terminal similar to this:

[*] Starting SharedPreferences monitor...
[*] SharedPreferences monitor active.
[+] getSharedPreferences called for file: my_app_prefs
[WRITE] SharedPreferences.Editor -> Key: username, Value: testuser
[WRITE] SharedPreferences.Editor -> Key: api_key, Value: aBcDeFg12345hIjKlMnOpQrStUvWxFyZ
[PERSIST] SharedPreferences.Editor.commit() called. Data saved.
[READ] SharedPreferences -> Key: username, Value: testuser, Default: null
[READ] SharedPreferences -> Key: session_token, Value: some_long_session_token_value, Default: null

This output clearly reveals the username and API key being written and subsequently read by the application. Even if the application employs client-side encryption, if the decryption happens before the getString() call or the encryption after the putString() call, Frida will capture the plaintext data because it operates at the API level, after the application’s internal logic has processed the data.

Advanced Considerations and Limitations

While powerful, this technique has some limitations:

• Obfuscation: If the application uses heavy obfuscation (e.g., ProGuard/R8), method names like getString or putString might be renamed. You would need to analyze the decompiled code (e.g., with Jadx or Ghidra) to find the obfuscated method names and adjust your Frida script accordingly.
• Native Code: If an application uses native code (JNI) to interact with SharedPreferences, hooking the Java methods alone might not suffice. You would need to employ native hooking techniques with Frida.
• Custom Storage: Some applications might implement custom data storage mechanisms instead of or in addition to SharedPreferences. In such cases, you’d need to identify and hook those custom methods.

Conclusion

Frida provides an invaluable tool for dynamic analysis of Android applications, allowing penetration testers to bypass client-side controls and gain deep insights into an app’s runtime behavior. By strategically hooking SharedPreferences methods, we can effectively uncover sensitive data that might otherwise be hidden or presumed secure, making it a critical technique in any Android reverse engineering and penetration testing toolkit. This approach empowers testers to validate the actual security posture of data handling within Android applications, moving beyond static analysis limitations.