O Registro: hives, chaves, horários LastWrite e logs de transações

O Registro do Windows é o banco de dados hierárquico no qual o Windows e os aplicativos mantêm configurações e no qual registram, como efeito colateral, grande parte da atividade do usuário e do sistema. A maioria das aulas deste módulo lê evidências dele. Esta aula aborda os fundamentos: quais arquivos contêm o Registro, como eles correspondem às chaves vistas no Regedit, como o formato de arquivo armazena chaves e valores, o que o horário LastWrite de uma chave comprova e por que uma hive offline deve ser lida com seus logs de transações. Ela se aplica ao Windows 10 e 11.

Hives e chaves raiz

O Registro é uma árvore de chaves (como pastas) que contêm valores (itens de dados nomeados) e subchaves. No disco, ele é dividido em hives: arquivos separados, cada um carregado em um ponto da árvore. O Regedit mostra cinco chaves raiz, mas apenas duas são raízes reais: HKEY_LOCAL_MACHINE (HKLM) e HKEY_USERS (HKU). As outras são visualizações. HKEY_CURRENT_USER (HKCU) é um link para HKU\<SID> do usuário conectado, HKEY_CLASSES_ROOT mescla HKLM\SOFTWARE\Classes com as classes do usuário e HKEY_CURRENT_CONFIG aponta para dentro da hive SYSTEM. Um SID (identificador de segurança), como S-1-5-21-…-1001, identifica uma conta; a Aula 2.2 aborda os SIDs.

HKLM\HARDWARE não tem arquivo algum: é uma hive volátil que o Windows cria na memória a cada inicialização a partir do hardware detectado, portanto nunca aparece em uma imagem de disco ou coleta de triagem. Amcache.hve usa o mesmo formato de arquivo, mas não é montado sob nenhuma chave raiz exibida pelo Regedit; a Aula 2.3 o aborda.

A pasta config também contém outras hives, como COMPONENTS e DRIVERS. As hives de um usuário são carregadas apenas enquanto esse usuário está conectado.

CurrentControlSet em uma hive offline

Os guias citam caminhos como HKLM\SYSTEM\CurrentControlSet\Services, mas CurrentControlSet é um link que o Windows cria na inicialização; ele não existe no arquivo SYSTEM. O arquivo contém conjuntos numerados, geralmente ControlSet001 e, às vezes, ControlSet002. Para saber qual estava em uso, leia SYSTEM\Select: seu valor DWORD Current fornece o número (1 significa ControlSet001). A maioria dos analisadores resolve isso automaticamente, mas, quando a resposta exige um caminho exato, verifique Select e informe o conjunto de controle real.

O formato de arquivo regf

Todos os arquivos de hive seguem o mesmo layout, frequentemente chamado de regf por causa de sua assinatura. Todos os inteiros são little-endian.

Bloco base

O arquivo começa com um bloco base (cabeçalho) de 4.096 bytes:

O Windows incrementa o número de sequência primário antes de gravar no arquivo de hive e define o número secundário com o mesmo valor quando a gravação é concluída. Se os dois números forem diferentes, a hive está suja: a última gravação no arquivo primário não foi concluída, e os dados atuais podem existir apenas nos logs de transações.

Bins de hive e células

Após o bloco base vêm os bins de hive, cada um começando com a assinatura hbin e com tamanho em múltiplos de 4.096 bytes. Um bin é dividido em células, cada uma começando com um tamanho com sinal de 4 bytes: negativo significa alocada, positivo significa livre. Os offsets das células são relativos ao primeiro bin, portanto o offset no arquivo é o offset da célula mais 4.096.

Os principais tipos de células são:

• nk (nó de chave): uma por chave: nome, horário LastWrite, offset da chave pai, contagens e listas de subchaves e valores, e o offset de sua célula de segurança.
• vk (chave de valor): uma por valor: nome, tipo de dados, tamanho dos dados e os próprios dados (4 bytes ou menos) ou o offset da célula de dados.
• Listas: listas de subchaves (assinaturas lf, lh, li e ri) e listas de valores (um vetor simples de offsets); células db contêm dados muito grandes em segmentos.
• sk (chave de segurança): um descritor de segurança (proprietário e permissões), compartilhado por muitas chaves.

