Architecture et structure¶

Ce que vous allez apprendre¶

• Comment Windows gere le registre en coulisses (le Configuration Manager)
• La structure binaire interne d'un fichier de ruche
• Le systeme de cellules, bacs et en-tetes
• Comment la journalisation protege vos donnees contre la corruption
• Les limites techniques du registre

Vue d'ensemble : qui gere le registre ?¶

Quand vous appelez reg query, votre commande traverse trois couches avant d'atteindre le fichier sur le disque :

graph TD
    A["Votre application<br/><small>reg.exe, Regedit, PowerShell...</small>"] -->|API Win32<br/>RegOpenKeyEx, RegQueryValueEx| B["advapi32.dll / kernelbase.dll<br/><small>Mode utilisateur</small>"]
    B -->|Appels systeme<br/>NtOpenKey, NtSetValueKey| C["Configuration Manager<br/><small>ntoskrnl.exe — Mode noyau</small>"]
    C --> D["Cache en memoire<br/><small>Acces rapide</small>"]
    C --> E["Fichiers de ruches<br/><small>Sur le disque</small>"]
    E --> F["Journaux .LOG<br/><small>Protection anti-corruption</small>"]

Le Configuration Manager (CmpMgr) est un composant du noyau Windows (ntoskrnl.exe). C'est lui qui charge, met en cache, synchronise et enregistre les ruches.

Structure interne d'une ruche¶

Un fichier de ruche (ex : SYSTEM, SOFTWARE) est un fichier binaire structure. Ouvrons le capot.

L'en-tete (Base Block) : la carte d'identite¶

Les 4 096 premiers octets du fichier contiennent les metadonnees de la ruche. C'est sa carte d'identite.

Les cellules (Cells) : les briques de base¶

Apres l'en-tete, toutes les donnees sont organisees en cellules. Chaque cellule commence par un entier signe de 4 octets indiquant sa taille :

Les principaux types de cellules :

Les bacs (Bins) : les conteneurs¶

