Dumping Android Application Memory

Android applications store sensitive data in memory during runtime, including plaintext credentials, session tokens, encryption keys, and personal user information. Memory forensics and runtime memory dumping are essential skills for any mobile penetration tester. Whether you are hunting for exposed secrets in a banking app or validating that a healthcare application properly clears sensitive data from memory, understanding how to dump and analyze Android application memory gives you a decisive edge.

This guide walks through the tools, techniques, and commands used by professional pentesters to extract and analyze Android app memory, along with the context you need to interpret what you find.

If your organization needs a thorough Android penetration test performed by expert researchers, Redfox Cybersecurity's mobile pentesting services are purpose-built for exactly this.

Why Android Memory Dumping Matters in Mobile Security

Modern Android apps are expected to handle sensitive data responsibly. Regulations like GDPR, PCI-DSS, and HIPAA require that sensitive data is not retained longer than necessary, including in volatile memory. Yet, in practice, many apps leave credentials, tokens, and PII sitting in heap memory long after they are no longer needed.

Memory dumping lets security professionals answer questions like:

• Does the app store plaintext passwords in memory after login?
• Are cryptographic keys left in memory after a session ends?
• Can authentication tokens be extracted from a running process?
• Is the app vulnerable to a memory scraping attack if the device is compromised?

These are not theoretical concerns. They are findings that appear regularly in real-world mobile application assessments.

Prerequisites and Environment Setup

Before you begin, you need a prepared testing environment. Attempting memory dumps on a stock, unrooted device with a production app will fail at nearly every step due to Android's application sandboxing.

What you need:

• A rooted Android device or an Android emulator (AVD) with root access
• ADB (Android Debug Bridge) installed and configured on your workstation
• Python 3.x installed
• Frida and Fridump installed
• The target APK installed on the device

Setting up ADB:

# Verify ADB detects your device
adb devices

# Enable root access via ADB shell
adb root

# Confirm root shell
adb shell whoami
# Expected output: root


If you are using an Android Virtual Device (AVD) via Android Studio, select a system image without Google Play to get root access by default.

Understanding Android Process Memory Structure

Android runs apps inside isolated Linux processes. Each app has its own virtual address space managed by the Linux kernel. The key memory regions relevant to a pentester are:

• Heap: Where dynamically allocated objects live, including strings, credentials, and session data
• Stack: Function call frames and local variables
• Shared libraries (.so files): Native code loaded at runtime
• /proc/[pid]/maps: A pseudo-file that lists all memory regions of a process

Understanding the /proc/[pid]/maps file is foundational to memory forensics on Android.

# Get the PID of the target app
adb shell ps | grep com.target.app

# Example output:
# u0_a95    12345  678   1234567  89012 S com.target.app

# Read the memory map of the process
adb shell cat /proc/12345/maps


The maps file will output entries like:

7f4a000000-7f4b000000 rw-p 00000000 00:00 0  [heap]
7f5c000000-7f5c001000 r--p 00000000 fd:00 12345  /data/app/com.target.app/lib/arm64/libnative.so


This tells you the start address, end address, permissions, and what occupies each region.

Dumping Memory Using /proc/pid/mem Directly

The most raw method of dumping Android app memory is reading directly from the /proc/[pid]/mem pseudo-file combined with the memory map. This approach works on rooted devices without additional tooling.

Step-by-Step Manual Memory Dump

# Step 1: Get the PID
adb shell
ps | grep com.target.app
# Note the PID, e.g., 12345

# Step 2: Pull the maps file to understand memory regions
cat /proc/12345/maps > /sdcard/app_maps.txt
exit

adb pull /sdcard/app_maps.txt ./app_maps.txt

# Step 3: Write a shell script to dump readable/writable regions
adb shell

