A memória RAM oferece uma visão privilegiada do estado operacional de um sistema. Processos em execução, módulos carregados, conexões de rede, chaves criptográficas, comandos, credenciais temporárias e artefatos de códigos maliciosos podem estar presentes na memória mesmo quando deixam poucos vestígios persistentes em dispositivos de armazenamento.
Entretanto, uma imagem de memória não deve ser interpretada como uma fotografia perfeitamente instantânea. Na maioria das aquisições realizadas em sistemas ativos, a cópia ocorre sequencialmente enquanto o sistema operacional continua executando processos, atendendo interrupções, modificando tabelas, alocando páginas e liberando objetos.
O resultado é uma representação produzida durante um intervalo temporal. Algumas regiões podem refletir o estado existente no início da aquisição, enquanto outras correspondem a momentos posteriores. A qualidade da análise depende, portanto, da compreensão de como a memória foi adquirida, de como os endereços são traduzidos e de como os objetos do sistema operacional são reconstruídos.
A memória como estado computacional dinâmico
O conteúdo da RAM muda continuamente. Mesmo um equipamento aparentemente ocioso mantém atividades internas:
- escalonamento de processos e threads;
- atualização de contadores e temporizadores;
- recepção e transmissão de pacotes;
- gerenciamento de caches;
- paginação de memória;
- criação e liberação de objetos do kernel;
- execução de serviços e agentes de segurança;
- registro de eventos;
- atualização de estruturas associadas ao sistema de arquivos.
A própria ferramenta de aquisição participa desse ambiente. Sua execução pode criar um processo, carregar um driver, reservar buffers, consumir tempo de processador e produzir operações de entrada e saída.
Uma representação simplificada da aquisição pode ser expressa por:
[
I = A\left(M(t),\Delta t,T,P\right)
]
em que:
- (I) representa a imagem adquirida;
- (M(t)) corresponde ao estado variável da memória ao longo do tempo;
- (\Delta t) é a duração da aquisição;
- (T) representa a técnica e a ferramenta empregadas;
- (P) corresponde às propriedades do sistema observado.
Essa formulação evidencia que a imagem resultante não depende apenas do conteúdo da RAM. Ela também depende do modo pelo qual esse conteúdo foi observado e registrado.
Correção, atomicidade, integridade e completude
A avaliação técnica de uma aquisição de memória pode envolver quatro propriedades relacionadas, mas distintas.
Correção
A correção indica se o valor registrado para determinado endereço corresponde ao valor que efetivamente estava armazenado naquele endereço quando ele foi lido.
Erros de acesso, falhas de drivers, regiões inacessíveis e conversões incorretas de formato podem comprometer essa propriedade.
Atomicidade
Uma aquisição possui atomicidade ideal quando todas as regiões representam um mesmo estado instantâneo ou, em uma definição mais ampla, um estado causalmente coerente.
Em sistemas físicos ativos, a aquisição integral da RAM normalmente exige algum tempo. Enquanto os bytes são copiados, o sistema continua modificando seu próprio estado. Por isso, imagens obtidas por software em ambiente ativo frequentemente apresentam atomicidade limitada.
Estudos experimentais demonstram que métodos baseados em software executados no próprio sistema tendem a apresentar variações relacionadas à atividade concorrente, enquanto snapshots controlados em determinados ambientes virtualizados podem alcançar condições superiores de atomicidade. A qualidade concreta, contudo, depende da implementação e do cenário analisado.
Integridade
Nesse contexto, integridade possui duas dimensões importantes.
A primeira consiste em garantir que a imagem permaneça inalterada após sua produção, normalmente por meio de funções de hash, controles de armazenamento e cadeia de custódia.
A segunda diz respeito à influência da aquisição sobre a própria memória observada. Se a ferramenta sobrescreve regiões que ainda seriam copiadas, parte do conteúdo original pode ser substituída por dados decorrentes do procedimento.
Completude
A completude avalia se todas as regiões relevantes e acessíveis foram incluídas.
Uma aquisição pode deixar de conter:
- páginas transferidas para arquivo de paginação;
- páginas pertencentes a regiões inacessíveis;
- conteúdo armazenado em dispositivos;
- memória de coprocesso ou placa gráfica;
- áreas excluídas pela ferramenta;
- regiões protegidas pelo hipervisor;
- páginas cuja leitura produziu erro;
- dados mantidos apenas em armazenamento secundário.
A imagem pode ser íntegra enquanto arquivo e, ao mesmo tempo, incompleta como representação do espaço de memória do sistema.
O fenômeno de memory smear
O termo memory smear descreve inconsistências produzidas porque diferentes partes da RAM são copiadas em momentos distintos.
Considere um processo encerrado durante a aquisição. A lista principal de processos pode ter sido copiada antes do encerramento, enquanto seus objetos auxiliares foram lidos depois. O resultado poderá conter:
- uma entrada do processo ainda vinculada à lista;
- páginas do executável já liberadas;
- threads parcialmente removidas;
- identificadores encerrados;
- referências para estruturas reutilizadas;
- tempos e contadores correspondentes a estados diferentes.
O inverso também pode ocorrer: a lista pode ser adquirida depois da remoção do processo, enquanto regiões copiadas anteriormente ainda preservam seu objeto e suas páginas.
O SWGDE observa que o tempo necessário para extrair a memória pode contribuir para o smear, pois o sistema continua modificando dados durante a aquisição. Estudos acadêmicos sobre atomicidade e integridade em métodos de aquisição apresentam resultados experimentais compatíveis com esse problema.
A presença de inconsistências não demonstra, isoladamente, falha da ferramenta ou manipulação maliciosa. Ela deve ser examinada em relação:
- à duração da aquisição;
- à carga computacional;
- ao método de leitura;
- à ordem em que as regiões foram copiadas;
- à atividade do sistema;
- aos objetos envolvidos;
- à possibilidade de desalocação e reutilização da memória.
A interferência produzida pela aquisição
Toda aquisição executada dentro do sistema observado possui algum grau de interferência.
Uma ferramenta pode:
- carregar bibliotecas e drivers;
- criar processos e threads;
- alterar tabelas internas;
- reservar memória paginada e não paginada;
- modificar caches;
- criar arquivos temporários;
- gerar conexões de rede;
- registrar eventos;
- acionar mecanismos de proteção;
- deslocar páginas entre RAM e armazenamento.
Essa interferência não torna automaticamente o procedimento inválido. Ela precisa ser conhecida, minimizada e documentada.
O registro técnico deve identificar, sempre que possível:
- nome e versão da ferramenta;
- hash do executável e de seus componentes;
- driver carregado;
- privilégios utilizados;
- comandos executados;
- horário inicial e final;
- destino da imagem;
- volume de dados produzido;
- mensagens de erro;
- impacto esperado da ferramenta;
- método empregado para verificar o resultado.
A distinção entre vestígios preexistentes e alterações produzidas pela coleta é parte essencial da interpretação.
Endereços físicos e espaços virtuais
Uma imagem bruta de RAM normalmente apresenta páginas físicas. Processos, entretanto, trabalham com endereços virtuais.
Cada processo possui seu próprio espaço de endereçamento. Assim, dois processos podem utilizar o mesmo endereço virtual e alcançar páginas físicas diferentes. Da mesma forma, páginas virtuais contíguas podem ser mapeadas para quadros físicos separados.
A documentação da Microsoft sobre espaços de endereços virtuais demonstra essa separação entre endereços virtuais de processos e páginas físicas.
A tradução pode ser resumida por:
[
VA \xrightarrow[\text{tabelas de páginas}]{\text{contexto do processo}} PA
]
em que:
- (VA) é o endereço virtual;
- (PA) é o endereço físico;
- o contexto do processo fornece a raiz das tabelas de páginas;
- as entradas dessas tabelas determinam o mapeamento válido.
Em arquiteturas x86-64, a tradução costuma envolver uma hierarquia de tabelas. Dependendo da configuração, podem existir páginas convencionais ou páginas grandes, além de bits de controle relacionados a presença, escrita, execução, usuário e outras propriedades.
Por isso, localizar uma sequência de bytes em determinado deslocamento físico não basta para atribuí-la a um processo. É necessário estabelecer:
- qual página física contém os bytes;
- qual tabela de páginas os referencia;
- qual endereço virtual resulta dessa tradução;
- qual processo utiliza aquela tabela;
- quais permissões e características pertencem ao mapeamento;
- qual objeto ou arquivo dá contexto à região.
Páginas residentes, paginadas e comprimidas
O espaço virtual de um processo pode ser maior que a quantidade de dados efetivamente residente na RAM. O sistema operacional mantém apenas parte das páginas em memória física.
Uma página virtual pode estar:
- residente na RAM;
- presente em lista de espera;
- modificada e aguardando gravação;
- armazenada em arquivo de paginação;
- representada por mapeamento de arquivo;
- compartilhada com outro processo;
- submetida a mecanismo de cópia na escrita;
- comprimida pelo gerenciador de memória;
- reservada sem conteúdo comprometido;
- inacessível ou liberada.
A documentação da Microsoft sobre memória virtual e armazenamento físico descreve a organização em páginas e a possibilidade de movimentação entre memória física e arquivo de paginação.
Consequentemente, a ausência de determinado conteúdo na imagem RAM não significa que ele estivesse ausente do espaço virtual do processo. O conteúdo pode ter sido paginado, liberado, comprimido ou substituído durante a aquisição.
Quando tecnicamente pertinente, arquivos de paginação, arquivos de hibernação e outros artefatos associados devem ser examinados em conjunto com a memória física. Essa integração exige cautela temporal: os componentes podem representar instantes diferentes.
Camadas de interpretação
Frameworks modernos de análise de memória organizam o exame em camadas. A arquitetura documentada pelo Volatility 3, por exemplo, separa camadas de memória, objetos, modelos de tipos e tabelas de símbolos.
De forma conceitual, a interpretação pode ser representada por:
[
\text{arquivo adquirido}
\rightarrow
\text{memória física}
\rightarrow
\text{tradução virtual}
\rightarrow
\text{tipos do kernel}
\rightarrow
\text{objetos}
\rightarrow
\text{artefatos interpretados}
]
Cada transição acrescenta hipóteses técnicas.
A leitura de um campo como identificador de processo depende de que:
- o formato da imagem tenha sido interpretado corretamente;
- a arquitetura do sistema tenha sido identificada;
- a tradução dos endereços esteja correta;
- a versão do kernel seja compatível;
- o deslocamento do campo esteja correto;
- os bytes pertençam realmente ao objeto proposto.
O resultado de um plugin não é uma observação direta e independente. Ele é a saída de uma cadeia de traduções.
Símbolos, tipos e versão do kernel
Estruturas internas do sistema operacional mudam entre versões, compilações e atualizações. Campos podem ser acrescentados, removidos, deslocados ou reinterpretados.
Tabelas de símbolos e modelos de tipos fornecem informações como:
- nomes de estruturas;
- tamanhos dos objetos;
- deslocamentos de campos;
- tipos de ponteiros;
- enumerações;
- endereços de símbolos;
- relações entre componentes do kernel.
A identificação incorreta desses elementos pode fazer com que bytes válidos sejam interpretados como campos errados. Um valor plausível ainda pode ser incorreto por coincidência.
A validação deve considerar:
- arquitetura do processador;
- versão e compilação do sistema;
- identificação do kernel;
- símbolos selecionados;
- resultado da tradução de endereços;
- mensagens de automação ou detecção;
- consistência entre plugins;
- compatibilidade da ferramenta com o sistema examinado.
A aleatorização de endereços do kernel também exige que a localização efetiva da imagem carregada seja determinada antes da resolução adequada dos símbolos.
Reconstrução de processos por múltiplas perspectivas
A lista principal de processos é uma fonte importante, mas representa apenas uma perspectiva.
Em sistemas Windows, por exemplo, processos ativos podem ser percorridos por meio de estruturas encadeadas mantidas pelo kernel. Uma segunda técnica pode procurar candidatos a objetos de processo diretamente nas regiões de memória, observando assinaturas, cabeçalhos, identificadores e outros campos.
Outras perspectivas incluem:
- threads vinculadas;
- tabelas de identificadores;
- objetos de processo;
- árvores de regiões virtuais;
- diretórios de tabelas de páginas;
- módulos carregados;
- regiões executáveis;
- sessões;
- tokens de segurança;
- conexões de rede;
- referências mantidas por outros objetos.
Uma divergência entre essas perspectivas é um ponto de investigação, não uma conclusão pronta.
Um objeto encontrado por varredura e ausente da lista ativa pode corresponder a:
- processo encerrado recentemente;
- objeto desalocado ainda não sobrescrito;
- estrutura parcialmente corrompida;
- falso positivo da varredura;
- inconsistência produzida pelo smear;
- fragmento de uma aquisição incompleta;
- objeto ocultado por manipulação das estruturas do kernel.
A hipótese de ocultação exige demonstração adicional de que o processo ainda apresentava estado operacional coerente quando deveria estar vinculado à lista.
Percurso de listas e varredura de objetos
O percurso de uma lista estruturada aproveita relações mantidas pelo sistema operacional. Quando os ponteiros estão íntegros, essa técnica oferece contexto e reduz falsos positivos.
A varredura, por outro lado, procura padrões compatíveis com objetos mesmo quando eles já não estão vinculados às estruturas principais.
Um candidato encontrado por varredura deve ser validado por um conjunto de propriedades, entre elas:
- cabeçalho e tipo do objeto;
- alinhamento;
- identificador de processo;
- nome da imagem;
- identificador do processo pai;
- horários de criação e encerramento;
- raiz das tabelas de páginas;
- número de threads;
- referências e contadores;
- ponteiros de listas;
- token de segurança;
- regiões virtuais associadas;
- páginas executáveis;
- presença de código compatível com PE ou outro formato esperado.
Quanto maior a convergência de propriedades independentes, maior a confiança de que o candidato corresponde a um objeto autêntico.
Regiões virtuais e propriedades de execução
A reconstrução do espaço virtual permite estudar como o processo organizava código, dados, pilhas, bibliotecas e arquivos mapeados.
No Windows, estruturas associadas aos descritores de endereços virtuais, frequentemente examinadas por meio da árvore VAD, ajudam a identificar:
- intervalo inicial e final;
- proteção da memória;
- região privada ou compartilhada;
- arquivo associado;
- páginas comprometidas;
- permissões de leitura, escrita e execução;
- relações entre regiões.
Regiões privadas com permissão de execução podem ser relevantes na investigação de injeção de código. Contudo, essa característica também pode surgir legitimamente em:
- compiladores just-in-time;
- navegadores;
- máquinas virtuais;
- mecanismos de proteção;
- empacotadores;
- sistemas de instrumentação;
- aplicações que geram código dinamicamente.
Uma classificação tecnicamente robusta deve combinar permissões com outros sinais:
- ausência de arquivo de origem;
- conteúdo executável reconhecível;
- divergências entre memória e arquivo;
- cabeçalhos reconstruídos;
- padrões de instruções;
- entropia;
- referências de threads;
- pontos de entrada;
- relações com chamadas de sistema;
- contexto comportamental.
Persistência residual de objetos e dados
A liberação de memória não implica apagamento imediato dos bytes. O sistema operacional pode marcar uma região como disponível e reutilizá-la posteriormente.
Por isso, uma imagem pode preservar:
- nomes de processos encerrados;
- fragmentos de comandos;
- objetos de kernel desalocados;
- credenciais temporárias;
- partes de executáveis;
- mensagens;
- endereços de rede;
- estruturas incompletas.
A busca textual é útil para localização inicial, mas oferece atribuição limitada. Uma cadeia de caracteres pode estar presente:
- no processo que a produziu;
- em um buffer compartilhado;
- no cache do sistema;
- em uma cópia feita por software de segurança;
- em memória já liberada;
- em uma região sem mapeamento ativo;
- em estrutura pertencente a outro processo.
A atribuição deve associar o conteúdo ao espaço virtual, ao objeto, à página e ao estado de alocação correspondente.
Temporalidade dos artefatos em memória
Algumas estruturas contêm horários de criação ou encerramento, mas a memória não oferece necessariamente uma linha temporal completa.
A análise deve relacionar:
- início e fim da aquisição;
- relógio do sistema;
- fuso horário;
- tempo de inicialização;
- horários de criação de processos;
- horários de encerramento;
- tempos de conexões;
- eventos persistidos em disco;
- registros de rede;
- dados de telemetria externa.
Quando a aquisição dura vários minutos, a própria ordem física das páginas copiadas pode influenciar o estado observado. Se a ferramenta registra o progresso ou a ordem dos intervalos lidos, essa informação pode auxiliar a avaliação de inconsistências.
A temporalidade deve ser apresentada como intervalo ou relação sustentada pelos artefatos, especialmente quando não existe uma fonte que estabeleça um instante preciso.
Exemplo de reconstrução de um processo
Considere uma análise na qual a varredura identifica um candidato a objeto de processo, mas o percurso da lista ativa não o apresenta.
Uma interpretação precipitada poderia classificá-lo imediatamente como processo oculto. O exame técnico deve avançar por etapas.
Primeiro, valida-se a estrutura:
- o objeto possui alinhamento compatível;
- seus campos principais apresentam valores plausíveis;
- o identificador não é meramente um fragmento aleatório;
- o nome da imagem é coerente;
- os ponteiros apontam para regiões válidas.
Em seguida, examina-se o estado:
- existe horário de encerramento;
- há threads ainda vinculadas;
- a raiz das tabelas de páginas permite tradução;
- as regiões virtuais podem ser reconstruídas;
- páginas executáveis continuam residentes;
- os identificadores permanecem ativos;
- há conexões associadas;
- outras estruturas referenciam o processo.
Um horário de encerramento coerente, ausência de threads ativas e páginas amplamente reutilizadas favorecem a hipótese de objeto residual.
Em contraste, tabelas de páginas funcionais, threads escalonáveis, identificadores ativos, regiões executáveis coerentes e referências contemporâneas podem justificar investigação de manipulação das listas.
Mesmo nesse segundo cenário, a conclusão deve distinguir:
- o objeto de processo foi encontrado;
- o objeto estava ausente de determinada lista;
- outros indicadores demonstram atividade;
- a causa da divergência foi avaliada.
Essa formulação preserva a separação entre observação, inferência e conclusão.
Validação cruzada e reprodutibilidade
Resultados relevantes devem ser confrontados por métodos que não dependam exatamente da mesma lógica.
A validação pode combinar:
- dois métodos de enumeração;
- exame manual das estruturas;
- tradução independente de endereços;
- diferentes plugins;
- outra ferramenta compatível;
- artefatos persistentes;
- registros de rede;
- telemetria de segurança;
- imagens de armazenamento;
- conjuntos de dados de referência.
Executar duas interfaces que utilizam a mesma biblioteca não constitui necessariamente validação independente. Se ambas dependem do mesmo algoritmo, da mesma tabela de símbolos e da mesma camada de tradução, podem reproduzir o mesmo erro.
A reprodutibilidade também depende do registro de:
- hash da imagem;
- formato;
- tamanho;
- ferramenta de aquisição;
- ferramenta de análise;
- versões;
- sistemas de símbolos;
- parâmetros;
- comandos;
- horário da análise;
- erros e advertências;
- critérios empregados na classificação.
Linguagem adequada ao relatório técnico
A redação deve expressar o grau de sustentação proporcionado pelos artefatos.
Uma afirmação como:
“O processo estava oculto.”
pode ultrapassar o que os dados demonstram.
Uma formulação tecnicamente mais precisa seria:
“Foi localizado, no deslocamento físico indicado, um candidato a objeto de processo com campos estruturalmente compatíveis. O objeto não foi alcançado pelo percurso da lista ativa, embora apresentasse raiz de tabelas de páginas válida e referências consistentes em estruturas de threads. A divergência é compatível com remoção da lista, sem excluir efeitos de aquisição, corrupção ou transição de estado.”
Essa redação identifica:
- a observação;
- o método empregado;
- os elementos de validação;
- a inferência possível;
- as hipóteses concorrentes;
- a limitação do exame.
Síntese e implicações técnico-forenses
A análise de memória volátil é um processo de reconstrução. Os bytes adquiridos precisam ser relacionados a endereços físicos, espaços virtuais, tabelas de páginas, símbolos, tipos e objetos do sistema operacional.
Uma imagem de RAM produzida em sistema ativo representa um intervalo de observação. Sua interpretação deve considerar memory smear, interferência da ferramenta, páginas ausentes, resíduos de objetos e mudanças ocorridas durante a coleta.
A confiabilidade não decorre da simples execução de um plugin. Ela emerge da convergência entre:
- compreensão do método de aquisição;
- validação das camadas de tradução;
- compatibilidade dos símbolos;
- reconstrução por múltiplas perspectivas;
- correlação com fontes externas;
- documentação das limitações;
- separação entre observação e inferência.
A memória pode revelar estados computacionais inacessíveis por outras fontes, mas exige uma leitura compatível com sua natureza dinâmica. Quanto mais relevante for a conclusão, maior deve ser o esforço de validação estrutural, temporal e metodológica.
Referências
- GRUHN, Michael; FREILING, Felix. Evaluating Atomicity and Integrity of Correct Memory Acquisition Methods. DFRWS Europe, 2016.
- VÖMEL, Stefan; FREILING, Felix. An Evaluation Platform for Forensic Memory Acquisition Software. DFRWS USA, 2013.
- SWGDE. Capture of Live Systems.
- SWGDE. Best Practices for Computer Forensic Acquisitions.
- NIST. Digital Investigation Techniques: A NIST Scientific Foundation Review — NIST IR 8354.
- VOLATILITY FOUNDATION. Volatility 3: documentação técnica.
- MICROSOFT. Virtual Address Spaces.
- MICROSOFT. Virtual Address Space and Physical Storage.