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

Imagine que o seu smartphone é uma cidade movimentada e de alta segurança. Dentro desta cidade, os seus aplicativos são como lojas movimentadas, e a RAM (memória) é o espaço de trabalho temporário onde todas as transações atuais acontecem. Quando você envia uma mensagem secreta ou faz login em uma conta, os dados existem neste espaço de trabalho por um momento antes de serem deletados ou movidos para o disco rígido. A perícia digital é a arte de entrar furtivamente neste espaço de trabalho para capturar evidências antes que elas desapareçam. Mas aqui está o detalhe: os arquitetos da cidade (Google) têm construído muros mais altos e removido as placas de sinalização. No passado, os investigadores podiam entrar com um mapa (símbolos de depuração/debug symbols) que lhes dizia exatamente onde ficava a loja "Mensagem Secreta". Agora, a cidade foi desprovida dessas placas para dificultar a entrada de hackers, deixando os investigadores encarando uma parede branca, perguntando-se se as lojas ainda estão lá.

Este artigo é uma história de detetive sobre se essas lojas ainda estão de pé, mesmo que as placas tenham sumido. Os pesquisadores perguntaram: "O Google removeu os mapas dos telefones que realmente compramos, mas eles também mudaram os edifícios?" Eles compararam as versões "projeto" (blueprint) do sistema Android (que os desenvolvedores usam e possuem mapas completos) contra as versões de "produção" (que as pessoas comuns recebem, com todas as placas removidas). Eles descobriram que, embora as placas de sinalização tenham de fato sumido, os edifícios em si não se moveram. O layout da memória continua o mesmo; ele apenas não tem mais uma etiqueta de identificação. Isso significa que, com um pouco de trabalho extra de detetive — usando um projeto de uma versão correspondente da cidade — os investigadores podem ainda encontrar as evidências, mesmo nos telefones mais modernos e protegidos.

O Grande Roubo dos Mapas

Por anos, especialistas em perícia digital confiaram em um arquivo de biblioteca chamado libart.so para navegar na memória caótica dos telefones Android. Pense neste arquivo como o diretório mestre de uma biblioteca enorme. Dentro dele, havia uma lista completa de cada livro, cada prateleira e exatamente onde cada parágrafo estava localizado. Essas listas eram chamadas de "símbolos". Se um investigador quisesse encontrar uma evidência específica, como uma mensagem de chat descriptografada, bastava procurar pelo símbolo "chat" no diretório e, poof, a ferramenta sabia exatamente onde procurar na memória.

Mas o Google, querendo tornar os telefones mais seguros contra hackers, iniciou uma campanha de "endurecimento" (hardening). Eles perceberam que, se um hacker tivesse o diretório completo, poderia facilmente encontrar vulnerabilidades para invadir o sistema. Por isso, começaram a remover esses diretórios dos telefones que realmente chegam às lojas. Eles removeram os símbolos estáticos (a lista principal), as referências de arquivos de origem (as notas do autor) e a maioria dos símbolos dinâmicos. Foi como pegar uma biblioteca e remover o catálogo de fichas, deixando apenas algumas etiquetas essenciais nas portas para que os bibliotecários ainda pudessem abri-las, mas escondendo todo o resto.

A grande questão era: eles apenas removeram as etiquetas ou também reorganizaram as prateleiras? Se as prateleiras se movessem, então, mesmo que um investigador tivesse um projeto de uma versão antiga da biblioteca, isso não ajudaria.

O Trabalho de Detetive

Para resolver isso, os pesquisadores agiram como bibliotecários viajantes do tempo. Eles pegaram duas versões do sistema Android:

1. A Build de "Desenvolvedor": Uma versão com o diretório completo e sem remoção de símbolos (o projeto/blueprint).
2. A Build de "Produção": A versão que realmente está rodando em um Google Pixel 7 (a realidade simplificada).

