Virtualisation et conteneurs¶

Ce que vous allez apprendre¶

• Comment le registre fonctionne dans les machines virtuelles Hyper-V
• Le registre jetable de Windows Sandbox
• Le registre dans les conteneurs Docker Windows
• La virtualisation App-V et son registre virtuel
• Le registre dans les packages MSIX
• La virtualisation UAC (VirtualStore) en profondeur
• Le registre en environnement Remote Desktop / Terminal Services
• La configuration WSL stockee dans le registre
• Les restrictions du mode S de Windows
• Comment diagnostiquer les problemes lies a la virtualisation du registre

Hyper-V : le registre dans les machines virtuelles¶

Chaque VM a son propre registre¶

Une machine virtuelle Hyper-V est un ordinateur complet simule. Son registre est stocke dans les fichiers de ruches situes sur le disque virtuel (VHDX).

Machine virtuelle (VHDX)
└── Windows
    └── System32
        └── config
            ├── SYSTEM
            ├── SOFTWARE
            ├── SAM
            ├── SECURITY
            └── DEFAULT

Acceder au registre d'une VM hors ligne¶

Vous pouvez monter le disque virtuel d'une VM eteinte et acceder a son registre :

# Mount the VHDX file
Mount-VHD -Path "C:\VMs\Server01\Virtual Hard Disks\Server01.vhdx" -ReadOnly

# The disk appears as a new drive letter (e.g., E:)
# Load the hive into the local registry
reg load HKLM\VM_SOFTWARE "E:\Windows\System32\config\SOFTWARE"

The operation completed successfully.

# Query a value from the mounted hive
Get-ItemProperty "HKLM:\VM_SOFTWARE\Microsoft\Windows NT\CurrentVersion" |
    Select-Object ProductName, CurrentBuild

ProductName      CurrentBuild
-----------      ------------
Windows Server 2022 20348

# Unload the hive when done
reg unload HKLM\VM_SOFTWARE

# Dismount the VHDX
Dismount-VHD -Path "C:\VMs\Server01\Virtual Hard Disks\Server01.vhdx"

The operation completed successfully.
Aucune sortie supplementaire si le demontage reussit.

Cles specifiques a Hyper-V sur l'hote¶

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization
HKLM\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters

Sur l'invite (la VM elle-meme), les services d'integration ecrivent dans :

HKLM\SOFTWARE\Microsoft\Virtual Machine\Auto
    HostName = "HYPERV-HOST01"
    VirtualMachineName = "Server01"

Windows Sandbox : le registre jetable¶

Principe de fonctionnement¶

Windows Sandbox cree un environnement ephemere : tout est detruit a la fermeture. Le registre de la Sandbox fonctionne par couches differentielles :

graph TD
    A["Image de base Windows<br/>(lecture seule)"] --> B["Couche differentielle<br/>(modifications en memoire)"]
    B --> C["Registre visible par la Sandbox<br/>(fusion des deux couches)"]
    style A fill:#e8f5e9
    style B fill:#fff3e0
    style C fill:#e3f2fd

Ce qui persiste et ce qui ne persiste pas¶

Configuration de la Sandbox via le registre hote¶

La Sandbox elle-meme est configuree sur l'hote :

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce  ← Commandes au demarrage de la Sandbox

Le fichier de configuration .wsb (XML) permet de preconfigurer la Sandbox :

<Configuration>
    <MappedFolders>
        <MappedFolder>
            <HostFolder>C:\Tools</HostFolder>
            <SandboxFolder>C:\Users\WDAGUtilityAccount\Desktop\Tools</SandboxFolder>
            <ReadOnly>true</ReadOnly>
        </MappedFolder>
    </MappedFolders>
    <LogonCommand>
        <Command>C:\Users\WDAGUtilityAccount\Desktop\Tools\setup.bat</Command>
    </LogonCommand>
</Configuration>

Le script setup.bat peut contenir des commandes reg add pour configurer le registre de la Sandbox au demarrage.

Docker Windows Containers : le registre en couches¶

Architecture du registre dans un conteneur¶

Les conteneurs Windows utilisent un systeme de couches (layers) pour le systeme de fichiers et le registre :

