Memory analysis is one of the most revealing techniques in mobile application security testing, often exposing secrets that never should have left the server in the first place. Hardcoded API keys, decrypted session tokens, plaintext credentials, and encryption keys frequently sit in an app's memory space even when the app appears secure on the surface. This guide walks through how to properly dump and analyze Android application memory during an authorized security assessment, using the tools professional mobile testers actually rely on. This is exactly the kind of analysis the mobile application security team at Sagefox Cybersecurity performs as part of comprehensive app assessments.
Why Memory Analysis Matters in Android App Security Testing
Static analysis of an APK only shows part of the picture. Obfuscation, string encryption, and packing can hide sensitive data from a decompiled source review while that same data sits fully decrypted in memory the moment the app actually runs. Memory dumping bridges that gap by capturing the application's runtime state, revealing exactly what data exists in cleartext during normal operation.
What Memory Dumps Commonly Reveal
- Decrypted API keys and authentication tokens that were encrypted at rest but decrypted for use
- Session identifiers and cookies that persist longer than intended
- Cryptographic keys used for local data encryption
- Cleartext credentials briefly held in memory during login flows
- Sensitive business logic or internal API structures not visible in the compiled bytecode
Setting Up an Android Testing Environment
Choosing Between a Rooted Device and an Emulator
Memory dumping requires elevated privileges on the device, which means either a rooted physical device or a rooted emulator image. Emulators offer easier snapshot and rollback capabilities, while physical devices provide more accurate real-world behavior, particularly for apps that detect emulation and alter their behavior accordingly.
avdmanager create avd -n pentest_avd -k "system-images;android-33;google_apis;x86_64"
emulator -avd pentest_avd -writable-system
Rooting the Emulator Image for Full Access
Standard emulator images ship with a read-only system partition. Remounting it as writable is required before installing testing frameworks that need system-level access.
adb root
adb remount
adb shell setenforce 0
[cta]
Installing and Configuring Frida for Memory Access
Why Frida Is the Standard Tool for This Work
Frida remains the dominant dynamic instrumentation framework for mobile security testing because it allows hooking into running processes, intercepting function calls, and accessing live memory without needing to modify the application's binary on disk.
Installing the Frida Server on the Device
Download the Frida server binary matching your device's architecture and push it to the device.
adb push frida-server-16.1.4-android-x86_64 /data/local/tmp/frida-server
adb shell "chmod 755 /data/local/tmp/frida-server"
adb shell "/data/local/tmp/frida-server &"
Confirm the server is running and reachable from your host machine:
frida-ps -U
[cta]
Installing the Frida Python Bindings on Your Host
pip install frida-tools
Confirm the target application is visible in the running process list before attempting to attach:
frida-ps -U | grep com.target.app
Dumping Application Memory with Fridump
Running Fridump Against a Live Process
Fridump is a memory dumping tool built specifically on top of Frida, designed to extract the full memory space of a running application for offline analysis.
python3 fridump.py -U com.target.app -o dump_output/
This attaches to the running application, enumerates all readable memory regions, and writes them to disk as individual binary files for further analysis.
[cta]
Searching Dumped Memory for Sensitive Strings
Once memory has been extracted, string searching across the dump directory is the fastest way to identify readable secrets.
grep -r -a -E "(api[_-]?key|token|password|secret)" dump_output/ | head -50
For more targeted searches, such as looking specifically for JWT tokens, a regex tuned to JWT structure catches tokens that generic keyword searches might miss:
grep -r -a -E "eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+" dump_output/
Using Objection for Interactive Memory Exploration
Why Objection Complements Fridump
Objection wraps Frida into an interactive runtime exploration shell, making it easier to explore an application's memory, hook specific methods, and bypass common protections like SSL pinning and root detection while conducting memory analysis in real time rather than working purely from static dumps.
Attaching Objection to a Running Application
objection -g com.target.app explore
Once attached, memory search can be performed directly within the interactive session:
memory search "sk_live_" --string
This example searches live memory for a common Stripe API key prefix pattern, a useful check for confirming whether production payment keys have leaked into a client-side application.
[cta]
Dumping Heap Objects for Deeper Java-Level Analysis
Objection also supports dumping live Java heap objects, which is useful when the sensitive data of interest exists as structured object fields rather than raw strings.
android heap search instances "com.target.app.models.UserSession"
This returns live instances of the specified class currently held in memory, along with their field values, often revealing session tokens or user data structured exactly as the application code defines them.
Bypassing Common Protections Before Memory Analysis
Dealing with SSL Pinning During Testing
Many applications implement certificate pinning specifically to prevent traffic interception during testing, which is separate from memory protection but often needs to be disabled first to fully understand what data an app is handling before it reaches memory.
objection -g com.target.app explore --startup-command "android sslpinning disable"
Bypassing Root Detection
Applications with root detection may refuse to run, alter their behavior, or clear sensitive memory regions specifically when they detect a rooted environment, which complicates memory analysis if not addressed first.
objection -g com.target.app explore --startup-command "android root disable"
[cta]
Analyzing Native Memory in Apps Using JNI and Native Libraries
Why Native Code Requires a Different Approach
Applications that implement sensitive logic in native C or C++ libraries through JNI store data in native memory regions that standard Java-level tooling does not always capture cleanly. Frida's ability to hook native functions directly becomes necessary here.
frida-trace -U -i "encrypt*" com.target.app
This traces all functions matching the pattern "encrypt" within the native library, revealing when and how encryption routines are called along with the arguments passed to them, which often includes the plaintext data immediately before encryption occurs.
Writing a Custom Frida Script to Hook Native Functions
For more precise control, a custom Frida script can hook a specific native function and log its arguments directly.
Interceptor.attach(Module.findExportByName("libnative.so", "encryptData"), {
onEnter: function(args) {
console.log("Plaintext input: " + Memory.readUtf8String(args[0]));
}
});
Running this script against the target process captures plaintext data at the exact moment it is passed into the native encryption function, before it becomes unreadable ciphertext.
[cta]
Documenting and Reporting Memory Analysis Findings
Demonstrating Impact Rather Than Just Extraction
A memory dump alone is not a finding a development team can act on effectively. The report needs to clearly show what specific sensitive data was recovered, under what conditions, and what realistic scenario would allow an attacker to access that same memory space, such as a rooted device in the hands of a malicious app or a compromised device in an enterprise environment.
Recommending Concrete Remediation
Findings from memory analysis typically map to a few common remediation categories:
- Avoid holding decrypted secrets in memory longer than strictly necessary, clearing sensitive variables immediately after use
- Use Android's hardware-backed Keystore for cryptographic operations rather than handling raw keys in application memory
- Implement additional anti-tampering and root detection specifically to raise the difficulty of memory-based attacks, understanding these are speed bumps rather than complete solutions
- Avoid embedding production credentials or API keys in client-side code entirely, regardless of encryption, since anything shipped to a device can eventually be extracted
This is the kind of structured, remediation-focused reporting that assessments from Sagefox Cybersecurity are built around, ensuring development teams walk away with fixes they can actually implement rather than a raw technical dump of findings.
Common Mistakes During Android Memory Analysis
Testing Against Debug Builds Instead of Production Builds
Debug builds often behave differently from production releases, sometimes including additional logging or lacking obfuscation entirely. Findings from a debug build do not always reflect what an attacker would actually find in the version of the app running on real user devices.
Skipping Anti-Tampering Bypass Before Testing
Attempting memory analysis against an application with active root detection or SSL pinning still enabled often produces incomplete or misleading results, since the application may be deliberately altering its behavior in response to the detected testing environment.
Failing to Test Across App States
Sensitive data often only appears in memory during specific application states, such as immediately after login or during an active payment flow. A single memory dump taken while the app sits idle at a home screen will miss data that only exists transiently during specific user actions.
Key Takeaways
Memory analysis remains one of the most effective techniques for uncovering what an Android application actually does with sensitive data at runtime, regardless of how well it appears protected through static obfuscation. Frida, Fridump, and Objection together form a reliable toolchain for extracting and analyzing that memory during an authorized assessment, but the real value comes from connecting what gets found to concrete, actionable remediation for the development team.
If your organization needs a thorough mobile application security assessment that goes beyond static code review into real runtime behavior, the team at Sagefox Cybersecurity can help identify what your app is actually exposing and how to fix it.
