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

Imagina que tu smartphone es una ciudad bulliciosa y de alta seguridad. Dentro de esta ciudad, las aplicaciones son como tiendas concurridas, y la RAM (memoria) es el espacio de trabajo temporal donde ocurren todas las transacciones actuales. Cuando envías un mensaje secreto o inicias sesión en una cuenta, los datos existen en este espacio de trabajo por un momento antes de ser eliminados o movidos al disco duro. La informática forense es el arte de colarse en este espacio de trabajo para capturar la evidencia antes de que se desvanezca. Pero aquí está el truco: los arquitectos de la ciudad (Google) han estado construyendo muros más altos y eliminando las señales de tráfico. En el pasado, los investigadores podían entrar con un mapa (símbolos de depuración) que les decía exactamente dónde estaba la tienda del "Mensaje Secreto". Ahora, la ciudad ha sido despojada de esas señales para que sea más difícil para los hackers entrar, dejando a los investigadores mirando una pared en blanco, preguntándose si las tiendas incluso siguen ahí.

Este artículo es una historia de detectives sobre si esas tiendas siguen en pie, incluso si las señales han desaparecido. Los investigadores se preguntaron: "Google ha eliminado los mapas de los teléfonos que realmente compramos, pero ¿también han movido los edificios?". Compararon la versión de "plano" del sistema Android (que los desarrolladores usan y tienen mapas completos) contra las versiones de "producción" (las que recibe la gente común, con todas las señales eliminadas). Descubrieron que, si bien las señales de tráfico han desaparecido, los edificios en sí no se han movido. El diseño de la memoria sigue siendo el mismo; solo es que ya no tiene una etiqueta de nombre. Esto significa que con un poco de trabajo de detective adicional —usando un plano de una versión coincidente de la ciudad— los investigadores aún pueden encontrar la evidencia, incluso en los teléfonos más modernos y protegidos.

El Gran Robo de Mapas

Durante años, los expertos en informática forense dependieron de un archivo de biblioteca llamado libart.so para navegar por la caótica memoria de los teléfonos Android. Piensa en este archivo como el directorio maestro de una biblioteca masiva. Dentro, tenía una lista completa de cada libro, cada estante y exactamente dónde se encontraba cada párrafo. Estas listas se llamaban "símbolos". Si un investigador quería encontrar una pieza específica de evidencia, como un mensaje de chat descifrado, simplemente buscaba el símbolo "chat" en el directorio, y puf, la herramienta sabía exactamente dónde buscar en la memoria.

Pero Google, queriendo hacer los teléfonos más seguros contra los hackers, comenzó una campaña de "fortalecimiento" (hardening). Se dieron cuenta de que si un hacker tenía el directorio completo, podría encontrar fácilmente debilidades para irrumpir en el sistema. Así que empezaron a eliminar estos directorios de los teléfonos que realmente se envían a las tiendas. Se llevaron los símbolos estáticos (la lista principal), las referencias de archivos fuente (las notas del autor) y la mayoría de los símbolos dinámicos. Fue como tomar una biblioteca y quitarle el catálogo de fichas, dejando solo algunas etiquetas esenciales en las puertas para que los bibliotecarios pudieran abrirlas, pero ocultando todo lo demás.

La gran pregunta era: ¿Solo eliminaron las etiquetas, o también reorganizaron los estantes? Si los estantes se movieron, entonces incluso si un investigador tuviera un plano de una versión antigua de la biblioteca, no serviría de nada.

El Trabajo de Detective

Para resolver esto, los investigadores actuaron como bibliotecarios que viajan en el tiempo. Tomaron dos versiones del sistema Android:

1. La compilación de "Desarrollador": Una versión con el directorio completo y sin eliminar (el plano).
2. La compilación de "Producción": La versión que realmente se ejecuta en un Google Pixel 7 (la realidad reducida).