graph TD
    A["Image de base<br/>mcr.microsoft.com/windows/servercore<br/>(lecture seule)"] --> B["Couche applicative<br/>Votre Dockerfile<br/>(lecture seule)"]
    B --> C["Couche d'ecriture<br/>Conteneur en cours d'execution<br/>(lecture-ecriture)"]
    C --> D["Registre visible<br/>par le conteneur"]
    style A fill:#e8f5e9
    style B fill:#fff3e0
    style C fill:#ffebee

Le registre a l'interieur du conteneur¶

Un conteneur Windows a son propre registre complet, isole de l'hote :

:: Inside a Windows container
docker run -it mcr.microsoft.com/windows/servercore:ltsc2022 cmd

L'image est telechargee si necessaire, puis une invite de commandes s'ouvre dans le conteneur.
Microsoft Windows [Version 10.0.20348.XXX]
C:\>

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v ProductName

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
    ProductName    REG_SZ    Windows Server 2022

Modifier le registre via Dockerfile¶

Les instructions RUN dans un Dockerfile peuvent modifier le registre du conteneur :

FROM mcr.microsoft.com/windows/servercore:ltsc2022

# Disable Server Manager at logon
RUN reg add "HKLM\SOFTWARE\Microsoft\ServerManager" /v DoNotOpenServerManagerAtLogon /t REG_DWORD /d 1 /f

# Configure application settings
RUN reg add "HKLM\SOFTWARE\MyApp" /v DataPath /t REG_SZ /d "C:\AppData" /f
RUN reg add "HKLM\SOFTWARE\MyApp" /v MaxConnections /t REG_DWORD /d 100 /f

# Import a complete .reg file
COPY config.reg C:/temp/config.reg
RUN reg import C:\temp\config.reg

Chaque instruction RUN cree une nouvelle couche. Les modifications de registre sont capturees dans cette couche, exactement comme les modifications de fichiers.

Inspecter le registre d'un conteneur¶

# Execute a command inside a running container
docker exec my_container reg query "HKLM\SOFTWARE\MyApp"

HKEY_LOCAL_MACHINE\SOFTWARE\MyApp
    DataPath    REG_SZ    C:\AppData
    MaxConnections    REG_DWORD    0x64

Process isolation vs Hyper-V isolation¶

# Run a container with Hyper-V isolation
docker run --isolation=hyperv mcr.microsoft.com/windows/servercore:ltsc2022 cmd

Le conteneur demarre dans une micro-VM Hyper-V avec isolation complete.
Une invite de commandes s'ouvre dans le conteneur.

App-V : registre virtuel applicatif¶

Concept de registre virtuel¶

Microsoft Application Virtualization (App-V) permet de virtualiser des applications sans les installer au sens classique. Chaque application App-V possede son propre registre virtuel.

graph LR
    A["Application App-V"] -->|Lit/ecrit| B["Registre virtuel<br/>(dans le package .appv)"]
    B -->|Fusion a l'execution| C["Registre reel<br/>(HKLM/HKCU)"]
    A -.->|"L'app croit ecrire<br/>dans le registre reel"| C

Le registre dans le package .appv¶

Un fichier .appv est un ZIP qui contient :

MonApp.appv
├── Registry.dat           ← Ruche du registre virtuel (format regf standard)
├── FilesystemMetadata.xml
├── PackageHistory.xml
├── AppxManifest.xml
└── Root/
    └── VFS/               ← Systeme de fichiers virtuel

Le fichier Registry.dat contient les cles que l'application pense ecrire dans le registre reel.

Interception des appels registre¶

Quand une application App-V appelle RegOpenKeyEx, le filtre App-V intercepte l'appel :

Groupes de connexion¶

Quand plusieurs applications App-V doivent partager des cles de registre, on cree un groupe de connexion (Connection Group) :

# List App-V connection groups
Get-AppvClientConnectionGroup

La liste des groupes de connexion App-V s'affiche avec leur nom, GUID et etat.
Si aucun groupe n'est configure, la sortie est vide.

Les registres virtuels des applications du groupe sont fusionnes dans un namespace commun.

MSIX : registre dans les packages modernes¶

Le registre virtualise MSIX¶

Les applications MSIX ont un registre virtualise stocke dans le package. C'est une evolution directe du concept App-V.

MonApp.msix (ZIP)
├── registry.dat       ← Ruche du registre virtuel
├── AppxManifest.xml
├── Assets/
└── VFS/

Comment Windows fusionne le registre¶

