Aller au contenu
Pagefile.sys Parser
← Retour au blog

Carving de fragments de ruches de registre depuis pagefile.sys

20/05/2026 · 5 min de lecture

Les ruches de registre vivent en permanence en RAM — chaque processus ouvre des handles de ruches au démarrage, et Windows met en cache les ruches actives dans le pool non paginé. Mais les portions les plus anciennes / les plus froides des grosses ruches (pensez à SOFTWARE sur un serveur chargé, ou à un NTUSER.DAT figé d'un utilisateur inactif) sont bel et bien paginées, et c'est là que le carving de pagefile fait son office : vous pouvez reconstruire des données de registre supprimées ou modifiées qui ne sont plus visibles sur disque.

Les deux signatures qui comptent

Les ruches du registre Windows sont constituées de deux types de blocs, tous deux alignés sur 4 Ko et triviaux à carver :

SignatureHexCe que c'est
regf72 65 67 66Bloc de base d'une ruche — l'en-tête du fichier
hbin68 62 69 6EBin d'une ruche — un conteneur de cellules de 4 Ko

Une ruche complète sur disque commence par un unique bloc regf (4 Ko) suivi d'une séquence de blocs hbin. Dans un pagefile, vous récupérez quasiment jamais la séquence intacte — ce que vous récupérez en revanche, ce sont de nombreux blocs hbin isolés, représentant chacun un morceau de 4 Ko de données de registre paginé depuis la RAM.

Le parser classe chaque page de 4 Ko et marque les matchs regf / hbin dans l'onglet Page map. Cliquez sur chacun pour voir son décalage absolu dans le fichier.

Ce qui survit dans un hbin isolé

Un hbin est un conteneur de cellules. Chaque cellule est soit :

  • Un nœud de clé (nk) — comporte le nom de la clé, l'horodatage de dernière écriture, la référence parent, le nombre de sous-clés.
  • Une entrée de valeur (vk) — nom, type (REG_SZ, REG_DWORD, REG_BINARY, etc.), décalage des données.
  • Une liste de sous-clés (lf, lh, li, ri).
  • Un descripteur de sécurité (sk).
  • Du big data pour les valeurs plus grandes que la taille de la cellule (db).
  • Les octets de valeur eux-mêmes.

Un unique hbin de 4 Ko contient typiquement quelques dizaines de cellules. Même un bin isolé peut vous donner :

  • Les noms et les horodatages de dernière écriture des clés qui vivaient dans ce bin.
  • Les noms et les types des valeurs, plus leurs données si celles-ci étaient inline (la plupart des valeurs REG_SZ et REG_DWORD le sont).
  • Les cellules supprimées : quand une clé ou une valeur est retirée, la cellule est marquée libre (le bit de poids fort de la taille bascule) mais son contenu n'est pas remis à zéro. Les outils de ruche en lecture sautent les cellules supprimées ; les carvers savent les lire.

C'est le principal prix forensique — des artefacts de registre qui n'existent plus dans la ruche vivante.

Extraire des cellules d'un hbin carvé

Vous ne pouvez pas charger un unique hbin directement dans Regedit ou Registry Explorer — ils attendent un fichier complet préfixé d'un regf. Le workflow :

  1. Trouver les pages hbin dans le pagefile via la Page map de cet outil.
  2. Noter les décalages absolus, par ex. 0x12340000, 0x12341000.
  3. Extraire les octets avec dd : 
    dd if=pagefile.sys of=hbin1.bin bs=1 skip=$((0x12340000)) count=4096
  4. Soit :
    • Parser manuellement : la référence du format des fichiers de registre Windows de Microsoft (documentation libregf) est la source canonique.
    • Préfixer un en-tête regf synthétique pour qu'un visualiseur de ruche accepte le fichier — yarp (le parser de registre Python de Maxim Suhanov) propose des helpers pour cela et tolère bien mieux la corruption que hivexsh ou Registry Explorer.

Ce qu'il faut chercher dans les ruches carvées

Les clés les plus intéressantes à récupérer dans un pagefile :

  • SAM\Domains\Account\Users\… — RID, hash NT, flags de compte.
  • SECURITY\Policy\Secrets\… — secrets LSA (mot de passe du compte machine, credentials de comptes de service, clés maîtres DPAPI).
  • SOFTWARE\Microsoft\Windows\CurrentVersion\Run / RunOnce — entrées de persistance.
  • SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks — GUID de tâches planifiées.
  • SYSTEM\CurrentControlSet\Services\… — services installés, y compris les malwares qui se sont enregistrés.
  • NTUSER.DAT Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU — commandes récemment saisies dans la boîte de dialogue Exécuter.
  • NTUSER.DAT Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths — historique de la barre d'adresse de l'Explorateur.
  • UsrClass.dat ShellBags — dossiers ouverts par l'utilisateur, même ceux supprimés depuis.

Un fragment paginé carvé de l'un de ces emplacements a une valeur forensique même sans le contexte de la ruche environnante.

Comparaison avec le système actif

Si vous avez à la fois le pagefile et les ruches SOFTWARE / SYSTEM / SAM / NTUSER.DAT actives depuis C:\Windows\System32\config\ :

  • Diffez les fragments carvés contre la ruche active — tout ce qui est dans les données carvées et pas dans la ruche active est supprimé. C'est la preuve.
  • Utilisez yarp (ou regipy) pour parcourir les deux et émettre une liste unifiée de valeurs.

Limites spécifiques au carving de registre

  • Pas de rejeu de journal de transactions : le système des ruches actives utilise des fichiers *.LOG1/*.LOG2 pour rendre les écritures durables ; dans un fragment paginé, vous pouvez voir un état pré-commit que la ruche active a déjà écrasé.
  • Les décalages de cellules sont relatifs à la base de la ruche : les pointeurs d'une cellule à l'autre (pointeurs de liste de sous-clés, listes de valeurs) sont inutilisables sans le bloc de base complet de la ruche — vous lisez les cellules inline mais ne pouvez pas naviguer.
  • Pages compressées : sur Windows 10+, un hbin peut être compressé en Xpress-Huffman avant d'être paginé. Cet outil signale ces pages dans la page map ; la décompression manuelle est une fonctionnalité future.

Lectures associées