O tipo de dados em uma célula vk informa como ler os bytes:

Horários LastWrite

Cada célula nk contém um FILETIME de 8 bytes: uma contagem de intervalos de 100 nanossegundos desde 1601-01-01 00:00:00 UTC. O Windows o define quando a chave é criada e o atualiza sempre que um valor nessa chave é adicionado, modificado ou excluído; adicionar ou excluir uma subchave direta normalmente também o atualiza. Disso decorrem três consequências:

• Somente chaves têm carimbos de data/hora. Valores não têm nenhum. Quando um valor contém um horário (UserAssist, BAM, propriedades de dispositivos USB), ele faz parte dos dados do valor e tem seu próprio significado.
• Ele informa quando, não o quê. Um horário LastWrite indica que algo na chave mudou naquele momento, não qual valor mudou nem como. Se uma chave tem dez valores, qualquer um deles, ou um valor excluído desde então, pode ser responsável por isso.
• Ele reflete apenas a alteração mais recente. Versões anteriores da chave podem sobreviver em Cópias de Sombra de Volume (Aula 2.9) ou nos logs de transações.

LastWrite é armazenado em UTC, independentemente do fuso horário do sistema. Tenha cautela com grupos de horários idênticos: atualizações do Windows podem regravar muitas chaves de uma só vez, e os horários LastWrite podem ser alterados deliberadamente (Módulo 7).

Logs de transações e hives sujas

Ao lado de cada arquivo de hive, o Windows mantém dois logs de transações com o mesmo nome acrescido de .LOG1 e .LOG2, por exemplo, SYSTEM.LOG1, SYSTEM.LOG2, NTUSER.DAT.LOG1 e UsrClass.dat.LOG2. No perfil do usuário, eles são arquivos ocultos. O Windows 8.1 introduziu um novo formato de log, usado pelo Windows 10 e 11, no qual cada entrada de log começa com a assinatura HvLE e contém as páginas sujas com seus próprios números de sequência.

Desde essa mudança, o Windows grava as modificações primeiro nos logs e as descarrega no arquivo de hive primário mais tarde, às vezes muito mais tarde. Uma hive copiada de um sistema em execução, como em uma coleta de triagem ao vivo, portanto, costuma estar suja, e suas alterações mais recentes (um novo valor Run, um dispositivo USB recém-conectado) podem existir apenas nos logs. O arquivo primário sozinho fornece um estado anterior.

Por esse motivo:

• Uma coleta de triagem deve incluir .LOG1 e .LOG2 para cada hive, coletados ao mesmo tempo que a hive. Uma coleta de triagem normalmente os mantém ao lado de cada hive em seu caminho original.
• Reaplique os logs antes da análise. O Registry Explorer detecta uma hive suja e oferece a opção de reaplicar os logs em uma cópia limpa. O RECmd reaplica os logs que encontra ao lado da hive. A biblioteca Python yarp, de Maxim Suhanov, pode aplicar logs e recuperar dados. O RegRipper analisa o arquivo primário como ele está, portanto reaplique os logs primeiro e execute-o na cópia limpa.
• Reaplique em um novo arquivo, nunca em sua única cópia, e registre quais logs você usou.

Chaves e valores excluídos

Quando uma chave ou um valor é excluído, o Windows marca suas células como livres (tamanho positivo), mas não necessariamente as sobrescreve. Até que o espaço seja reutilizado, as células nk, vk e de dados permanecem legíveis, incluindo o nome e o horário LastWrite da chave excluída. O Registry Explorer e o yarp recuperam essas chaves e esses valores. Uma chave recuperada sem uma chave pai válida é exibida como não associada: seu conteúdo é real, mas sua localização original pode ser desconhecida.

RegBack

