Introduction to Memory Dumping in Android Applications

Android application reverse engineering often involves peering into the app’s runtime state. While static analysis provides valuable insights into an application’s structure and potential vulnerabilities, dynamic analysis, specifically memory dumping, allows reverse engineers to extract crucial data such as cryptographic keys, user credentials, and sensitive application logic that might only exist transiently in memory. Frida, a dynamic instrumentation toolkit, combined with an understanding of the Android Runtime (ART), provides unparalleled capabilities for this task.

ART, the default runtime for Android since Lollipop, compiles application bytecode (DEX) into machine code. This compilation means that Java objects and their underlying data structures are managed by ART’s memory allocator and garbage collector, ultimately residing in native memory. For reverse engineers, this implies that both the high-level Java object model and the low-level native memory representation must be understood to effectively extract information.

Setting Up Your Environment (Prerequisites)

Before diving into memory dumping, ensure you have a working Frida setup. This typically involves:

• A rooted Android device or emulator.
• adb installed and configured on your host machine.
• Frida client (frida-tools) installed on your host (pip install frida-tools).
• Frida server running on your Android device, matching its architecture (e.g., frida-server-16.1.4-android-arm64).

Once Frida server is running (e.g., adb shell /data/local/tmp/frida-server & and port forwarding adb forward tcp:27042 tcp:27042), you’re ready to inject scripts.

Dumping Java Objects with Frida

Understanding Java Object Representation in ART

In ART, every Java object is a region of native memory. Frida’s Java API provides a powerful abstraction layer to interact with these objects directly. When you obtain a reference to a Java object using Java.use(), Java.choose(), or by hooking a method, Frida internally handles the complexities of ART’s object model, allowing you to access fields, invoke methods, and even inspect the object’s memory address.

Locating and Interacting with Java Objects

A common scenario is to dump the contents of a specific Java object instance. Let’s imagine an application stores a sensitive configuration or a decrypted key in an instance of com.example.app.SecureConfig. We can hook the constructor of this class to get a reference to an active instance and then dump its fields.

Consider a simplified SecureConfig class:

