Fichiers d’hibernation, de pagination et de vidage sur incident

Les leçons 5.1 à 5.3 supposaient une capture de la mémoire vive sur un système en cours d’exécution. Souvent, aucune capture n’est disponible : l’ordinateur était éteint, ou vous ne disposez que d’une image disque ou d’une collecte de triage. La mémoire se retrouve néanmoins sur le disque par le biais de l’hibernation, des fichiers de pagination, des vidages sur incident et de leurs équivalents Linux. Cette leçon explique quand chaque fichier est écrit, quelle part de sa structure est conservée et comment dater ce que vous trouvez. Les collectes de triage excluent souvent pagefile.sys et hiberfil.sys en raison de leur taille, tandis que les petits rapports d’incident sont généralement collectés.

Pourquoi la mémoire se retrouve sur le disque

Les systèmes écrivent la RAM sur le disque pour libérer de la RAM (pagination), pour s’éteindre sans perdre leur état (hibernation) et pour consigner une défaillance (vidages sur incident). Plus la structure est préservée, plus la méthode de travail avec Volatility présentée dans les leçons 5.2 et 5.3 est applicable.

Le fichier d’hibernation

C:\hiberfil.sys est un fichier système caché situé à la racine du volume système. Lorsque l’utilisateur choisit Mettre en veille prolongée, Windows y écrit le contenu de la RAM sous forme compressée, puis s’éteint ; au démarrage suivant, le chargeur de démarrage restaure la mémoire à partir de ce fichier. La valeur de registre HibernateEnabled, sous SYSTEM\<ControlSet>\Control\Power, indique si l’hibernation est activée. Dans une ruche hors ligne, lisez Select\Current pour trouver le bon ControlSet00x (leçon 2.1).

Démarrage rapide

Le démarrage rapide (également appelé arrêt hybride) utilise le même fichier. Lorsque l’utilisateur clique sur Arrêter, Windows ferme toutes les sessions utilisateur, puis met en hibernation uniquement la session noyau : le noyau, les pilotes ainsi que les processus système et services de la session 0. Le démarrage à froid suivant reprend cette image au lieu d’effectuer un démarrage complet. Le démarrage rapide est activé par défaut sur de nombreuses installations clientes de Windows 10 et 11 prenant en charge l’hibernation, mais vous devez le vérifier plutôt que le supposer : la valeur HiberbootEnabled, sous SYSTEM\<ControlSet>\Control\Session Manager\Power, vaut 1 lorsqu’il est activé. Un Redémarrage n’utilise pas le démarrage rapide ; il effectue un arrêt complet. Au démarrage suivant, l’événement 27 de Kernel-Boot dans le journal Système consigne le type de démarrage : 0x0 pour un démarrage complet, 0x1 pour un démarrage rapide (hybride) et 0x2 pour une reprise après hibernation.

Un ordinateur saisi alors qu’il est éteint conserve donc souvent un instantané de sa session noyau au dernier arrêt : processus système, services, pilotes et structures réseau du noyau, mais pas les applications utilisateur telles que explorer.exe, car les sessions utilisateur ont d’abord été fermées. Une véritable mise en veille prolongée conserve également les sessions utilisateur.

Conversion et datation

Le fichier n’est pas une image mémoire brute. Il comporte un en-tête et des ensembles de pages compressés (compression Microsoft Xpress ; la variante dépend de la version de Windows) ; il doit donc être décompressé avant que la plupart des outils puissent l’utiliser. Les versions officielles de Volatility 3 ne lisent pas directement les fichiers d’hibernation : convertissez donc d’abord le fichier avec un outil tel que Hibr2Bin, qui produit une image brute. Après conversion, les plugins des leçons 5.2 et 5.3 fonctionnent comme d’habitude.

L’en-tête commence par une signature telle que HIBR (hibr en minuscules sur les anciennes versions) lorsque l’image est valide. La signature de l’en-tête change après une reprise : Windows écrase ou efface l’en-tête, de sorte que l’on observe des valeurs telles que WAKE, RSTR ou des zéros, et un fichier obsolète peut ne pas se convertir correctement. Des pages compressées de cette ancienne image peuvent néanmoins subsister et méritent une recherche de chaînes de caractères ou une recherche YARA.

Avant tout, datez l’instantané : il décrit le moment où le fichier a été écrit, potentiellement plusieurs jours avant la saisie. Utilisez l’heure système stockée dans l’en-tête d’hibernation si votre outil l’analyse, ainsi que l’horodatage de modification $STANDARD_INFORMATION du fichier dans la $MFT, puis corroborez ces deux éléments avec les événements d’arrêt et de démarrage du journal Système (leçon 2.7).

Fichiers pagefile et swapfile

C:\pagefile.sys contient des pages que le gestionnaire de mémoire a déplacées hors de la RAM. Son emplacement et sa taille sont définis dans la valeur PagingFiles, sous SYSTEM\<ControlSet>\Control\Session Manager\Memory Management ; recherchez donc aussi des fichiers de pagination sur d’autres volumes. C:\swapfile.sys (Windows 8 et versions ultérieures) est un fichier complémentaire plus petit, utilisé pour déplacer intégralement hors de la mémoire les applications modernes (Store).

