Le Registre : ruches, clés, horodatages LastWrite et journaux de transactions

Le Registre Windows est la base de données hiérarchique dans laquelle Windows et les applications conservent leur configuration et enregistrent, par effet de bord, une grande partie de l’activité des utilisateurs et du système. La plupart des leçons de ce module y extraient des éléments de preuve. Cette leçon présente les fondements : quels fichiers contiennent le Registre, comment ils correspondent aux clés visibles dans Regedit, comment le format de fichier stocke les clés et les valeurs, ce que prouve l’horodatage LastWrite d’une clé et pourquoi une ruche hors ligne doit être lue avec ses journaux de transactions. Elle s’applique à Windows 10 et 11.

Ruches et clés racines

Le Registre est une arborescence de clés (comparables à des dossiers) qui contiennent des valeurs (éléments de données nommés) et des sous-clés. Sur disque, il est divisé en ruches : des fichiers distincts, chacun chargé à un emplacement de l’arborescence. Regedit affiche cinq clés racines, mais seules deux sont de véritables racines : HKEY_LOCAL_MACHINE (HKLM) et HKEY_USERS (HKU). Les autres sont des vues. HKEY_CURRENT_USER (HKCU) est un lien vers HKU\<SID> de l’utilisateur connecté, HKEY_CLASSES_ROOT fusionne HKLM\SOFTWARE\Classes avec les classes de l’utilisateur, et HKEY_CURRENT_CONFIG pointe vers la ruche SYSTEM. Un SID (identificateur de sécurité) tel que S-1-5-21-…-1001 identifie un compte ; la leçon 2.2 traite des SID.

HKLM\HARDWARE ne possède aucun fichier : il s’agit d’une ruche volatile que Windows construit en mémoire à chaque démarrage à partir du matériel détecté ; elle n’apparaît donc jamais dans une image disque ni dans une collecte de triage. Amcache.hve utilise le même format de fichier, mais n’est monté sous aucune des clés racines affichées par Regedit ; la leçon 2.3 le présente.

Le dossier config contient également d’autres ruches, telles que COMPONENTS et DRIVERS. Les ruches d’un utilisateur ne sont chargées que pendant sa session.

CurrentControlSet dans une ruche hors ligne

Les guides citent des chemins tels que HKLM\SYSTEM\CurrentControlSet\Services, mais CurrentControlSet est un lien que Windows crée au démarrage ; il n’existe pas dans le fichier SYSTEM. Ce fichier contient des ensembles numérotés, généralement ControlSet001 et parfois ControlSet002. Pour savoir lequel était utilisé, consultez SYSTEM\Select : sa valeur DWORD Current en donne le numéro (1 signifie ControlSet001). La plupart des outils d’analyse résolvent automatiquement cette correspondance, mais lorsqu’un chemin exact est demandé, vérifiez Select et indiquez le véritable ensemble de contrôle.

Le format de fichier regf

Chaque fichier de ruche suit la même structure, souvent appelée regf d’après sa signature. Tous les entiers sont en petit-boutiste.

Bloc de base

Le fichier commence par un bloc de base (en-tête) de 4 096 octets :

Windows incrémente le numéro de séquence primaire avant d’écrire dans le fichier de ruche et attribue la même valeur au numéro secondaire lorsque l’écriture est terminée. Si les deux numéros diffèrent, la ruche est non synchronisée : la dernière écriture dans le fichier principal n’a pas été achevée, et les données actuelles peuvent n’exister que dans les journaux de transactions.

Blocs de ruche et cellules

Après le bloc de base viennent les blocs de ruche, chacun commençant par la signature hbin et ayant une taille multiple de 4 096 octets. Un bloc est divisé en cellules, chacune commençant par une taille signée sur 4 octets : une valeur négative indique une cellule allouée, une valeur positive une cellule libre. Les décalages des cellules sont relatifs au premier bloc ; le décalage dans le fichier est donc égal au décalage de la cellule plus 4 096.

Les principaux types de cellules sont :

• nk (nœud de clé) : une par clé : nom, horodatage LastWrite, décalage du parent, nombres et listes des sous-clés et des valeurs, et décalage de sa cellule de sécurité.
• vk (valeur de clé) : une par valeur : nom, type de données, taille des données et soit les données elles-mêmes (4 octets ou moins), soit le décalage de la cellule de données.
• Listes : listes de sous-clés (signatures lf, lh, li et ri) et listes de valeurs (simple tableau de décalages) ; les cellules db contiennent les données très volumineuses sous forme de segments.
• sk (clé de sécurité) : un descripteur de sécurité (propriétaire et autorisations), partagé par de nombreuses clés.