Eles analisaram os números primeiro. Na antiga versão Android 8, a biblioteca tinha 20.495 símbolos estáticos. Na nova versão Android 15, esse número caiu para zero. As referências de arquivos de origem, que diziam de qual arquivo de código vinha uma função, também desapareceram completamente. Os símbolos dinâmicos (as poucas etiquetas que precisavam ficar para o telefone funcionar) caíram cerca de 60 por cento, de 6.577 para 2.614.

Parecia um desastre para a perícia. Mas então, eles olharam mais profundamente. Eles verificaram a estrutura real da memória — as próprias "prateleiras" e "livros". Eles compararam os mapas de memória de um telefone Android 8 e de um Android 15. Descobriram que as estruturas principais, como o "heap" (onde os apps armazenam seus dados) e o "garbage collector" (que limpa dados antigos), ainda estavam lá. Elas apenas mudaram de nome levemente. Por exemplo, um espaço de memória chamado dalvik-allocspace main rosalloc no Android 8 tornou-se dalvik-allocspace non moving no Android 15. O edifício se moveu, mas o endereço não mudou.

O Truque do "Projeto Mágico"

A parte mais emocionante do artigo é o "truque de mágica" que eles realizaram. Como o telefone em si não possui um mapa, os pesquisadores decidiram pegar emprestado um mapa de uma versão correspondente.

Eles pegaram a build de "Desenvolvedor" do Android 15 (que ainda tinha o mapa completo) e a usaram para encontrar o deslocamento exato (offset/distância em bytes) para estruturas específicas. Em seguida, foram ao Pixel 7 de "Produção" (que não tinha mapa) e aplicaram essas mesmas distâncias.

Aqui está o que aconteceu:

1. Eles encontraram o objeto "Runtime" (o principal gerenciador da memória do telefone) usando um único símbolo que tinha que permanecer para o telefone funcionar.
2. Usaram o mapa de "Desenvolvedor" para encontrar onde o "Heap" (o armazenamento de dados) estava localizado dentro desse objeto Runtime.
3. Aplicaram essa distância ao telefone de "Produção".
4. Resultado: Funcionou perfeitamente. O ponteiro que eles calcularam levou exatamente ao mesmo endereço de memória válido no telefone real.

Eles repetiram isso para a "Thread List" e para o "Bump Pointer Space", e toda vez, o projeto da versão de desenvolvedor os levou ao local correto no telefone de produção simplificado.

O Que Isso Significa para o Futuro

O artigo sugere que, embora o "modo fácil" da perícia tenha acabado, o jogo não está perdido. O endurecimento da segurança não quebrou a arquitetura da memória; apenas escondeu as etiquetas.

• A Boa Notícia: O layout interno da memória é preservado. Se você tiver uma build de "Desenvolvedor" que corresponda exatamente à versão do telefone que você está investigando, pode usar o mapa dela para navegar no telefone simplificado.
• A Má Notícia: Você não pode simplesmente usar um mapa antigo. O artigo observa que os deslocamentos das estruturas mudam entre diferentes versões do Android (como Android 14 vs. 15). Portanto, você não pode usar um mapa do Android 8 para resolver um caso de Android 15. Você precisa de um projeto que seja da mesma versão.
• O Detalhe: Este processo agora é muito mais manual. Os investigadores não podem apenas rodar uma ferramenta que diga "Encontrar Evidência". Eles têm que encontrar a versão exata do telefone, extrair a build de desenvolvedor correspondente, extrair as distâncias específicas e, então, aplicá-las manualmente.

Os pesquisadores também observaram que testaram isso apenas em dispositivos Google Pixel. Eles não têm certeza se outros fabricantes de telefones (como Samsung ou Xiaomi) fizeram a mesma coisa ou se eles reorganizaram as prateleiras inteiramente. Mas para os dispositivos que testaram, a conclusão é clara: a cidade ainda está lá, os edifícios não se moveram, mas você precisará trazer seu próprio mapa para encontrar o caminho.