Introduction: The Unseen Layers of Android Forensics

In the realm of Android malware analysis, understanding the behavior of malicious applications often requires more than just dynamic analysis or APK reverse engineering. When a device is severely compromised, encrypted, or rendered inoperable, a deeper dive into its persistent storage becomes imperative. This is where NAND flash dump analysis emerges as a powerful, albeit complex, technique. A NAND dump is a raw, bit-for-bit copy of the device’s internal flash memory, providing an unparalleled view into the operating system, installed applications, user data, and the subtle artifacts left by malware.

This article delves into the expert-level methodology of performing a post-mortem analysis of Android NAND dumps to uncover malicious applications and their traces. We’ll explore the acquisition process, initial processing challenges, filesystem extraction, and targeted analysis techniques crucial for identifying malware artifacts that might otherwise remain hidden.

Prerequisites and Tools of the Trade

Before embarking on NAND dump analysis, certain foundational knowledge and tools are essential. This process requires a blend of hardware expertise, low-level data recovery skills, and forensic analysis proficiency.

Hardware & Basic Knowledge:

• Understanding of NAND flash memory architecture (pages, blocks, ECC, spare areas).
• Basic soldering/desoldering skills (for chip-off).
• Knowledge of Android’s filesystem hierarchy (/system, /data, /cache, etc.).
• Familiarity with Linux command-line tools.

Software Tools:

• NAND Programmer: Specialized hardware for reading NAND chips (e.g., various commercial programmers, or open-source solutions like Flashrom with appropriate adapters).
• Hex Editor: HxD, 010 Editor, or similar for raw data inspection.
• Forensic Imaging Tools: FTK Imager Lite, Autopsy, Sleuth Kit (TSK).
• Filesystem Carving Tools: foremost, scalpel, binwalk.
• Filesystem Mounting Utilities: mount, losetup.
• Android Reverse Engineering Tools: Jadx-GUI, Apktool, Frida, Ghidra (for APK and binary analysis).

Acquisition of the NAND Dump: The Chip-Off Method

The most comprehensive method for acquiring a full NAND dump, especially from a non-functional device, is the chip-off technique. This involves physically removing the NAND flash memory chip from the device’s Printed Circuit Board (PCB).

Physical Disassembly Steps (High-Level):

1. Device Disassembly: Carefully open the Android device, locating the main PCB.
2. Chip Identification: Identify the NAND flash memory chip. It’s usually a square or rectangular chip with numerous pins, often from manufacturers like Samsung, Hynix, Micron, or Toshiba. Look for markings that indicate its type (e.g., eMMC, UFS).
3. Desoldering: Using a hot air rework station or specialized desoldering tools, carefully remove the NAND chip from the PCB. Precision is critical to avoid damaging the chip or its pads.
4. Cleaning and Adapter: Clean the chip’s pads and mount it onto a suitable adapter for your NAND programmer. These adapters often have BGA (Ball Grid Array) sockets specific to the chip’s footprint.
5. Reading the Chip: Connect the adapter to the NAND programmer and use its software to read the entire contents of the chip, block by block. Save this as a raw binary image file (e.g., nand_dump.bin).

Initial Processing and Filesystem Identification

Raw NAND dumps are rarely clean filesystem images. They contain raw data, ECC (Error Correcting Code) information, wear-leveling artifacts, and potentially bad blocks. The first challenge is to clean and interpret this data.

Addressing ECC and Spare Areas:

Many NAND programmers will handle ECC and bad block remapping internally, presenting a ‘clean’ raw image. However, some raw dumps may still contain interleaved ECC data or significant spare areas. Tools like nand-sbl or custom scripts might be needed to reconstruct a more usable raw data stream, though this is less common with modern eMMC/UFS dumps.

Identifying Filesystems and Partitions:

Once you have a raw dump, the next step is to identify partitions and their respective filesystems. Android devices typically use `ext4` for /system and /data, but older devices or specific manufacturers might use YAFFS2, F2FS, or others. `binwalk` is an excellent tool for initial analysis:

binwalk -Me nand_dump.bin

This command will scan the dump for known file signatures and attempt to extract them. Look for `squashfs`, `ext4`, `yaffs2`, `fat`, or `vfat` partitions. For more granular control or if `binwalk` struggles, a hex editor can manually identify partition tables (if present) or filesystem headers.