Le type de données d’une cellule vk indique comment lire les octets :

Horodatages LastWrite

Chaque cellule nk contient un FILETIME de 8 octets : un nombre d’intervalles de 100 nanosecondes depuis 1601-01-01 00:00:00 UTC. Windows le définit lors de la création de la clé et le met à jour chaque fois qu’une valeur de cette clé est ajoutée, modifiée ou supprimée ; l’ajout ou la suppression d’une sous-clé directe le met normalement à jour également. Trois conséquences en découlent :

• Seules les clés possèdent des horodatages. Les valeurs n’en ont pas. Lorsqu’une valeur contient une date et une heure (UserAssist, BAM, propriétés des périphériques USB), celles-ci font partie des données de la valeur et ont leur propre signification.
• Il indique quand, pas quoi. Un horodatage LastWrite indique qu’un élément de la clé a changé à cet instant, mais pas quelle valeur a changé ni de quelle manière. Si une clé possède dix valeurs, n’importe laquelle d’entre elles, ou une valeur supprimée depuis, peut expliquer cet horodatage.
• Il ne reflète que la modification la plus récente. Des versions plus anciennes de la clé peuvent subsister dans les clichés instantanés de volume (leçon 2.9) ou dans les journaux de transactions.

LastWrite est stocké en UTC, quel que soit le fuseau horaire du système. Soyez prudent face aux groupes d’horodatages identiques : les mises à jour de Windows peuvent réécrire de nombreuses clés simultanément, et les horodatages LastWrite peuvent être délibérément altérés (module 7).

Journaux de transactions et ruches non synchronisées

À côté de chaque fichier de ruche, Windows conserve deux journaux de transactions portant le même nom suivi de .LOG1 et .LOG2, par exemple SYSTEM.LOG1, SYSTEM.LOG2, NTUSER.DAT.LOG1 et UsrClass.dat.LOG2. Dans le profil utilisateur, ce sont des fichiers cachés. Windows 8.1 a introduit un nouveau format de journal, utilisé par Windows 10 et 11, dans lequel chaque entrée commence par la signature HvLE et contient les pages modifiées avec leurs propres numéros de séquence.

Depuis ce changement, Windows écrit d’abord les modifications dans les journaux, puis les transfère dans le fichier de ruche principal ultérieurement, parfois bien plus tard. Une ruche copiée depuis un système en fonctionnement, comme lors d’une collecte de triage à chaud, est donc souvent non synchronisée, et ses modifications les plus récentes (une nouvelle valeur Run, un périphérique USB tout juste connecté) peuvent n’exister que dans les journaux. Le fichier principal seul fournit un état plus ancien.

Pour cette raison :

• Une collecte de triage doit inclure les fichiers .LOG1 et .LOG2 de chaque ruche, collectés en même temps que celle-ci. Une collecte de triage les conserve normalement à côté de chaque ruche, à son chemin d’origine.
• Rejouez les journaux avant l’analyse. Registry Explorer détecte une ruche non synchronisée et propose de rejouer les journaux dans une copie synchronisée. RECmd rejoue les journaux qu’il trouve à côté de la ruche. La bibliothèque Python yarp, de Maxim Suhanov, peut appliquer les journaux et récupérer des données. RegRipper analyse le fichier principal tel quel ; rejouez donc d’abord les journaux, puis exécutez-le sur la copie synchronisée.
• Rejouez les journaux dans un nouveau fichier, jamais dans votre unique copie, et consignez les journaux utilisés.

Clés et valeurs supprimées

Lorsqu’une clé ou une valeur est supprimée, Windows marque ses cellules comme libres (taille positive), mais ne les écrase pas nécessairement. Tant que l’espace n’est pas réutilisé, les cellules nk, vk et de données restent lisibles, y compris le nom et l’horodatage LastWrite de la clé supprimée. Registry Explorer et yarp récupèrent ces clés et valeurs. Une clé récupérée sans parent valide est affichée comme non associée : son contenu est réel, mais son emplacement d’origine peut être inconnu.

RegBack

