Assessing the Forensic Viability of Android Memory Analysis Across Production Builds: A Cross-Version Study of Security Hardening and Structure Preservation

Imagine your smartphone is a bustling, high-security city. Inside this city, your apps are like busy shops, and the RAM (memory) is the temporary workspace where all the current transactions happen. When you send a secret message or log into an account, the data exists in this workspace for a moment before it gets deleted or moved to the hard drive. Digital forensics is the art of sneaking into this workspace to grab evidence before it vanishes. But here's the catch: the city's architects (Google) have been building higher walls and removing the street signs. In the past, investigators could walk in with a map (debug symbols) that told them exactly where the "Secret Message" shop was located. Now, the city has been stripped of those signs to make it harder for hackers to break in, leaving investigators staring at a blank wall, wondering if the shops are even still there.

This paper is a detective story about whether those shops are still standing, even if the signs are gone. The researchers asked: "Google has removed the maps from the phones we actually buy, but did they also move the buildings?" They compared the "blueprint" versions of the Android system (which developers use and have full maps for) against the "production" versions (which regular people get, with all the signs stripped away). They found that while the street signs are indeed gone, the buildings themselves haven't moved. The layout of the memory is still the same; it just doesn't have a name tag anymore. This means that with a little extra detective work—using a blueprint from a matching version of the city—investigators can still find the evidence, even on the most modern, hardened phones.

The Great Map Heist

For years, digital forensics experts relied on a library file called libart.so to navigate the chaotic memory of Android phones. Think of this file as the master directory of a massive library. Inside, it had a complete list of every book, every shelf, and exactly where every paragraph was located. These lists were called "symbols." If an investigator wanted to find a specific piece of evidence, like a decrypted chat message, they just looked up the "chat" symbol in the directory, and poof, the tool knew exactly where to look in the memory.

But Google, wanting to make phones more secure against hackers, started a "hardening" campaign. They realized that if a hacker had the full directory, they could easily find weaknesses to break into the system. So, they began stripping these directories out of the phones that actually ship to stores. They took away the static symbols (the main list), the source file references (the author's notes), and most of the dynamic symbols. It was like taking a library and removing the card catalog, leaving only a few essential labels on the doors so the librarians could still open them, but hiding everything else.

The big question was: Did they just remove the labels, or did they also rearrange the shelves? If the shelves moved, then even if an investigator had a blueprint from an old version of the library, it wouldn't help.

The Detective Work

To solve this, the researchers acted like time-traveling librarians. They grabbed two versions of the Android system:

1. The "Developer" Build: A version with the full, unstripped directory (the blueprint).
2. The "Production" Build: The version actually running on a Google Pixel 7 phone (the stripped-down reality).

They looked at the numbers first. In the old Android 8 version, the library had 20,495 static symbols. In the new Android 15 version, that number dropped to zero. The source file references, which told you which code file a function came from, also vanished completely. The dynamic symbols (the few labels that had to stay for the phone to work) dropped by about 60 percent, from 6,577 down to 2,614.

It looked like a disaster for forensics. But then, they looked deeper. They checked the actual structure of the memory—the "shelves" and "books" themselves. They compared the memory maps of an Android 8 phone and an Android 15 phone. They found that the core structures, like the "heap" (where apps store their data) and the "garbage collector" (which cleans up old data), were still there. They had just changed their names slightly. For example, a memory space called dalvik-allocspace main rosalloc in Android 8 became dalvik-allocspace non moving in Android 15. The building moved, but the address didn't change.

The "Magic Blueprint" Trick

The most exciting part of the paper is the "magic trick" they pulled off. Since the phone itself has no map, the researchers decided to borrow a map from a matching version.

They took the "Developer" build of Android 15 (which still had the full map) and used it to find the exact offset (the distance in bytes) to specific structures. Then, they went to the "Production" Pixel 7 (which had no map) and applied those same distances.

Here is what happened:

1. They found the "Runtime" object (the main manager of the phone's memory) using a single symbol that had to stay for the phone to work.
2. They used the "Developer" map to find where the "Heap" (the data storage) was located inside that Runtime object.
3. They applied that distance to the "Production" phone.
4. Result: It worked perfectly. The pointer they calculated led to the exact same valid memory address on the real phone.

They repeated this for the "Thread List" and the "Bump Pointer Space," and every single time, the blueprint from the developer version led them to the correct spot on the stripped production phone.

What This Means for the Future

The paper suggests that while the "easy mode" of forensics is over, the game isn't lost. The security hardening didn't break the memory architecture; it just hid the labels.

• The Good News: The internal layout of the memory is preserved. If you have a "Developer" build that matches the exact version of the phone you are investigating, you can use its map to navigate the stripped phone.
• The Bad News: You can't just use an old map. The paper notes that structure offsets change between different Android versions (like Android 14 vs. 15). So, you can't use an Android 8 map to solve an Android 15 case. You need a version-matched blueprint.
• The Catch: This process is now much more manual. Investigators can't just run a tool that says "Find Evidence." They have to find the exact version of the phone, pull the matching developer build, extract the specific distances, and then apply them manually.

The researchers also noted that they only tested this on Google Pixel devices. They aren't sure if other phone makers (like Samsung or Xiaomi) have done the same thing or if they've rearranged the shelves entirely. But for the devices they tested, the conclusion is clear: the city is still there, the buildings haven't moved, but you'll need to bring your own map to find your way around.