Introduction to Android Memory Forensics

In the evolving landscape of mobile threats, traditional file-system and network-based analysis often fall short in detecting sophisticated Android malware. Many advanced persistent threats (APTs) and evasive malware variants reside solely in memory, never touching the disk or employing rootkit-like techniques to hide their presence. Live memory forensics provides a powerful methodology to uncover these hidden artifacts, offering a snapshot of the operating system’s state, running processes, loaded modules, network connections, and open files at a specific moment. This deep dive into a device’s RAM allows investigators to bypass file system obfuscation, decrypt in-memory data, and reconstruct the execution flow of malicious applications, making it an indispensable tool for thorough malware investigations on rooted Android devices.

Prerequisites for Memory Acquisition & Analysis

Before embarking on live memory forensics, ensure you have the following:

• Rooted Android Device: Full root access is critical to access kernel memory devices like /dev/mem or /proc/kcore.
• ADB (Android Debug Bridge): Installed and configured on your host machine for communication with the Android device.
• Linux Host Machine: A Linux environment is recommended for running Volatility Framework and processing memory dumps.
• Volatility Framework: The leading open-source memory forensics framework.
• Appropriate Kernel Headers/Source: Essential for creating a custom Volatility profile for your specific Android device’s kernel.
• Storage: Sufficient space on both the Android device (for the temporary dump) and the host machine.

Live Memory Acquisition from a Rooted Android Device

Acquiring a live memory dump from a running Android device is the foundational step. The most common method involves using the dd utility to copy the contents of kernel memory devices.

Method 1: Using /dev/mem or /proc/kcore

/dev/mem represents the physical memory of the system, while /proc/kcore is a virtual file that maps the physical memory into the process’s address space. While /dev/mem is more direct, /proc/kcore is often more accessible and reliable on various Android kernels for a full memory dump. We will use /proc/kcore as it generally provides a more complete view of kernel and user memory.

Steps for Acquisition:

1. Connect the Device: Connect your rooted Android device to your host machine via USB and ensure ADB debugging is enabled.

   adb devices

   You should see your device listed, e.g.:

   List of devices attachedcd0a174c device

2. Gain Root Shell: Obtain a root shell on the device.

   adb shellsu

   Confirm the prompt changes to #, indicating root access.

3. Perform Memory Dump: Use dd to copy the memory to an accessible location, such as /data/local/tmp or /sdcard (if it’s not a restricted path). Note that /data/local/tmp is generally safer as /sdcard might be emulated or restricted.

   dd if=/proc/kcore of=/data/local/tmp/android_memdump.raw bs=1M

   This command instructs dd to read from /proc/kcore and write to android_memdump.raw, using a block size of 1MB for efficiency. This process can take a significant amount of time, depending on the device’s RAM size (e.g., 2GB, 4GB, or more).

4. Verify Dump Size: Once completed, check the size of the generated dump file.

   ls -lh /data/local/tmp/android_memdump.raw

   The file size should roughly correspond to the total RAM of the device plus some overhead (for /proc/kcore, it’s often significantly larger as it includes kernel mappings, but Volatility will parse the relevant parts).

5. Pull Dump to Host: Transfer the memory dump from the Android device to your Linux host machine.

   adb pull /data/local/tmp/android_memdump.raw ~/android_forensics/

   Replace ~/android_forensics/ with your desired directory on the host.

Method 2 (Advanced): Using a Loadable Kernel Module (LKM) like LiME

For more robust and stealthy acquisition, or when /dev/mem is not directly readable, a Loadable Kernel Module (LKM) like LiME (Linux Memory Extractor) can be compiled for the specific Android kernel. LiME allows for in-memory acquisition directly to a network socket or file. This method requires cross-compiling the LiME module for the target Android kernel, which is a more complex process involving kernel source code and toolchains.

Volatility Framework: Android Profile Creation

Volatility requires a profile specific to the target kernel version for effective analysis. Since Android kernels are highly customized, a generic Linux profile often won’t suffice.

Steps to Create an Android Volatility Profile:

1. Obtain Kernel Source/Headers: This is the most challenging part. You need the exact kernel source code or at least the kernel headers (Module.symvers, System.map, and vmlinux) corresponding to the Android device’s kernel. These are often found in the device’s firmware releases or custom ROM repositories. Kernel version can be checked via adb shell cat /proc/version.

