Assessing the Forensic Viability of Android Memory Analysis Across Production Builds: A Cross-Version Study of Security Hardening and Structure Preservation
arXiv:2607.13821
The paper measures how Google’s security hardening that strips debug symbols from Android runtime binaries affects the ability to perform memory forensics, showing that while symbol information is largely removed, core heap and garbage‑collector structures remain intact across Android 8 to Android 15.
Abstract
Android memory forensics recovers evidence that never touches disk: decrypted messages, session credentials, and the live internal state of a running application. The tools that perform this recovery depend on debug symbols embedded in libart.so, the Android Runtime library, to locate data structures and interpret their layout. Across recent releases Google has stripped most of that information from the binaries that ship on consumer phones as part of a broader security hardening effort, yet no prior work has measured how far the stripping has progressed on the devices examiners actually encounter, or whether the memory architecture beneath the stripped surface still resembles what the forensics literature describes. This paper measures the gap between the unstripped development builds researchers use and the production builds that ship on real hardware, using binaries extracted from Pixel factory images across Android 8 through Android 15. Static symbols fell from 20,495 entries to zero, dynamic symbols dropped by roughly 60 percent, and source file references disappeared entirely. A compressed fallback section in the Android 15 binary restores thousands of function names but carries no structure layouts. Source code review and memory map comparisons across Android 8 and 15 show that the heap spaces, garbage collector infrastructure, and allocation bitmaps remain structurally intact, with visible changes limited to naming and arithmetic optimization. Live validation on a rooted, fully stripped Pixel 7 confirms that the runtime entry point is still locatable through the dynamic symbol table, and that structural offsets pulled from a version-matched development build resolve to valid pointers inside production memory.