Un fichier de pagination est un ensemble de pages de 4 KiB écrites au fil du temps, sans table de correspondance : les tables de pages qui indiquent à quel processus et à quelle adresse virtuelle une page appartenait se trouvent dans la RAM, pas dans le fichier. Vous ne pouvez pas reconstituer des processus à partir du seul fichier de pagination. Certains environnements d’analyse mémoire peuvent combiner un fichier de pagination avec une capture de RAM réalisée au même moment pour résoudre les adresses des pages transférées sur disque, mais dans un dossier où seul le disque est disponible, le fichier de pagination est une source de chaînes de caractères : URL, fragments de courriels et de conversations, commandes saisies, chemins de fichiers et parfois identifiants d’authentification. Windows réutilise le fichier d’un démarrage à l’autre sans l’effacer par défaut ; une page peut donc provenir d’une session antérieure.

Deux éléments réduisent ce que vous pouvez trouver :

• Compression de la mémoire (Windows 10 et versions ultérieures) : les pages peuvent être compressées dans le magasin de compression mémoire en RAM avant d’être transférées dans le fichier de pagination ; le contenu de ce fichier peut donc être compressé et invisible lors d’une simple recherche de chaînes de caractères. Des outils de recherche existent pour décompresser ce magasin, mais les outils standard ne détectent pas ce contenu.
• ClearPageFileAtShutdown : lorsque cette valeur DWORD sous Memory Management vaut 1, Windows remplace le contenu du fichier de pagination par des zéros à l’arrêt. Un fichier de pagination entièrement rempli de zéros, lorsque cette valeur est définie, est normal et ne constitue pas un signe d’effacement par l’utilisateur.

Analysez le fichier avec strings en ASCII et en UTF-16LE (strings -el), bulk_extractor (ses fichiers de résultats indiquent chaque occurrence avec son offset en octets et le contexte environnant) et des règles YARA. Consignez l’offset de chaque occurrence ; c’est votre seul repère de localisation.

Vidages sur incident et rapports d’erreurs

Lorsque Windows s’arrête sur un bugcheck (un « écran bleu »), il écrit la mémoire dans le fichier de pagination puis, au démarrage suivant, l’enregistre dans un fichier de vidage et consigne l’événement Système 1001 de la source BugCheck. Le type est défini par CrashDumpEnabled, sous SYSTEM\<ControlSet>\Control\CrashControl :

Les vidages complets et du noyau sont enregistrés dans C:\Windows\MEMORY.DMP (valeur DumpFile ; par défaut, chaque incident écrase le précédent), et les images mémoire partielles dans C:\Windows\Minidump\*.dmp. Volatility 3 ne lit que les vidages mémoire complets (formats full et bitmap, DumpType 1 et 5), pas les vidages du noyau ni les images mémoire partielles ; un vidage complet se comporte donc comme une capture de RAM. Analysez les vidages du noyau avec WinDbg. Un vidage du noyau répertorie les processus et les pilotes, mais tout ce qui se trouve dans la mémoire utilisateur, comme les lignes de commande stockées dans l’environnement du processus, est absent. Dans WinDbg, !analyze -v explique l’incident, lm répertorie les modules et !process 0 0 répertorie les processus.

Les incidents d’application sont pris en charge par le Rapport d’erreurs Windows (WER). Les rapports sont stockés dans C:\ProgramData\Microsoft\Windows\WER\ReportArchive (envoyés ou traités) et ReportQueue (en attente), avec des copies propres à chaque utilisateur sous %LOCALAPPDATA%\Microsoft\Windows\WER. Les noms de dossiers commencent par le type de rapport et le nom de l’exécutable, par exemple AppCrash_xfer.exe_…. Chacun contient un fichier texte UTF-16 Report.wer composé de lignes clé=valeur, par exemple EventType=APPCRASH, un EventTime écrit sous forme de FILETIME décimal, ainsi que le nom de l’application et, sur les versions plus récentes, son chemin complet. Un rapport d’incident prouve que le programme s’est exécuté ; c’est donc un artefact d’exécution qui subsiste après la suppression du programme (la leçon 2.3 traite des autres). Les événements 1000 (Application Error) et 1001 (Windows Error Reporting) du journal Application le corroborent.

Les vidages complets en mode utilisateur d’un processus ayant subi un incident ne sont écrits que si LocalDumps est configuré sous SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps : DumpFolder (par défaut %LOCALAPPDATA%\CrashDumps), DumpType (1 minividage, 2 complet) et DumpCount (10 par défaut). Un vidage complet d’un navigateur peut contenir du contenu déchiffré.

Linux : espace d’échange et vidages mémoire de processus

