Il Registro di sistema: hive, chiavi, orari LastWrite e log delle transazioni

Il Registro di sistema di Windows è il database gerarchico in cui Windows e le applicazioni conservano la configurazione e in cui registrano, come effetto collaterale, gran parte dell'attività degli utenti e del sistema. La maggior parte delle lezioni di questo modulo ne esamina le evidenze. Questa lezione tratta i fondamenti: quali file contengono il Registro di sistema, come corrispondono alle chiavi visualizzate in Regedit, come il formato dei file memorizza chiavi e valori, che cosa dimostra l'orario LastWrite di una chiave e perché un hive offline deve essere letto insieme ai relativi log delle transazioni. Si applica a Windows 10 e 11.

Hive e chiavi radice

Il Registro di sistema è un albero di chiavi (simili a cartelle) che contengono valori (elementi di dati dotati di nome) e sottochiavi. Su disco è suddiviso in hive: file separati, ciascuno caricato in un punto dell'albero. Regedit mostra cinque chiavi radice, ma soltanto due sono radici effettive: HKEY_LOCAL_MACHINE (HKLM) e HKEY_USERS (HKU). Le altre sono viste. HKEY_CURRENT_USER (HKCU) è un collegamento a HKU\<SID> dell'utente connesso, HKEY_CLASSES_ROOT unisce HKLM\SOFTWARE\Classes alle classi dell'utente e HKEY_CURRENT_CONFIG punta all'interno dell'hive SYSTEM. Un SID (identificatore di sicurezza), come S-1-5-21-…-1001, identifica un account; la lezione 2.2 tratta i SID.

HKLM\HARDWARE non ha alcun file: è un hive volatile che Windows costruisce in memoria a ogni avvio a partire dall'hardware rilevato, quindi non compare mai in un'immagine disco o in un'acquisizione di triage. Amcache.hve utilizza lo stesso formato di file, ma non viene montato sotto alcuna chiave radice visualizzata da Regedit; la lezione 2.3 lo tratta.

La cartella config contiene anche altri hive, come COMPONENTS e DRIVERS. Gli hive di un utente vengono caricati soltanto mentre l'utente è connesso.

CurrentControlSet in un hive offline

Le guide riportano percorsi come HKLM\SYSTEM\CurrentControlSet\Services, ma CurrentControlSet è un collegamento creato da Windows all'avvio; non esiste nel file SYSTEM. Il file contiene set numerati, solitamente ControlSet001 e talvolta ControlSet002. Per sapere quale fosse in uso, leggere SYSTEM\Select: il suo valore DWORD Current fornisce il numero (1 indica ControlSet001). La maggior parte dei parser risolve automaticamente questo riferimento, ma quando la risposta richiede un percorso esatto, verificare Select e indicare il set di controllo effettivo.

Il formato di file regf

Ogni file hive segue la stessa struttura, spesso chiamata regf dalla sua firma. Tutti gli interi sono little-endian.

Blocco di base

Il file inizia con un blocco di base (intestazione) di 4.096 byte:

Windows incrementa il numero di sequenza primario prima di scrivere nel file hive e imposta il numero secondario sullo stesso valore al completamento della scrittura. Se i due numeri differiscono, l'hive è dirty: l'ultima scrittura nel file primario non è stata completata e i dati aggiornati potrebbero esistere soltanto nei log delle transazioni.

Bin dell'hive e celle

Dopo il blocco di base si trovano i bin dell'hive, ciascuno dei quali inizia con la firma hbin e ha una dimensione multipla di 4.096 byte. Un bin è suddiviso in celle, ciascuna delle quali inizia con una dimensione con segno di 4 byte: negativa indica una cella allocata, positiva una cella libera. Gli offset delle celle sono relativi al primo bin, quindi l'offset nel file è pari all'offset della cella più 4.096.

I principali tipi di cella sono:

• nk (nodo di chiave): una per chiave: nome, orario LastWrite, offset della chiave padre, conteggi ed elenchi di sottochiavi e valori e offset della relativa cella di sicurezza.
• vk (chiave di valore): una per valore: nome, tipo di dati, dimensione dei dati e i dati stessi (4 byte o meno) oppure l'offset della cella dei dati.
• Elenchi: elenchi di sottochiavi (firme lf, lh, li e ri) ed elenchi di valori (un semplice array di offset); le celle db contengono dati molto grandi suddivisi in segmenti.
• sk (chiave di sicurezza): un descrittore di sicurezza (proprietario e autorizzazioni), condiviso da molte chiavi.