for line in $(grep -E "rw-p" /proc/12345/maps | awk '{print $1}'); do
 start=$(echo $line | cut -d'-' -f1)
 end=$(echo $line | cut -d'-' -f2)
 dd if=/proc/12345/mem bs=1 skip=$((16#$start)) count=$(( 16#$end - 16#$start )) >> /sdcard/memdump.bin 2>/dev/null
done

exit

# Step 4: Pull the dump to your workstation
adb pull /sdcard/memdump.bin ./memdump.bin


Once you have the binary dump, you can search it for strings:

strings memdump.bin | grep -iE "password|token|secret|key|auth|session"


This simple grep pass often surfaces credentials that developers assumed were safely hidden.

Using Fridump for Automated Memory Dumping

Fridump is an open-source memory dumping tool built on top of Frida. It automates the process of identifying readable memory segments and extracting them, making it significantly faster than manual methods.

Installing Frida and Fridump

# Install Frida tools on your workstation
pip3 install frida-tools

# Download Frida server for your device's architecture
# Check architecture first
adb shell getprop ro.product.cpu.abi
# e.g., arm64-v8a

# Download matching frida-server from https://github.com/frida/frida/releases
# Then push it to the device
adb push frida-server-16.x.x-android-arm64 /data/local/tmp/frida-server
adb shell chmod 755 /data/local/tmp/frida-server

# Start the Frida server on the device
adb shell "/data/local/tmp/frida-server &"

# Verify Frida can see running processes
frida-ps -U | grep com.target.app


Running Fridump

# Clone Fridump
git clone https://github.com/Nightbringer21/fridump.git
cd fridump

# Basic memory dump of the target app
python3 fridump.py -u com.target.app

# Dump with string extraction enabled
python3 fridump.py -u com.target.app -s

# Dump to a specific output directory
python3 fridump.py -u com.target.app -s -o /tmp/target_dump/


Fridump will create a directory with all dumped memory segments as individual .data files. The -s flag automatically runs the strings utility against each segment.

Searching Dumped Segments

# Search all dumped segments for sensitive keywords
grep -ria "password" /tmp/target_dump/
grep -ria "Bearer " /tmp/target_dump/
grep -ria "eyJ" /tmp/target_dump/   # JWT token prefix (base64 of {"alg"...})

# Use a broader regex to catch encoded tokens
grep -riaE "[A-Za-z0-9+/]{40,}={0,2}" /tmp/target_dump/ | head -50


Finding a raw JWT, an API key, or a hardcoded password in these dumps is a critical severity finding in any mobile pentest report.

For organizations that want these tests conducted systematically and reported with actionable remediation steps, Redfox Cybersecurity's application security services cover Android memory analysis as part of a comprehensive mobile pentest engagement.

Runtime Memory Inspection with Frida Scripts

Beyond bulk dumping, Frida lets you hook into specific functions and inspect memory at the exact moment sensitive data is processed. This is particularly useful when credentials only exist in memory for a brief window.

Hooking String Constructors to Catch Credentials

// frida_hook_strings.js
Java.perform(function () {
   var String = Java.use("java.lang.String");

   String.$init.overload("[B").implementation = function (bytes) {
       var result = this.$init(bytes);
       var str = Java.use("java.lang.String").$new(bytes);
       if (str.length() > 5 && str.length() < 200) {
           console.log("[String] " + str);
       }
       return result;
   };
});


Run it with:

frida -U -l frida_hook_strings.js com.target.app


Dumping SharedPreferences at Runtime

Many Android apps store tokens in SharedPreferences. You can read them live via Frida:

// frida_sharedprefs.js
Java.perform(function () {
   var ActivityThread = Java.use("android.app.ActivityThread");
   var context = ActivityThread.currentApplication().getApplicationContext();
   var prefs = context.getSharedPreferences("user_prefs", 0);
   var all = prefs.getAll();
   var keys = all.keySet().toArray();
   for (var i = 0; i < keys.length; i++) {
       console.log(keys[i] + ": " + all.get(keys[i]));
   }
});
frida -U -l frida_sharedprefs.js com.target.app


This frequently surfaces session tokens, user IDs, and authentication flags that developers stored without encryption.

Analyzing Heap Dumps with JADX and Bytecode Inspection

If Frida is not available or the app detects instrumentation and crashes, heap dumps captured via Android Studio's profiler or the am dumpheap command can be parsed offline.

Capturing a Heap Dump via ADB

# Dump the heap of the target process
adb shell am dumpheap com.target.app /sdcard/heap_dump.hprof

# Pull it to your workstation
adb pull /sdcard/heap_dump.hprof ./heap_dump.hprof

# Convert to standard HPROF format if needed (for Android < 14)
hprof-conv heap_dump.hprof converted_heap_dump.hprof


Open the converted file in Android Studio's Memory Profiler, or use the open-source tool Eclipse Memory Analyzer (MAT) to browse object instances, inspect string values, and find retained memory that should have been cleared.

# Use MAT from command line to export all String instances
./ParseHeapDump.sh converted_heap_dump.hprof org.eclipse.mat.api:suspects


Bypassing Anti-Tamper and Root Detection

Many production applications implement root detection and anti-Frida checks. Bypassing these is a necessary step in a real-world pentest.

Bypassing Root Detection with Frida

// bypass_root.js
Java.perform(function () {
   var RootBeer = Java.use("com.scottyab.rootbeer.RootBeer");
   RootBeer.isRooted.implementation = function () {
       console.log("[*] isRooted called, returning false");
       return false;
   };
});
frida -U -l bypass_root.js com.target.app


For apps using native root checks, you may need to hook at the native layer using Interceptor.attach targeting the relevant .so file exports.

Bypassing Frida Detection

Some apps scan for Frida's presence by checking for known port numbers or library names. A common bypass:

# Launch Frida server on a non-default port
adb shell "/data/local/tmp/frida-server -l 0.0.0.0:27043 &"

# Connect Frida tools to the custom port
frida -H 127.0.0.1:27043 -l script.js com.target.app


For persistent evasion, gadget injection (embedding frida-gadget.so directly into the APK and repacking it) is the most reliable approach against detection-heavy applications.

What to Look for in Extracted Memory

Once you have a raw memory dump or Frida output, the following patterns are high-value findings in a pentest context:

• JWT tokens: Start with eyJ (base64-encoded {")
• Bearer tokens: Look for Authorization: Bearer strings
• Private keys: -----BEGIN RSA PRIVATE KEY----- or -----BEGIN EC PRIVATE KEY-----
• Database connection strings: jdbc:, mongodb://, postgresql://
• Hardcoded API keys: Match patterns for known providers (e.g., AIza for Google APIs, sk- for OpenAI)
• Plaintext credentials: password=, passwd=, pwd=, secret=

# Comprehensive grep across all dump files
grep -riaE "(password|passwd|secret|token|key|auth|credential|bearer)[=: ]['\"]?[A-Za-z0-9+/._-]{6,}" /tmp/target_dump/


Document every finding with the memory region it came from, the process PID, and the timestamp of extraction. This constitutes the evidence chain for your pentest report.

Remediation Guidance for Developers

Understanding these attack techniques informs better secure development practices. Developers should:

• Use char[] arrays for sensitive strings instead of String objects, since char[] can be explicitly zeroed after use while Java String objects are immutable and persist in memory until GC
• Use Android's EncryptedSharedPreferences from the Jetpack Security library instead of plain SharedPreferences
• Clear sensitive data from memory immediately after use using Arrays.fill(sensitiveArray, (char) 0)
• Avoid logging sensitive data even in debug builds
• Use the Android Keystore System for cryptographic key storage to prevent key material from being extracted into app process memory

Closing Thoughts

Android memory dumping sits at the intersection of mobile security, Linux internals, and reverse engineering. Mastering it requires hands-on practice with real tools and real applications. The commands and techniques covered in this guide, from raw /proc/mem reads to Frida-powered runtime hooks and heap analysis, represent the core toolkit that professional mobile pentesters rely on during engagements.

Memory vulnerabilities are among the most commonly overlooked findings in mobile application security reviews, partly because they require runtime analysis rather than static code review alone. Many organizations release apps that pass static analysis but leak credentials the moment a pentester attaches a debugger.

If you want to know exactly what an attacker would find in your Android application's memory, the security researchers at Redfox Cybersecurity conduct thorough, methodology-driven mobile application penetration tests that include runtime memory analysis, reverse engineering, and full attack chain simulation. Their team goes beyond automated scanning to manually identify the vulnerabilities that tools miss.

Get in touch with Redfox Cybersecurity to discuss a mobile application security assessment tailored to your environment, whether you need a black-box test of a published app or a white-box review with source code access.