graph TD
    A["Application MSIX<br/>lit HKLM\SOFTWARE\MonApp"] --> B{"Cle dans<br/>registry.dat ?"}
    B -->|Oui| C["Retourne la valeur<br/>du package"]
    B -->|Non| D["Retourne la valeur<br/>du registre reel"]

    A2["Application MSIX<br/>ecrit HKLM\SOFTWARE\MonApp"] --> E["Ecriture redirigee vers<br/>le registre virtuel prive"]

Verifier le registre d'un package MSIX¶

# List installed MSIX packages
Get-AppxPackage | Select-Object Name, InstallLocation | Format-Table

# The registry.dat is inside the package folder
$package = Get-AppxPackage -Name "Microsoft.WindowsTerminal"
$registryDat = Join-Path $package.InstallLocation "registry.dat"
Test-Path $registryDat

True

Vous pouvez charger cette ruche pour l'examiner :

# Load the MSIX registry hive
reg load HKLM\MSIX_TEMP $registryDat
reg query HKLM\MSIX_TEMP
reg unload HKLM\MSIX_TEMP

The operation completed successfully.
HKEY_LOCAL_MACHINE\MSIX_TEMP
HKEY_LOCAL_MACHINE\MSIX_TEMP\Registry
HKEY_LOCAL_MACHINE\MSIX_TEMP\Registry\Machine
HKEY_LOCAL_MACHINE\MSIX_TEMP\Registry\User
The operation completed successfully.

%ProgramData%\Packages\<package_family_name>\SystemAppData\Helium\

Virtualisation UAC (VirtualStore) en profondeur¶

Le probleme : applications legacy et UAC¶

Avant Vista, de nombreuses applications ecrivaient librement dans HKLM\SOFTWARE. Avec l'UAC de Vista, les processus non eleves n'ont plus le droit d'ecrire dans HKLM.

La virtualisation UAC resout ce probleme en redirigeant silencieusement les ecritures vers un espace prive.

Mecanisme detaille¶