Il tipo di dati in una cella vk indica come leggere i byte:

Orari LastWrite

Ogni cella nk contiene un FILETIME di 8 byte: un conteggio di intervalli di 100 nanosecondi a partire dal 1601-01-01 00:00:00 UTC. Windows lo imposta quando viene creata la chiave e lo aggiorna ogni volta che un valore di quella chiave viene aggiunto, modificato o eliminato; normalmente anche l'aggiunta o l'eliminazione di una sottochiave diretta lo aggiorna. Ne derivano tre conseguenze:

• Soltanto le chiavi hanno marche temporali. I valori non ne hanno. Quando un valore contiene un orario (UserAssist, BAM, proprietà dei dispositivi USB), questo fa parte dei dati del valore e ha un proprio significato.
• Indica quando, non che cosa. Un orario LastWrite indica che qualcosa nella chiave è cambiato in quel momento, non quale valore sia cambiato o in che modo. Se una chiave ha dieci valori, uno qualsiasi di essi, oppure un valore successivamente eliminato, potrebbe esserne la causa.
• Riflette soltanto la modifica più recente. Versioni precedenti della chiave potrebbero sopravvivere nelle copie shadow del volume (lezione 2.9) o nei log delle transazioni.

LastWrite viene memorizzato in UTC indipendentemente dal fuso orario del sistema. Occorre cautela con i gruppi di orari identici: gli aggiornamenti di Windows possono riscrivere molte chiavi contemporaneamente e gli orari LastWrite possono essere alterati deliberatamente (modulo 7).

Log delle transazioni e hive dirty

Accanto a ciascun file hive, Windows conserva due log delle transazioni con lo stesso nome più .LOG1 e .LOG2, ad esempio SYSTEM.LOG1, SYSTEM.LOG2, NTUSER.DAT.LOG1 e UsrClass.dat.LOG2. Nel profilo utente sono file nascosti. Windows 8.1 ha introdotto un nuovo formato di log, utilizzato da Windows 10 e 11, in cui ogni voce di log inizia con la firma HvLE e contiene le pagine modificate con i rispettivi numeri di sequenza.

Da questa modifica, Windows scrive le modifiche prima nei log e le trasferisce nel file hive primario in seguito, talvolta molto più tardi. Un hive copiato da un sistema in esecuzione, come avviene in un'acquisizione di triage dal vivo, è quindi spesso dirty e le sue modifiche più recenti (un nuovo valore Run, un dispositivo USB appena collegato) potrebbero esistere soltanto nei log. Il solo file primario fornisce uno stato precedente.

Per questo motivo:

• Un'acquisizione di triage deve includere .LOG1 e .LOG2 per ogni hive, acquisiti contemporaneamente all'hive. Un'acquisizione di triage normalmente li conserva accanto a ciascun hive nel relativo percorso originale.
• Riapplicare i log prima dell'analisi. Registry Explorer rileva un hive dirty e propone di riapplicare i log in una copia ripristinata. RECmd riapplica i log che trova accanto all'hive. La libreria Python yarp, di Maxim Suhanov, può applicare i log e recuperare dati. RegRipper analizza il file primario così com'è, quindi occorre prima riapplicare i log ed eseguirlo sulla copia ripristinata.
• Riapplicare i log in un nuovo file, mai nell'unica copia disponibile, e registrare quali log sono stati utilizzati.

Chiavi e valori eliminati

Quando una chiave o un valore viene eliminato, Windows contrassegna le relative celle come libere (dimensione positiva), ma non le sovrascrive necessariamente. Finché lo spazio non viene riutilizzato, le celle nk, vk e dei dati rimangono leggibili, compresi il nome e l'orario LastWrite della chiave eliminata. Registry Explorer e yarp recuperano tali chiavi e valori. Una chiave recuperata priva di un padre valido viene mostrata come non associata: il suo contenuto è reale, ma la sua posizione originale potrebbe essere sconosciuta.

RegBack