C:\Windows\System32\config\RegBack antes continha cópias de backup periódicas das hives do sistema. Desde o Windows 10 versão 1803, o Windows não gera mais essas cópias por padrão: a pasta geralmente está presente, mas vazia ou com arquivos de zero byte. A Microsoft documenta um valor, EnablePeriodicBackup, que reativa o backup, portanto verifique os tamanhos e as datas dos arquivos antes de descartar a pasta.

Ferramentas

O Registry Explorer permite navegar pelas hives, reaplica logs, mostra células excluídas e decodifica muitos valores. O RECmd é seu equivalente de linha de comando; com um arquivo em lote (por exemplo, Kroll_Batch.reb), ele extrai um conjunto definido de chaves de muitas hives para CSV. O RegRipper executa plugins que relatam um artefato cada. O yarp é adequado para análise e recuperação por scripts. Use um editor hexadecimal quando uma resposta exata depender dos bytes brutos.

Exemplo resolvido: decodificando um horário LastWrite

Em um NTUSER.DAT limpo, você examina a chave Software\Microsoft\Windows\CurrentVersion\Run. Ela contém dois valores, OneDrive e updater. O início de sua célula nk apresenta:

Ordem dos bytes. Inverta os oito bytes little-endian: 0x01DCB39A655DBDD0 = 134.179.564.621.250.000.

Unidades. Divida por 10.000.000 (intervalos de 100-ns por segundo): 13.417.956.462,125 segundos desde 1601-01-01.

Época. Subtraia 11.644.473.600 segundos (de 1601-01-01 a 1970-01-01): tempo Unix 1.773.482.862,125.

Data e hora. 1.773.482.862 ÷ 86.400 = 20.526 dias, resto de 36.462 s. O dia 20.526 após 1970-01-01 é 2026-03-14; 36.462 s = 10 h 07 min 42 s. O horário LastWrite é 2026-03-14T10:07:42.125Z.

O que isso comprova. Algo sob a chave Run foi adicionado, alterado ou excluído às 10:07:42Z, e essa é a alteração desse tipo mais recente.

O que isso não comprova. Isso não mostra que updater foi adicionado naquele momento: o OneDrive pode ter regravado seu próprio valor, ou um terceiro valor pode ter sido excluído. Não mostra que o programa foi executado, nem quem fez a alteração. Para atribuí-la, compare com uma cópia anterior da chave (cópia de sombra ou entradas de log), verifique a $MFT e o diário USN em busca do arquivo para o qual updater aponta e procure evidências de execução (Aula 2.3).

Foco no exame: Espere ter de associar um artefato ao arquivo de hive correto e ao seu caminho em uma coleta de triagem, resolver CurrentControlSet por meio de SYSTEM\Select e informar o horário LastWrite de uma chave em UTC a partir de uma hive cujos logs devem ser reaplicados primeiro. As questões podem testar a regra dos números de sequência para hives sujas, o fato de que valores não têm carimbos de data/hora e o que um horário LastWrite pode ou não sustentar.

Pontos principais

• Hives são arquivos: SYSTEM, SOFTWARE, SAM, SECURITY e DEFAULT em System32\config; NTUSER.DAT e UsrClass.dat em cada perfil. HKLM\HARDWARE é criada na memória na inicialização.
• Offline, não há CurrentControlSet; SYSTEM\Select\Current identifica o ControlSet00n a ser usado.
• Arquivos regf começam com um bloco base de 4.096 bytes; números de sequência primário e secundário diferentes indicam uma hive suja. Os dados ficam em bins hbin como células nk, vk, de lista e sk.
• Somente chaves têm um FILETIME LastWrite (UTC); ele mostra quando algo na chave foi alterado pela última vez, não o quê.
• Colete e reaplique .LOG1/.LOG2 antes da análise; alterações recentes podem existir apenas nos logs.
• Chaves e valores excluídos frequentemente sobrevivem em células livres; cópias do RegBack não são geradas por padrão desde o Windows 10 versão 1803.