package com.example.app;public class SecureConfig {    private String apiKey;    private byte[] secretBlob;    private int configVersion;    public SecureConfig(String key, byte[] blob, int version) {        this.apiKey = key;        this.secretBlob = blob;        this.configVersion = version;    }    // ... other methods ...}

Here’s a Frida script to dump its contents:

Java.perform(function() {    const SecureConfig = Java.use('com.example.app.SecureConfig');    SecureConfig.$init.overload('java.lang.String', '[B', 'int').implementation = function(key, blob, version) {        console.log('SecureConfig constructor called!');        console.log('  apiKey: ' + key);        console.log('  configVersion: ' + version);        if (blob) {            console.log('  secretBlob length: ' + blob.length);            // Convert byte array to hex string for display            let hexBlob = '';            for (let i = 0; i < blob.length; i++) {                hexBlob += ('0' + (blob[i] & 0xFF).toString(16)).slice(-2);            }            console.log('  secretBlob (hex): ' + hexBlob);        }        this.$init(key, blob, version); // Call original constructor    };    // Alternatively, to find existing instances (less precise without proper hooks)    // Java.choose('com.example.app.SecureConfig', {    //     onMatch: function(instance) {    //         console.log('Found existing SecureConfig instance at ' + instance.toString());    //         console.log('  apiKey: ' + instance.apiKey.value); // Accessing fields    //         // ... dump other fields as above ...    //     },    //     onComplete: function() {    //         console.log('SecureConfig search complete!');    //     }    // });});

To run this, save it as `dump_java.js` and inject it:

frida -U -f com.example.app --no-pause -l dump_java.js

Dumping Native Structures and Memory

Native Memory Layout in Android Applications

Android applications extensively use native libraries (.so files) for performance-critical operations, cryptographic routines, or integration with system services. These libraries manage their own memory, often storing sensitive data in custom C/C++ structs. To dump these, we need to understand the application’s memory map, which can be viewed via /proc//maps on the device.

Frida’s Module and Memory APIs are indispensable for native memory operations. Module.findBaseAddress() helps locate the base address of a loaded library, and Memory.readByteArray(), Memory.readPointer(), and Memory.readUtf8String() allow reading raw bytes, pointers, and strings respectively from specified memory addresses.

Identifying Target Native Structures

Identifying native structures usually involves prior static analysis using tools like Ghidra or IDA Pro. You’d look for custom structures passed as arguments to functions, or global variables, especially in libraries dealing with cryptography or sensitive data handling. For example, a `struct CryptoContext` might contain an encryption key and an IV (Initialization Vector).

Let’s assume static analysis reveals that libnativecrypt.so has an exported function get_crypto_context() which returns a pointer to a struct CryptoContext defined as:

typedef struct {    char key[32];      // 256-bit key    char iv[16];       // 128-bit IV    uint32_t algorithm_id;} CryptoContext;

Reading Native Memory with Frida

We can hook get_crypto_context to obtain the pointer and then read the memory block corresponding to the CryptoContext structure.

Java.perform(function() {    const libNativeCrypt = Module.findBaseAddress('libnativecrypt.so');    if (libNativeCrypt) {        console.log('Found libnativecrypt.so at: ' + libNativeCrypt);        // Assuming get_crypto_context is at a known offset (e.g., 0x1234) or exported        // For exported function: Module.findExportByName(null, 'get_crypto_context');        // Let's assume an offset for this example        const getCryptoContextPtr = libNativeCrypt.add(0x1234); // Replace 0x1234 with actual offset        console.log('Hooking get_crypto_context at: ' + getCryptoContextPtr);        Interceptor.attach(getCryptoContextPtr, {            onLeave: function(retval) {                console.log('get_crypto_context returned: ' + retval);                if (retval.isNull()) {                    console.warn('CryptoContext pointer is null!');                    return;                }                const cryptoContextAddr = retval;                console.log('Dumping CryptoContext at: ' + cryptoContextAddr);                // Read the key (32 bytes)                const keyBytes = Memory.readByteArray(cryptoContextAddr, 32);                console.log('  Key (hex): ' + hexdump(keyBytes, { ansi: false }));                // Read the IV (16 bytes) - offset + 32                const ivBytes = Memory.readByteArray(cryptoContextAddr.add(32), 16);                console.log('  IV (hex): ' + hexdump(ivBytes, { ansi: false }));                // Read the algorithm_id (4 bytes) - offset + 32 + 16                const algorithmId = Memory.readU32(cryptoContextAddr.add(32 + 16));                console.log('  Algorithm ID: ' + algorithmId);            }        });    } else {        console.log('libnativecrypt.so not found.');    }});

Inject this script similarly:

frida -U -f com.example.app --no-pause -l dump_native.js

Practical Scenarios and Advanced Tips

The real power emerges when combining Java and native memory dumping. For instance, you might retrieve a Java object that internally holds a pointer to a native structure. You can use Java.cast(javaObject, nativePointerClass).nativePointer.readPointer() to extract the native address, then use Frida’s native memory APIs to inspect it.

When dealing with obfuscation, class names, method names, and even string literals might be mangled. This necessitates more robust hooking strategies, such as hooking common Android framework APIs that process sensitive data (e.g., javax.crypto.Cipher methods or JNI calls like GetStringUTFChars) to intercept data before or after obfuscation/encryption.

For continuous monitoring or larger memory regions, consider writing data to a file on the device or host using send() and a Python handler script. This can be critical for forensic analysis of an app’s runtime state over time.

Conclusion

Frida is an indispensable tool for Android app reverse engineers, providing deep insights into both the Java and native layers of an application’s memory. By understanding how ART manages Java objects and how native libraries interact with memory, you can leverage Frida’s powerful APIs to dump sensitive data structures, cryptographic keys, and other critical information that might otherwise remain hidden. Mastering these memory dumping techniques is a crucial step towards comprehensive Android application security analysis and exploitation.