C:\Windows\System32\config\RegBack conteneva in passato copie di backup periodiche degli hive di sistema. Da Windows 10 versione 1803, Windows non genera più queste copie per impostazione predefinita: la cartella è solitamente presente ma vuota oppure contiene file di zero byte. Microsoft documenta un valore, EnablePeriodicBackup, che riattiva il backup, quindi verificare dimensioni e date dei file prima di escludere la cartella.

Strumenti

Registry Explorer consente di esplorare gli hive, riapplicare i log, visualizzare le celle eliminate e decodificare molti valori. RECmd è la sua controparte a riga di comando; con un file batch (ad esempio Kroll_Batch.reb) estrae in CSV un insieme definito di chiavi da molti hive. RegRipper esegue plugin, ciascuno dei quali produce un resoconto su un artefatto. yarp è adatto all'analisi e al recupero tramite script. Utilizzare un editor esadecimale quando una risposta esatta dipende dai byte grezzi.

Esempio svolto: decodifica di un orario LastWrite

In un NTUSER.DAT ripristinato si esamina la chiave Software\Microsoft\Windows\CurrentVersion\Run. Contiene due valori, OneDrive e updater. L'inizio della sua cella nk riporta:

Ordine dei byte. Invertire gli otto byte little-endian: 0x01DCB39A655DBDD0 = 134.179.564.621.250.000.

Unità. Dividere per 10.000.000 (intervalli di 100-ns al secondo): 13.417.956.462,125 secondi dal 1601-01-01.

Epoca. Sottrarre 11.644.473.600 secondi (dal 1601-01-01 al 1970-01-01): tempo Unix 1.773.482.862,125.

Data e ora. 1.773.482.862 ÷ 86.400 = 20.526 giorni, resto 36.462 s. Il giorno 20.526 dopo il 1970-01-01 è il 2026-03-14; 36.462 s = 10 h 07 min 42 s. L'orario LastWrite è 2026-03-14T10:07:42.125Z.

Che cosa dimostra. Qualcosa nella chiave Run è stato aggiunto, modificato o eliminato alle 10:07:42Z e questa è la modifica più recente di questo tipo.

Che cosa non dimostra. Non dimostra che updater sia stato aggiunto in quel momento: OneDrive potrebbe aver riscritto il proprio valore, oppure un terzo valore potrebbe essere stato eliminato. Non dimostra che il programma sia stato eseguito, né chi abbia apportato la modifica. Per attribuirla, confrontare con una copia precedente della chiave (copia shadow o voci di log), verificare la $MFT e il journal USN per il file a cui punta updater e cercare evidenze di esecuzione (lezione 2.3).

Focus sull'esame: È necessario saper associare un artefatto al file hive corretto e al relativo percorso in un'acquisizione di triage, risolvere CurrentControlSet tramite SYSTEM\Select e riportare l'orario LastWrite di una chiave in UTC a partire da un hive i cui log devono essere prima riapplicati. Le domande possono verificare la regola dei numeri di sequenza per gli hive dirty, il fatto che i valori non abbiano marche temporali e quali conclusioni un orario LastWrite possa o non possa supportare.

Punti chiave

• Gli hive sono file: SYSTEM, SOFTWARE, SAM, SECURITY e DEFAULT in System32\config; NTUSER.DAT e UsrClass.dat in ciascun profilo. HKLM\HARDWARE viene costruito in memoria all'avvio.
• Offline non esiste CurrentControlSet; SYSTEM\Select\Current indica il ControlSet00n da utilizzare.
• I file regf iniziano con un blocco di base di 4.096 byte; numeri di sequenza primario e secondario diversi indicano un hive dirty. I dati risiedono nei bin hbin sotto forma di celle nk, vk, di elenco e sk.
• Soltanto le chiavi hanno un FILETIME LastWrite (UTC); indica quando qualcosa nella chiave è stato modificato per l'ultima volta, non che cosa.
• Acquisire e riapplicare .LOG1/.LOG2 prima dell'analisi; le modifiche recenti potrebbero esistere soltanto nei log.
• Le chiavi e i valori eliminati spesso sopravvivono nelle celle libere; le copie RegBack non vengono generate per impostazione predefinita da Windows 10 versione 1803.