# Example of identifying ext4 superblock magic (0xEF53) with grep on a raw dump (might be slow)grep -Pao 'x53xEF' nand_dump.bin

Filesystem Extraction and Mounting

After identifying potential filesystem offsets, you can extract them into separate image files or directly mount them.

Extracting Partitions:

If `binwalk` didn’t fully extract them, use `dd` to carve out suspected partitions:

# Example: Extract a partition starting at byte offset 0x12340000 with a size of 0x56780000dd if=nand_dump.bin of=system.img bs=1 skip=0x12340000 count=0x56780000

Mounting Filesystems:

Once you have a partition image (e.g., system.img or data.img), you can often mount it as a loop device on a Linux system:

sudo mount -o loop system.img /mnt/android_systemsudo mount -o loop data.img /mnt/android_data

For YAFFS2 filesystems, specialized tools like `unyaffs` or `yaffs2utils` are required as they don’t directly mount as loop devices.

unyaffs data.img extracted_data/

Targeted Analysis for Malware Artifacts

With the filesystems extracted and mounted, the real hunt for malware begins. Focus on specific areas known to harbor malicious components.

1. Application Directories:

• /data/app: Contains user-installed applications (APKs). Malware often masquerades as legitimate apps here.
• /data/app-private: Legacy location for some private app data.
• /system/app & /system/priv-app: System-level applications. Malware that achieves root or system-level privileges might inject itself here, posing as a legitimate system component.

Thoroughly inspect all APKs in these directories. Use `Apktool` to decompile and `Jadx-GUI` or `Ghidra` for deeper code analysis.

apktool d malicious.apk -o malicious_decompiled/jadx-gui malicious.apk

2. Application Private Data:

• /data/data/: Each application stores its private data here, including databases (SQLite), shared preferences (XML), caches, and custom files. Look for suspicious configurations, C2 server addresses, collected data, or signs of illicit activities within these files.

find /mnt/android_data/data -name "*.db" -exec sqlite3 {} .dump ;find /mnt/android_data/data -name "*.xml" -exec cat {} ; | grep -i "c2server"

3. Dalvik Cache and Optimized DEX Files:

• /data/dalvik-cache: Contains optimized DEX files (ODEX) for installed applications. While not directly executable, inspecting these can reveal an app’s true classes and methods if the original APK was heavily obfuscated.

4. Persistence Mechanisms:

Malware often establishes persistence. Look for:

• Boot-time services: Injected code or scripts in /system/etc/init.d, modified init scripts, or entries in /data/system/startup-config.xml.
• Broadcast Receivers: APKs registering for `BOOT_COMPLETED` or other system events.
• Rootkit components: Modified system binaries (e.g., `su`, `init`), kernel modules (`.ko` files), or altered libraries in /system/lib or /system/lib64.

5. Log Files and System Traces:

• /data/log & /dev/log (if accessible): Android’s unified logging system can sometimes contain traces of malware activity, crashes, or unusual network connections.
• Browser history, SMS, Contacts: Malware designed for data exfiltration will leave traces in these user data files.

6. Network Configuration & C2 Infrastructure:

• Hardcoded IP addresses or domains: Use `strings` and `grep` on relevant binaries and configuration files to find potential Command and Control (C2) servers.
• VPN or Proxy Configurations: Malware might install custom VPN profiles or proxy settings to intercept traffic.

strings -a /mnt/android_system/bin/* | grep -E "(http|https|ftp)://[a-zA-Z0-9.-]+"strings -a /mnt/android_data/data/*/*.db | grep -E "(http|https|ftp)://[a-zA-Z0-9.-]+"

Conclusion

Post-mortem analysis of Android NAND dumps is an indispensable technique for deep-seated malware investigation. While challenging due to the hardware-level acquisition and the complexity of raw data processing, it offers an unparalleled forensic view into a compromised device. By meticulously extracting filesystems, scrutinizing application data, and hunting for persistence mechanisms and C2 traces, forensic analysts can unmask even the most elusive malicious applications, providing critical intelligence for incident response and threat intelligence.

This methodology goes beyond conventional dynamic or static analysis, reaching into the very heart of the device’s persistent memory. It’s a testament to the fact that even when a device seems ‘dead,’ its digital footprint can still tell a compelling story of compromise and exploitation.