C:\Windows\System32\config\RegBack contenait autrefois des copies de sauvegarde périodiques des ruches système. Depuis Windows 10 version 1803, Windows n’alimente plus ces copies par défaut : le dossier est généralement présent, mais vide ou contenant des fichiers de zéro octet. Microsoft documente une valeur, EnablePeriodicBackup, qui réactive la sauvegarde ; vérifiez donc la taille et les dates des fichiers avant d’écarter ce dossier.

Outils

Registry Explorer permet de parcourir les ruches, de rejouer les journaux, d’afficher les cellules supprimées et de décoder de nombreuses valeurs. RECmd est son équivalent en ligne de commande ; avec un fichier de traitement par lots (par exemple Kroll_Batch.reb), il extrait un ensemble défini de clés de nombreuses ruches vers un fichier CSV. RegRipper exécute des greffons qui produisent chacun un rapport sur un artefact. yarp convient à l’analyse et à la récupération par scripts. Utilisez un éditeur hexadécimal lorsqu’une réponse exacte dépend des octets bruts.

Exemple détaillé : décodage d’un horodatage LastWrite

Dans un fichier NTUSER.DAT synchronisé, vous examinez la clé Software\Microsoft\Windows\CurrentVersion\Run. Elle contient deux valeurs, OneDrive et updater. Le début de sa cellule nk se présente ainsi :

Ordre des octets. Inversez les huit octets en petit-boutiste : 0x01DCB39A655DBDD0 = 134 179 564 621 250 000.

Unités. Divisez par 10 000 000 (intervalles de 100 ns par seconde) : 13 417 956 462,125 secondes depuis 1601-01-01.

Origine temporelle. Soustrayez 11 644 473 600 secondes (de 1601-01-01 à 1970-01-01) : temps Unix 1 773 482 862,125.

Date et heure. 1 773 482 862 ÷ 86 400 = 20 526 jours, reste 36 462 s. Le jour 20 526 après 1970-01-01 est le 2026-03-14 ; 36 462 s = 10 h 07 min 42 s. L’horodatage LastWrite est 2026-03-14T10:07:42.125Z.

Ce qu’il prouve. Un élément sous la clé Run a été ajouté, modifié ou supprimé à 10:07:42Z, et il s’agit de la modification de ce type la plus récente.

Ce qu’il ne prouve pas. Il ne montre pas que updater a été ajouté à ce moment-là : OneDrive a pu réécrire sa propre valeur, ou une troisième valeur a pu être supprimée. Il ne montre ni que le programme a été exécuté, ni qui a effectué la modification. Pour l’attribuer, comparez avec une copie plus ancienne de la clé (cliché instantané ou entrées de journal), consultez la $MFT et le journal USN pour le fichier vers lequel pointe updater, et recherchez des éléments de preuve d’exécution (leçon 2.3).

Points clés pour l'examen : Attendez-vous à devoir associer un artefact au bon fichier de ruche et à son chemin dans une collecte de triage, à résoudre CurrentControlSet à l’aide de SYSTEM\Select, et à indiquer en UTC l’horodatage LastWrite d’une clé issue d’une ruche dont les journaux doivent d’abord être rejoués. Les questions peuvent porter sur la règle des numéros de séquence des ruches non synchronisées, sur le fait que les valeurs n’ont pas d’horodatage, et sur ce qu’un horodatage LastWrite permet ou non d’étayer.

Points essentiels

• Les ruches sont des fichiers : SYSTEM, SOFTWARE, SAM, SECURITY et DEFAULT dans System32\config ; NTUSER.DAT et UsrClass.dat dans chaque profil. HKLM\HARDWARE est construit en mémoire au démarrage.
• Hors ligne, CurrentControlSet n’existe pas ; SYSTEM\Select\Current désigne le ControlSet00n à utiliser.
• Les fichiers regf commencent par un bloc de base de 4 096 octets ; des numéros de séquence primaire et secondaire différents indiquent une ruche non synchronisée. Les données se trouvent dans les blocs hbin, sous forme de cellules nk, vk, de liste et sk.
• Seules les clés possèdent un FILETIME LastWrite (UTC) ; il indique quand un élément de la clé a été modifié pour la dernière fois, mais pas lequel.
• Collectez et rejouez .LOG1/.LOG2 avant l’analyse ; les modifications récentes peuvent n’exister que dans les journaux.
• Les clés et valeurs supprimées subsistent souvent dans les cellules libres ; les copies RegBack ne sont plus alimentées par défaut depuis Windows 10 version 1803.