Primero miraron los números. En la antigua versión de Android 8, la biblioteca tenía 20.495 símbolos estáticos. En la nueva versión de Android 15, ese número cayó a cero. Las referencias de archivos fuente, que indicaban de qué archivo de código provenía una función, también desaparecieron por completo. Los símbolos dinámicos (las pocas etiquetas que tenían que quedarse para que el teléfono funcionara) disminuyeron aproximadamente un 60 por ciento, de 6.577 a 2.614.

Parecía un desastre para la informática forense. Pero luego, miraron más profundo. Revisaron la estructura real de la memoria: los "estantes" y los "libros" mismos. Compararon los mapas de memoria de un teléfono Android 8 y un teléfono Android 15. Encontraron que las estructuras centrales, como el "heap" (donde las aplicaciones almacenan sus datos) y el "recolector de basura" (que limpia los datos antiguos), seguían allí. Solo habían cambiado ligeramente sus nombres. Por ejemplo, un espacio de memoria llamado dalvik-allocspace main rosalloc en Android 8 se convirtió en dalvik-allocspace non moving en Android 15. El edificio se movió, pero la dirección no cambió.

El Truco del "Plano Mágico"

La parte más emocionante del artículo es el "truco de magia" que realizaron. Dado que el teléfono no tiene mapa, los investigadores decidieron tomar prestado un mapa de una versión coincidente.

Tomaron la compilación de "Desarrollador" de Android 15 (que aún tenía el mapa completo) y la usaron para encontrar el desplazamiento exacto (la distancia en bytes) hacia estructuras específicas. Luego, fueron al Pixel 7 de "Producción" (que no tenía mapa) y aplicaron esas mismas distancias.

Esto fue lo que pasó:

1. Encontraron el objeto "Runtime" (el gestor principal de la memoria del teléfono) usando un único símbolo que tenía que permanecer para que el teléfono funcionara.
2. Usaron el mapa de "Desarrollador" para encontrar dónde se encontraba el "Heap" (el almacenamiento de datos) dentro de ese objeto Runtime.
3. Aplicaron esa distancia al teléfono de "Producción".
4. Resultado: Funcionó perfectamente. El puntero que calcularon condujo a la misma dirección de memoria válida en el teléfono real.

Repitieron esto para la "Lista de Hilos" (Thread List) y el "Espacio de Puntero Bump" (Bump Pointer Space), y cada vez, el plano de la versión de desarrollador los llevó al lugar correcto en el teléfono de producción reducido.

Lo Que Esto Signa para el Futuro

El artículo sugiere que, aunque el "modo fácil" de la informática forense ha terminado, el juego no se ha perdido. El fortalecimiento de la seguridad no rompió la arquitectura de la memoria; solo ocultó las etiquetas.

• La Buena Noticia: El diseño interno de la memoria se preserva. Si tienes una compilación de "Desarrollador" que coincida exactamente con la versión del teléfono que estás investigando, puedes usar su mapa para navegar por el teléfono reducido.
• La Mala Noticia: No puedes usar simplemente un mapa antiguo. El artículo señala que los desplazamientos de las estructuras cambian entre diferentes versiones de Android (como Android 14 vs. 15). Por lo tanto, no puedes usar un mapa de Android 8 para resolver un caso de Android 15. Necesitas un plano que coincida con la versión.
• El Problema: Este proceso es ahora mucho más manual. Los investigadores no pueden simplemente ejecutar una herramienta que diga "Buscar Evidencia". Tienen que encontrar la versión exacta del teléfono, obtener la compilación de desarrollador correspondiente, extraer las distancias específicas y luego aplicarlas manualmente.

Los investigadores también señalaron que solo probaron esto en dispositivos Google Pixel. No están seguros de si otros fabricantes de teléfonos (como Samsung o Xiaomi) han hecho lo mismo o si han reorganizado los estantes por completo. Pero para los dispositivos que probaron, la conclusión es clara: la ciudad sigue ahí, los edificios no se han movido, pero necesitarás traer tu propio mapa para poder orientarte.