Les cellules sont regroupees dans des bacs (bins). Chaque bac fait un multiple de 4 096 octets (taille d'une page memoire).

Voici comment tout s'emboite :

graph TD
    subgraph Fichier de ruche
        A["En-tete<br/><code>regf</code><br/>4 096 octets"]
        subgraph "Bac 1 — hbin"
            B["Cellule nk<br/><small>Cle racine</small>"]
            C["Cellule vk<br/><small>Valeur</small>"]
            D["Cellule sk<br/><small>Securite</small>"]
        end
        subgraph "Bac 2 — hbin"
            E["Cellule nk<br/><small>Sous-cle</small>"]
            F["Cellule vk<br/><small>Valeur</small>"]
            G["Cellule libre"]
        end
    end
    A --> B
    B --> E

Le Configuration Manager en detail¶

Chargement des ruches : un ballet ordonne¶

Les ruches ne sont pas toutes chargees en meme temps. Le demarrage suit un ordre precis :

sequenceDiagram
    participant B as Bootloader
    participant K as Noyau Windows
    participant S as Session utilisateur
    B->>K: 1. Charge SYSTEM + BCD
    K->>K: 2. Initialise le Configuration Manager
    K->>K: 3. Charge SOFTWARE, SAM, SECURITY, DEFAULT
    S->>K: 4. Ouverture de session
    K->>K: 5. Charge NTUSER.DAT de l'utilisateur

Cache en memoire : la vitesse avant tout¶

Le Configuration Manager ne lit pas le disque a chaque acces. Il utilise un cache en memoire :

• Les bacs sont mappes en memoire a la demande
• Les bacs frequemment accedes restent en memoire
• Un mecanisme appele lazy flusher ecrit les modifications sur le disque de maniere asynchrone (toutes les quelques secondes)

Clés volatiles : ce qui ne touche jamais le disque¶

Toutes les clés du registre ne correspondent pas à un stockage persistant sur disque. Certaines sont volatiles : elles existent uniquement en mémoire et ne sont jamais écrites dans un fichier de ruche.

Au niveau API Win32, ce comportement est demandé avec le flag REG_OPTION_VOLATILE lors d'un appel comme RegCreateKeyEx. La clé est alors créée dans l'espace du registre en mémoire, mais sans support persistant.

Concrètement :

• elle apparaît normalement dans Regedit ou via PowerShell
• elle peut contenir des sous-clés et des valeurs
• elle disparaît entièrement à l'arrêt de Windows ou au redémarrage

Windows utilise ce mécanisme pour exposer des informations transitoires, liées à l'état courant de la machine plutôt qu'à une configuration durable.

Exemples classiques de zones volatiles :

• HKLM\HARDWARE : entièrement volatile, reconstruite à partir de la détection matérielle à chaque boot
• HKCU\Software\Classes\Local Settings : certaines branches sont temporaires ou recalculées
• certaines clés de registration COM temporaires créées par des applications

# HARDWARE hive has no backing file — it's pure memory
(Get-Item "HKLM:\HARDWARE").GetType().Name

# Try to export it — will succeed in Regedit but the exported .reg is a snapshot
reg export "HKLM\HARDWARE" "$env:TEMP\hardware_snapshot.reg" /y

L'export réussit, mais le fichier capturé reflète l'état au moment de l'export.
À chaque redémarrage, HKLM\HARDWARE est entièrement reconstruit par le noyau.

Etat propre et etat sale (dirty/clean)¶

Une ruche en memoire peut etre dans deux etats :

Quand une application modifie une valeur, le Configuration Manager marque la ruche comme dirty. Un flag specifique dans l'en-tete (base block) est positionne pour indiquer cet etat.

Le mecanisme CmpFlushNotify est charge de notifier le systeme qu'une ruche a ete modifiee et doit etre synchronisee.

Ce qui se passe a l'arret normal¶

1. Windows envoie un signal d'arret a tous les services
2. Le Configuration Manager effectue un flush de toutes les ruches dirty
3. Chaque ruche est ecrite sur le disque via le processus de journalisation
4. Les flags dirty sont remis a zero
5. L'arret se termine proprement

Ce qui se passe en cas de crash¶

1. La ruche reste dans un etat dirty sur le disque (Sequence 1 ≠ Sequence 2)
2. Au redemarrage, le Configuration Manager detecte l'incoherence
3. Il rejoue les modifications depuis les fichiers .LOG1 / .LOG2
4. La ruche est restauree dans un etat coherent

# Check the last write time of the SYSTEM hive file
Get-ItemProperty "$env:SystemRoot\System32\config\SYSTEM" | Select-Object LastWriteTime

LastWriteTime
-------------
2026-04-03 09:15:00

Les fichiers LOG1 et LOG2 en detail¶

Chaque ruche est accompagnee de deux fichiers journaux : .LOG1 et .LOG2. Comprendre leur role est essentiel pour le depannage et la forensique.

Pourquoi deux journaux ?¶

Le systeme utilise un mecanisme de double journalisation (dual logging). Si une corruption survient pendant la relecture du premier journal, le second journal contient une copie de secours. Le processus est le suivant :

1. Les modifications sont ecrites dans .LOG1
2. Si .LOG1 est plein ou lors d'un cycle de synchronisation, Windows bascule sur .LOG2
3. En cas de crash, la priorite de recuperation est : .LOG1 > .LOG2 > RegBack

Verifier la coherence d'un journal¶

Les fichiers journaux commencent par une signature identifiable :

# List all log files for the SYSTEM hive
Get-ChildItem "$env:SystemRoot\System32\config\SYSTEM.LOG*"

    Directory: C:\Windows\System32\config

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         1/15/2026   8:30 AM         262144 SYSTEM.LOG1
-a----         1/15/2026   8:30 AM         262144 SYSTEM.LOG2

Journalisation transactionnelle : zero perte de donnees¶

Chaque modification suit un processus en 4 etapes :

graph LR
    A["1. Ecriture dans<br/>le journal .LOG"] --> B["2. Sequence 1<br/>incrementee"]
    B --> C["3. Ecriture dans<br/>le fichier principal"]
    C --> D["4. Sequence 2<br/>incrementee"]
    style A fill:#4a9,stroke:#333
    style D fill:#4a9,stroke:#333

1. Les donnees modifiees sont ecrites dans le fichier journal (.LOG)
2. Le numero de sequence 1 de l'en-tete est incremente
3. Les donnees sont ecrites dans le fichier principal de la ruche
4. Le numero de sequence 2 est incremente pour confirmer la transaction

Limites connues¶

Surveiller la taille du registre¶

La taille du registre n'est pas qu'une curiosité. Des ruches trop volumineuses ralentissent plusieurs opérations critiques :

• le démarrage de Windows, car davantage de données doivent être chargées et validées
• l'ouverture de session, surtout quand NTUSER.DAT grossit fortement
• les sauvegardes, restaurations et captures forensiques, qui deviennent plus longues et plus lourdes

Dans la pratique, ce n'est pas la taille totale du registre qui pose problème, mais la croissance anormale d'une ou deux ruches. SOFTWARE et NTUSER.DAT sont souvent les premiers candidats.

# Check size of main hive files
$hives = @("SYSTEM", "SOFTWARE", "SAM", "SECURITY", "DEFAULT")
foreach ($hive in $hives) {
    $path = "$env:SystemRoot\System32\config\$hive"
    if (Test-Path $path) {
        $size = (Get-Item $path).Length / 1MB
        Write-Host ("{0,-12} : {1:N1} MB" -f $hive, $size)
    }
}

SYSTEM       : 18.2 MB
SOFTWARE     : 82.4 MB
SAM          : 0.1 MB
SECURITY     : 0.3 MB
DEFAULT      : 0.5 MB

Les causes classiques d'un gonflement du registre sont bien connues :

• logiciels désinstallés laissant des clés orphelines
• listes MRU (Most Recently Used) qui s'accumulent sans purge
• malwares qui stockent charges utiles, configuration ou données exfiltrées dans des valeurs
• applications mal conçues qui utilisent le registre comme pseudo base de données temporaire

Quand vous suspectez un abus, il peut être utile de rechercher des valeurs anormalement grosses. Le script suivant explore un sous-arbre et remonte les entrées dépassant 1 Mo :

# Find registry values larger than 1 MB (may indicate bloat or abuse)
function Find-LargeRegistryValues {
    param([string]$Path, [int]$ThresholdKB = 1024)
    try {
        $key = Get-Item -LiteralPath $Path -ErrorAction Stop
        foreach ($valueName in $key.GetValueNames()) {
            $data = $key.GetValue($valueName)
            $size = if ($data -is [byte[]]) { $data.Length } else { [System.Text.Encoding]::Unicode.GetByteCount($data.ToString()) }
            if ($size -gt ($ThresholdKB * 1024)) {
                [PSCustomObject]@{ Path = $Path; Value = $valueName; SizeKB = [math]::Round($size/1KB, 1) }
            }
        }
        foreach ($subkey in $key.GetSubKeyNames()) {
            Find-LargeRegistryValues -Path "$Path\$subkey" -ThresholdKB $ThresholdKB
        }
    } catch {}
}
Find-LargeRegistryValues -Path "HKLM:\SOFTWARE" | Sort-Object SizeKB -Descending | Select-Object -First 20

Cette approche peut compléter un reg.exe query /s ciblé sur une branche connue, notamment quand vous cherchez à confirmer qu'une valeur volumineuse explique une ruche anormalement grosse.

Flags de compatibilite¶

Le Configuration Manager expose plusieurs parametres internes via le registre lui-meme. Ces valeurs, situees sous HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager, permettent d'ajuster le comportement du gestionnaire de ruches.

# Read Configuration Manager settings
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager" -ErrorAction SilentlyContinue

RegistryLazyFlushInterval : 5
EnablePeriodicBackup      : 0