2. Compile Module.symvers and System.map: If you have the full kernel source, navigate to the kernel source directory and compile. This will generate System.map and Module.symvers. You might need to perform a `make clean` and then a `make` or `make modules`.

   cd /path/to/android/kernel/sourcemake ARCH=arm64 CROSS_COMPILE=/path/to/aarch64-linux-android-gcc- LKM_BUILD=1 # Example for ARM64

   Ensure you specify the correct architecture (ARCH) and cross-compiler (CROSS_COMPILE) based on your device’s CPU.

3. Create vmlinux: The vmlinux file is an uncompressed kernel image with debug symbols. It’s usually generated during the kernel compilation process. If not, you might need to extract it from a kernel image (e.g., zImage, Image.gz-dtb) using tools like extract-vmlinux or vmlinux-to-elf.

   # Example if vmlinux is not directly availableextract-vmlinux arch/arm64/boot/Image.gz-dtb > vmlinux

4. Package the Profile: Create a ZIP file containing Module.symvers, System.map, and vmlinux. The ZIP file’s name will be your profile name.

   zip Android_4.19.112_Profile.zip Module.symvers System.map vmlinux

   Place this ZIP file in Volatility’s volatility/plugins/linux/ directory or specify its path using the --plugins option.

Memory Analysis with Volatility Framework

With the memory dump and a custom profile, you can now analyze the Android device’s RAM. All Volatility commands will start with vol.py -f android_memdump.raw --profile=Android_4.19.112_Profile (replace with your actual profile name).

Key Volatility Plugins for Android Malware Analysis:

1. linux_pslist: List Running Processes
   Identifies all running processes, their PIDs, parent PIDs, and associated command-line arguments. This is crucial for identifying suspicious processes.

   vol.py -f android_memdump.raw --profile=Android_4.19.112_Profile linux_pslist

2. linux_modscan: Scan for Loaded Kernel Modules
   Lists all loaded kernel modules. Malware might inject malicious modules to gain rootkit functionality or hide processes.

   vol.py -f android_memdump.raw --profile=Android_4.19.112_Profile linux_modscan

3. linux_memmap: Process Memory Maps
   Shows the memory regions of a specific process, including mapped files, shared libraries, and executable segments. Useful for finding injected code or suspicious memory regions.

   vol.py -f android_memdump.raw --profile=Android_4.19.112_Profile linux_memmap -p <PID_OF_SUSPICIOUS_PROCESS>

4. linux_lsof: List Open Files
   Displays files opened by processes. Malware often interacts with specific files (e.g., configuration, data exfiltration, C2 communication). This can reveal hidden files or network sockets.

   vol.py -f android_memdump.raw --profile=Android_4.19.112_Profile linux_lsof

5. linux_netstat: Network Connections
   Enumerates active network connections and listening ports. Essential for detecting C2 communication, data exfiltration attempts, or unauthorized network activity.

   vol.py -f android_memdump.raw --profile=Android_4.19.112_Profile linux_netstat

6. linux_procdump: Dump Process Executable
   Extracts the executable image of a specific process from memory. This allows for static analysis of the running binary, even if it’s packed or obfuscated on disk.

   vol.py -f android_memdump.raw --profile=Android_4.19.112_Profile linux_procdump -p <PID> -D /path/to/output/directory/

7. linux_strings: Extract ASCII and Unicode Strings
   Extracts printable strings from a process’s memory space. Often reveals configuration data, URLs, API keys, or other indicators of compromise (IOCs).

   vol.py -f android_memdump.raw --profile=Android_4.19.112_Profile linux_strings -p <PID>

Challenges and Best Practices

Android memory forensics presents unique challenges:

• Device Fragmentation: A vast array of devices and kernel versions means profiles are rarely interchangeable.
• Anti-Forensics: Sophisticated malware might detect forensic tools or attempts to dump memory and self-terminate or wipe critical data.
• Time Sensitivity: Live memory changes rapidly. The faster you acquire, the more relevant the data.
• Data Volume: Memory dumps can be gigabytes in size, requiring robust storage and processing power.

Best Practices:

• Always work on copies of the memory dump.
• Document every step of the acquisition and analysis process.
• Isolate the device from the network immediately if malware is suspected, but *before* acquisition if live network state is critical.
• Prioritize profile creation for target devices to streamline future investigations.

Conclusion

Live memory acquisition and analysis on rooted Android devices are powerful techniques for uncovering elusive malware. By leveraging tools like dd and the Volatility Framework with custom profiles, forensic investigators can gain unprecedented visibility into the runtime behavior of malicious applications, identify hidden processes, network connections, and extract critical artifacts that would otherwise be missed. As mobile threats continue to evolve, memory forensics will remain an essential capability in the arsenal of any serious Android security researcher or incident responder, offering a deep, unparalleled view into the heart of a compromised system.