Linux transfère les pages mémoire vers une partition d’échange ou un fichier d’échange tel que /swapfile ; /etc/fstab les répertorie. Une zone d’échange porte la signature SWAPSPACE2 dans les 10 derniers octets de sa première page (offset 4 086 avec des pages de 4 KiB). Comme un fichier de pagination, l’espace d’échange est une source de chaînes de caractères. L’hibernation (suspension sur disque) sous Linux écrit l’image mémoire dans l’espace d’échange, et l’implémentation propre au noyau remplace la signature par S1SUSPEND jusqu’à la reprise. L’espace d’échange est souvent chiffré avec le disque, et zram conserve l’espace d’échange compressé uniquement en RAM.

Les incidents de processus sur les distributions utilisant systemd sont capturés par systemd-coredump : des fichiers de vidage mémoire de processus compressés dans /var/lib/systemd/coredump/, dont les noms comprennent le nom du programme, l’identifiant utilisateur, l’identifiant de démarrage, l’identifiant du processus et l’heure de l’incident, ainsi qu’une entrée de journal que coredumpctl list affiche même après le nettoyage du fichier de vidage.

Tableau récapitulatif

Exemple détaillé

Fichier d’hibernation. Un ordinateur de bureau a été trouvé éteint et saisi le 2026-03-16T09:30:00Z. L’image contient hiberfil.sys avec un horodatage de modification dans la $MFT de 2026-03-13T22:47:10Z. Dans ControlSet001\Control\Session Manager\Power, HiberbootEnabled = 1. L’image convertie montre lsass.exe, services.exe, de nombreuses instances de svchost.exe et un service inhabituel, mais aucun explorer.exe ni navigateur.

Interprétation : il s’agit d’une image de démarrage rapide datant du dernier arrêt, et non de la saisie. L’intervalle va de 2026-03-13T22:47:10Z à 2026-03-16T09:30:00Z : 2 jours (jusqu’au 2026-03-15T22:47:10Z) plus 10 h 42 min 50 s, soit 2 d 10 h 42 min 50 s. Indiquez dans le rapport que le service inhabituel était « en cours d’exécution à 2026-03-13T22:47:10Z, heure du dernier arrêt avec démarrage rapide », et corroborez cette heure avec les événements d’arrêt du journal Système. L’absence de processus utilisateur ne signifie pas que personne n’était connecté.

Fichier de pagination. bulk_extractor signale la chaîne UTF-16LE transfer.example.com/upload à l’offset en octets 1 234 567 890 de pagefile.sys, et à proximité un fragment de courriel rcos.vidal@exampl. 1 234 567 890 = 0x499602D2. Avec des pages de 4 KiB : 1 234 567 890 ÷ 4 096 = 301 408, reste 722, soit la page 301 408 (0x49960), à l’octet 722 (0x2D2) dans cette page. Consignez dans le rapport :

• la chaîne exacte, l’encodage, l’offset en décimal et en hexadécimal, ainsi que l’empreinte du fichier pagefile.sys exporté ;
• le fragment exactement tel qu’il a été trouvé, sans compléter l’adresse ;
• le fait que le fichier de pagination ne fournit ni heure ni processus propriétaire, et que la page peut être antérieure au dernier démarrage ;
• les éléments de corroboration provenant de sources horodatées : historique de navigation et téléchargements (module 4), utilisation du réseau dans SRUM (leçon 2.8) ou journaux de proxy et de pare-feu.

Traitement des contenus sensibles

Ces fichiers contiennent tout ce qui se trouvait en mémoire : mots de passe, messages de tiers, données de santé ou financières et communications protégées par le secret professionnel. Limitez vos recherches au cadre de votre autorisation, ne rapportez que les résultats pertinents et protégez les chaînes de caractères et les vidages exportés comme les éléments de preuve eux-mêmes.

Points clés pour l'examen : Attendez-vous à des questions sur le contenu de chaque fichier et sur le moment de son écriture, en particulier sur le fait qu’un hiberfil.sys de démarrage rapide ne contient que la session noyau du dernier arrêt et doit être daté. Connaissez les valeurs de CrashDumpEnabled, les chemins de vidage par défaut, les dossiers WER comme preuves d’exécution, ainsi que les valeurs de registre HiberbootEnabled et ClearPageFileAtShutdown. Les occurrences trouvées dans le fichier de pagination sont rapportées par offset, sans heure.

Points essentiels

• hiberfil.sys est un instantané compressé de la RAM datant de la dernière mise en veille prolongée ou du dernier arrêt avec démarrage rapide ; convertissez-le et datez-le avant de l’interpréter.
• Le démarrage rapide n’enregistre que la session noyau ; les applications utilisateur sont donc absentes par conception.
• pagefile.sys, swapfile.sys et l’espace d’échange Linux sont des pages non structurées : recherchez des chaînes de caractères, consignez les offsets et n’en déduisez jamais une heure.
• CrashDumpEnabled définit le type de vidage (1 complet, 2 noyau, 3 partiel, 7 automatique) ; un vidage du noyau ne contient pas la mémoire en mode utilisateur.
• Les fichiers WER Report.wer et les entrées systemd-coredump prouvent qu’un programme s’est exécuté, même après sa suppression.
• Ces fichiers contiennent des données de tiers et des données sensibles ; restez dans le périmètre autorisé.