sequenceDiagram
    participant App as Application legacy<br/>(32 bits, pas de manifest)
    participant UAC as Filtre UAC<br/>(noyau)
    participant VS as VirtualStore<br/>(HKCU)
    participant Real as Registre reel<br/>(HKLM)

    App->>UAC: RegSetValueEx(HKLM\SOFTWARE\MonApp\Setting, ...)
    UAC->>UAC: Verifier les permissions
    Note over UAC: Acces refuse (pas admin)
    UAC->>UAC: Verifier si la virtualisation est active
    Note over UAC: Oui : application legacy sans manifest
    UAC->>VS: Rediriger vers HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE\MonApp\Setting
    VS-->>App: Succes (l'app croit avoir ecrit dans HKLM)

    App->>UAC: RegQueryValueEx(HKLM\SOFTWARE\MonApp\Setting)
    UAC->>VS: Chercher d'abord dans VirtualStore
    VS-->>UAC: Valeur trouvee
    UAC-->>App: Retourne la valeur du VirtualStore

Emplacement du VirtualStore¶

HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE\

C'est le miroir de HKLM\SOFTWARE, mais par utilisateur.

# Check if any keys exist in the VirtualStore
Get-ChildItem "HKCU:\Software\Classes\VirtualStore\MACHINE\SOFTWARE" -ErrorAction SilentlyContinue

    Hive: HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE

Name
----
OldApp1
LegacyGame
AncientUtility

Quels processus sont virtualises ?¶

La virtualisation ne s'applique pas a tous les processus. Voici les regles :

Detecter la virtualisation¶

# Check if a specific application is being virtualized
# Look for the compatibility flag in the PEB (Process Environment Block)
$process = Get-Process -Name "oldapp" -ErrorAction SilentlyContinue
if ($process) {
    # Check the executable for an application manifest
    $manifest = [System.Reflection.Assembly]::LoadFile($process.Path).GetManifestResourceInfo("RT_MANIFEST")
    Write-Output "Has manifest: $($null -ne $manifest)"
}

# Simpler check: look for VirtualStore entries
$virtualStoreEntries = Get-ChildItem "HKCU:\Software\Classes\VirtualStore\MACHINE\SOFTWARE" -ErrorAction SilentlyContinue
if ($virtualStoreEntries) {
    Write-Output "Virtualized keys found:"
    $virtualStoreEntries | ForEach-Object { Write-Output "  $($_.Name)" }
}

Virtualized keys found:
  HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\OldApp1
  HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\LegacyGame

Drapeaux de compatibilite¶

Vous pouvez desactiver la virtualisation pour une application specifique via les drapeaux de compatibilite :

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
    "C:\Path\to\app.exe" = "RUNASINVOKER"

Remote Desktop / Terminal Services¶

Cles par session vs par machine¶

En environnement Remote Desktop, plusieurs utilisateurs partagent le meme systeme. Le registre gere cette cohabitation :

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server
    fDenyTSConnections = 0    ; 0 = RDP active, 1 = RDP desactive
    fSingleSessionPerUser = 1 ; Une session par utilisateur

Profils utilisateurs et registre¶

Chaque session RDP charge le NTUSER.DAT de l'utilisateur :

graph TD
    A["Utilisateur A<br/>se connecte en RDP"] --> B["NTUSER.DAT de A<br/>charge dans HKU\S-1-5-21-...-1001"]
    C["Utilisateur B<br/>se connecte en RDP"] --> D["NTUSER.DAT de B<br/>charge dans HKU\S-1-5-21-...-1002"]
    B --> E["HKCU pour la session A"]
    D --> F["HKCU pour la session B"]

HKCU est une vue par session : chaque utilisateur connecte voit son propre HKCU.

Configuration du serveur RDS¶

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
    PortNumber = 3389         ; Port d'ecoute RDP
    SecurityLayer = 2         ; 0=RDP, 1=Negotiate, 2=TLS
    UserAuthentication = 1    ; NLA (Network Level Authentication)
    MinEncryptionLevel = 3    ; Niveau de chiffrement minimum

# Check RDP configuration
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" |
    Select-Object PortNumber, SecurityLayer, UserAuthentication, MinEncryptionLevel

PortNumber      : 3389
SecurityLayer   : 2
UserAuthentication : 1
MinEncryptionLevel : 3

Cles specifiques par session¶

Certaines cles sont instanciees par session sur les serveurs RDS :

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\SessionInfo\<session_id>

Cela permet a chaque session d'avoir ses propres parametres d'Explorateur Windows.

Profils itinerants et registre¶

Avec les profils itinerants (roaming profiles), le NTUSER.DAT est synchronise avec un partage reseau :

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID>
    ProfileImagePath = \\server\profiles$\%username%
    CentralProfile   = \\server\profiles$\%username%

WSL (Windows Subsystem for Linux)¶

Configuration WSL dans le registre¶

L'installation et la configuration de WSL sont tracees dans le registre Windows :

HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss

# List all WSL distributions registered for the current user
Get-ChildItem "HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss" |
    ForEach-Object {
        $props = Get-ItemProperty $_.PSPath
        [PSCustomObject]@{
            Name    = $props.DistributionName
            Version = $props.Version
            State   = $props.State
            Path    = $props.BasePath
            Default = $props.DefaultUid
        }
    }

Name             Version State Path                                            Default
----             ------- ----- ----                                            -------
Ubuntu-22.04           2     1 C:\Users\User\AppData\Local\Packages\...          1000
Debian                 2     1 C:\Users\User\AppData\Local\Packages\...          1000
kali-linux             2     1 C:\Users\User\AppData\Local\Packages\...          1000

Structure des cles WSL¶

Chaque distribution est une sous-cle identifiee par un GUID :

HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss\{guid}
    DistributionName = "Ubuntu-22.04"
    Version = 2                          ; 1 = WSL 1, 2 = WSL 2
    BasePath = "C:\Users\...\ext4.vhdx"  ; Chemin du disque virtuel
    State = 1                            ; 1 = installe, 3 = en cours d'installation
    DefaultUid = 1000                    ; UID par defaut (generalement 1000)
    Flags = 15                           ; Drapeaux de configuration
    PackageFamilyName = "Canonical..."    ; Store package

La distribution par defaut¶

HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss
    DefaultDistribution = {guid}    ; GUID de la distribution lancee par "wsl" sans argument

# Get the default WSL distribution GUID
$defaultGuid = (Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss").DefaultDistribution
Write-Output "Default distribution GUID: $defaultGuid"

Default distribution GUID: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}

Configuration globale WSL 2¶

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss
    NatNetwork = 172.28.0.0/16    ; Reseau NAT pour WSL 2
    DhcpRange = 172.28.0.1        ; Plage DHCP

Windows en mode S : restrictions du registre¶

Qu'est-ce que le mode S ?¶

Windows en mode S est une configuration verrouillee qui n'autorise que les applications du Microsoft Store et le navigateur Edge.

Restrictions au niveau du registre¶

HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy
    VerifiedAndReputablePolicyState = 1    ; Mode S actif

Quitter le mode S¶

# Verify S Mode status
$ciPolicy = Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Policy" -ErrorAction SilentlyContinue
if ($ciPolicy.VerifiedAndReputablePolicyState -eq 1) {
    Write-Output "Windows S Mode is ACTIVE"
} else {
    Write-Output "Windows S Mode is NOT active"
}

Windows S Mode is NOT active

Diagnostiquer les problemes de virtualisation¶

Scenario 1 : une application ne retrouve pas ses parametres¶

Symptome : une application legacy ecrit des parametres qui semblent disparaitre.

Diagnostic :

# Step 1: Check if the app is writing to VirtualStore
$appName = "OldApp"
$virtualStorePath = "HKCU:\Software\Classes\VirtualStore\MACHINE\SOFTWARE\$appName"
$realPath = "HKLM:\SOFTWARE\$appName"

$virtualExists = Test-Path $virtualStorePath
$realExists = Test-Path $realPath

Write-Output "Real key exists: $realExists"
Write-Output "VirtualStore key exists: $virtualExists"

if ($virtualExists) {
    Write-Output "--- VirtualStore values ---"
    Get-ItemProperty $virtualStorePath
    Write-Output "--- Real registry values ---"
    Get-ItemProperty $realPath -ErrorAction SilentlyContinue
}

Real key exists: True
VirtualStore key exists: True
--- VirtualStore values ---
Setting1 : UserValue
Setting2 : CustomConfig
--- Real registry values ---
Setting1 : DefaultValue
Setting2 : OriginalConfig

Solution : l'application utilise la virtualisation UAC. Ajoutez un manifest avec requestedExecutionLevel ou executez en tant qu'administrateur.

Scenario 2 : les parametres d'un conteneur Docker ne persistent pas¶

Symptome : des modifications reg add dans un conteneur en cours d'execution sont perdues au redemarrage.

Diagnostic : les modifications faites dans un conteneur en cours d'execution sont dans la couche d'ecriture. Si le conteneur est supprime (docker rm), elles sont perdues.

Solutions :

# Solution 1: Put reg changes in the Dockerfile (build time)
RUN reg add "HKLM\SOFTWARE\MyApp" /v Setting /t REG_SZ /d "value" /f

# Solution 2: Use a startup script (run time)
COPY startup.bat C:/startup.bat
CMD ["C:\\startup.bat"]

Scenario 3 : une application MSIX ne lit pas le registre systeme¶

Symptome : une application MSIX ne voit pas les cles que vous avez ajoutees dans HKLM\SOFTWARE.

Diagnostic : l'application MSIX est isolee et son registre virtuel prend le dessus.

# Check the MSIX package's virtual registry
$package = Get-AppxPackage -Name "MyApp"
$registryPath = Join-Path $package.InstallLocation "registry.dat"
if (Test-Path $registryPath) {
    reg load HKLM\MSIX_CHECK $registryPath
    reg query HKLM\MSIX_CHECK
    reg unload HKLM\MSIX_CHECK
}

The operation completed successfully.
HKEY_LOCAL_MACHINE\MSIX_CHECK
HKEY_LOCAL_MACHINE\MSIX_CHECK\Registry
The operation completed successfully.

Solution : utilisez les mecanismes de configuration prevus par l'application (fichier de config, variables d'environnement) plutot que le registre systeme.

Scenario 4 : WSL ne demarre pas¶

Symptome : wsl retourne une erreur de lancement.

# Verify WSL registration in the registry
$lxssPath = "HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss"
if (Test-Path $lxssPath) {
    $distros = Get-ChildItem $lxssPath
    Write-Output "Registered distributions: $($distros.Count)"
    $distros | ForEach-Object {
        $props = Get-ItemProperty $_.PSPath
        $basePath = $props.BasePath
        $exists = Test-Path $basePath
        Write-Output "  $($props.DistributionName): BasePath exists = $exists"
    }
} else {
    Write-Output "No WSL configuration found in registry"
}

Registered distributions: 1
  Ubuntu-22.04: BasePath exists = False

Solution : le disque virtuel de la distribution a ete deplace ou supprime. Reinstallez la distribution ou restaurez le fichier VHDX a l'emplacement attendu.