Cache, navigation privée et traces persistantes

Les leçons 4.1 et 4.2 portaient sur la lecture des bases de données d’historique. Cette leçon traite du cache du navigateur, qui conserve des copies de ce qui a réellement été transmis, et de la navigation privée, qui supprime l’historique et le cache, mais pas les traces conservées par le reste de Windows. Le rôle de l’examinateur est de savoir quelles traces subsistent, où les trouver et jusqu’où elles permettent d’étayer une constatation.

Ce que contient le cache et pourquoi c’est important

Un navigateur conserve des copies de pages, d’images, de scripts, de feuilles de style et d’autres contenus téléchargés afin de pouvoir les afficher à nouveau sans les récupérer. Chaque entrée du cache conserve la clé (essentiellement l’URL), le contenu lui-même et les en-têtes de réponse du serveur, tels que Date (moment où le serveur a envoyé la réponse), Last-Modified, Content-Type, Content-Length et ETag, ainsi que des horodatages inscrits par le navigateur à partir de l’horloge locale. Cela fournit à l’examinateur trois éléments que la base de données d’historique ne fournit pas : le contenu que l’utilisateur a vu, la preuve que ce contenu est parvenu à ce profil de navigateur et un horodatage provenant de l’horloge du serveur.

L’en-tête Date est écrit par le serveur web, dont l’horloge est normalement synchronisée : il constitue donc une horloge externe utile ; une réponse servie depuis le cache d’un CDN ou d’un proxy conserve sa valeur Date d’origine, et un en-tête Age indique alors son ancienneté. Comparez-la aux horodatages locaux de la même entrée pour mesurer le décalage de l’horloge de l’appareil (leçon 3.5). Last-Modified fournit une borne inférieure : le contenu ne peut pas avoir été transmis avant sa dernière modification sur le serveur.

Cache de Chromium

Chrome conserve son cache HTTP dans %LOCALAPPDATA%\Google\Chrome\User Data\Default\Cache\Cache_Data ; Edge utilise la même organisation sous %LOCALAPPDATA%\Microsoft\Edge\User Data\<profile>. Le format sur disque varie selon la plateforme et la version. Les versions récentes de Chrome sous Windows utilisent le format blockfile dans Cache_Data :

Chaque entrée comporte un flux 0 (les informations analysées de la réponse HTTP, y compris les en-têtes) et un flux 1 (le corps, souvent encore compressé avec gzip ou Brotli tel qu’il a été envoyé). Chromium stocke les horodatages en microsecondes depuis le 1601-01-01 UTC. Sous Android, Linux, ChromeOS et macOS, Chromium utilise par défaut le format simple cache : un fichier par entrée nommé <16 hex digits>_0, avec éventuellement des fichiers _1 et _s et un dossier index-dir.

Depuis Chrome 86, le cache HTTP est partitionné par site ; les clés peuvent donc commencer par un préfixe tel que 1/0/_dk_, suivi du site de premier niveau qui a chargé la ressource. Ce préfixe vous indique pour quelle page une image ou un script tiers a été chargé.

Deux dossiers voisins sont souvent confondus avec le cache. Code Cache (sous-dossiers js et wasm) contient du JavaScript et du WebAssembly compilés, indexés par l’URL du script : il montre que les scripts d’un site ont été exécutés, et non ce qui a été affiché. GPUCache contient des shaders graphiques compilés et présente peu de valeur probante.

Cache2 de Firefox

Firefox 32 et les versions ultérieures utilisent le format cache2 dans le profil local (et non itinérant) : %LOCALAPPDATA%\Mozilla\Firefox\Profiles\<profile>\cache2\entries. Chaque entrée correspond à un fichier, nommé d’après le hachage SHA-1 de sa clé, composé de 40 chiffres hexadécimaux. Le fichier contient d’abord le contenu, puis les métadonnées : un hachage de 4 octets des métadonnées, les hachages des blocs (2 octets par bloc de 256 KiB), un en-tête (version, nombre de récupérations, dernière récupération, dernière modification, score de fréquence et de récence, date d’expiration, taille de la clé, indicateurs), la clé se terminant par l’URL (précédée d’indicateurs courts tels que a,:) et des éléments nommés tels que request-method et response-head, qui contient les en-têtes complets de la réponse. Les 4 derniers octets constituent un décalage en ordre gros-boutiste vers le début des métadonnées, égal à la longueur du contenu. Les horodatages de l’en-tête sont exprimés en secondes Unix sur 32 bits, en ordre gros-boutiste. cache2\index récapitule toutes les entrées (hachages, score de fréquence et de récence, indicateurs) et ne contient pas d’URL.

Exemple détaillé : lecture d’une entrée cache2

Un fichier d’entrée a une longueur de 15 240 octets. Ses 4 derniers octets sont 00 00 3A 98 = 0x3A98 = 15 000 ; les octets 0 à 14 999 constituent donc le contenu mis en cache (ils commencent par 89 50 4E 47, un PNG) et les métadonnées commencent au décalage 15 000. Le champ de dernière récupération contient 69 B5 60 85 = 1 773 494 405 secondes depuis le 1970-01-01 = 2026-03-14T13:20:05Z. L’élément response-head contient Date: Sat, 14 Mar 2026 13:20:03 GMT. L’horloge locale et celle du serveur concordent à 2 secondes près, ce qui correspond à un temps de transfert normal ; aucune correction de décalage n’est donc nécessaire pour cette période.

Outils et limites

Exemples d’outils gratuits : ChromeCacheView et MozillaCacheView de NirSoft affichent l’URL, le type de contenu, l’horodatage du serveur et celui de dernière modification, et exportent le contenu ; Plaso dispose des analyseurs chrome_cache et firefox_cache2 ; Hindsight analyse le cache de Chromium conjointement avec l’historique. Quel que soit l’outil, ouvrez manuellement une entrée et confirmez les horodatages.

Un cache a une capacité limitée. Les navigateurs le dimensionnent en fonction des paramètres ou de l’espace disque disponible et évincent les entrées les moins récemment utilisées ; les réponses marquées Cache-Control: no-store, fréquentes sur les pages bancaires et de connexion, ne sont jamais écrites ; et l’utilisateur peut vider le cache. L’absence d’une entrée dans le cache ne prouve pas qu’une page n’a pas été visitée.

Navigation privée

Les modes navigation privée de Chrome, InPrivate d’Edge et navigation privée de Firefox fonctionnent tous selon le même principe. Le navigateur n’écrit ni l’historique, ni la liste des téléchargements, ni les données de formulaire, ni les recherches saisies ; les cookies et les données des sites restent en mémoire et sont supprimés à la fermeture de la dernière fenêtre privée ; et le cache HTTP est conservé en mémoire plutôt que dans Cache_Data ou cache2. Les trois conservent les fichiers téléchargés dans une fenêtre privée et les marque-pages (favoris) créés dans celle-ci, car ils sont stockés en dehors de la session privée. Le mode privé protège contre le prochain utilisateur du profil, et non contre le système d’exploitation, le réseau ou les sites visités.

Les traces qui subsistent se trouvent donc en dehors des bases de données propres au navigateur :

Points à appliquer avec précision :

• Zone.Identifier. Pour un téléchargement dans une fenêtre normale, Chromium sous Windows 10 et 11 écrit HostUrl et ReferrerUrl. Pour un téléchargement en mode navigation privée, il ne transmet pas l’URL : le flux conserve ZoneId=3, mais HostUrl contient la valeur de remplacement about:internet et ReferrerUrl est absent. Confirmez le comportement de la version concernée par votre affaire au moyen d’un téléchargement de test.
• Prefetch et BAM prouvent que chrome.exe ou firefox.exe a été exécuté, et non qu’une fenêtre privée a été utilisée. Prefetch n’enregistre pas les arguments de ligne de commande ; un commutateur tel que --incognito n’apparaît donc que là où les lignes de commande sont journalisées, par exemple dans l’événement de sécurité 4688 lorsque l’audit des lignes de commande est activé ; une fenêtre ouverte avec Ctrl+Shift+N dans un navigateur déjà en cours d’exécution n’est pas du tout lancée avec ce commutateur.
• Cache du client DNS. Sur un système en fonctionnement, ipconfig /displaydns répertorie les noms résolus par le client DNS de Windows ; ce cache est volatil et disparaît après un redémarrage. Un navigateur qui résout lui-même les noms, comme Chrome lorsque son résolveur intégré est activé, peut contourner ce cache, et un navigateur utilisant DNS sur HTTPS contourne également les journaux du serveur DNS local.
• Les journaux réseau indiquent généralement les noms d’hôte, et non les URL complètes : pour HTTPS, un proxy sans interception journalise l’hôte et le port de la requête CONNECT, et non le chemin.

Un historique effacé n’est pas de la navigation privée

L’effacement de l’historique supprime des lignes qui ont été écrites ; la navigation privée ne les écrit jamais. Cette différence est importante, car des lignes supprimées peuvent subsister. Dans une implémentation générique de SQLite, une ligne supprimée se retrouve dans l’espace libre d’une page ou dans une page de la liste des pages libres jusqu’à sa réutilisation ou à l’exécution de VACUUM, mais Chromium et Firefox compilent SQLite avec la suppression sécurisée activée, ce qui écrase le contenu supprimé avec des zéros dans le fichier principal. Des copies peuvent néanmoins subsister dans le journal d’annulation (History-journal dans Chromium) ou le journal d’écriture anticipée (places.sqlite-wal dans Firefox), dans les clichés instantanés de volumes et dans les enregistrements $UsnJrnl des fichiers de cache supprimés au moment de l’effacement. SRUM et Prefetch ne sont aucunement touchés par la fonction d’effacement du navigateur.

Formuler une constatation à partir de traces indirectes

Lorsque seules des traces indirectes existent, indiquez chaque source et sa limite, et ne présentez pas l’utilisation d’une fenêtre privée comme un fait à moins qu’un élément ne la démontre. Formulation appropriée : « Les traces sont compatibles avec une navigation vers transfer.example.com dans une fenêtre privée ; l’historique du navigateur lui-même ne contient aucun enregistrement de ce site. » Énumérez ensuite les autres hypothèses que vous avez vérifiées : autre navigateur ou profil, historique effacé ou autre appareil.

Exemple détaillé : un reçu sans historique

Une collecte de triage sous Windows 11 provenant d’une autre affaire, pour l’utilisateur lferraz, montre les éléments suivants :

• History de Chrome : aucune visite ni aucun téléchargement pour transfer.example.com. La visite la plus ancienne dans la base de données date du 2026-04-21T15:02:41Z.
• C:\Users\lferraz\Downloads\upload-receipt.pdf, création $SI le 2026-04-21T13:41:07Z, avec Zone.Identifier ZoneId=3, ReferrerUrl=https://transfer.example.com/upload/done, HostUrl=https://transfer.example.com/r/8f3a/upload-receipt.pdf.
• Utilisation des données réseau dans SRUM pour chrome.exe, utilisateur lferraz, intervalle se terminant à 14:00:00Z (ligne précédente à 13:00:00Z) : BytesSent 734 003 200, BytesRecvd 9 437 184.
• Cache_Data contient uniquement index et de nouveaux fichiers data_0 à data_3 sans aucune entrée, créés le 2026-04-21T15:01:58Z.

Calcul. 734 003 200 ÷ 1 048 576 = 700 MiB envoyés et 9 437 184 ÷ 1 048 576 = 9 MiB reçus entre 13:00:00Z et 14:00:00Z, soit un rapport d’environ 78:1 compatible avec un téléversement. Le téléchargement à 13:41:07Z se situe dans cet intervalle.

Ce qui peut être conclu. Un fichier a été enregistré à 13:41:07Z depuis une URL sur transfer.example.com, après une page de ce site (/upload/done). chrome.exe, sous le compte lferraz, a envoyé environ 700 MiB au cours de la même heure.

Ce que l’hypothèse de navigation privée doit expliquer. La valeur réelle de HostUrl va à l’encontre d’un téléchargement en mode navigation privée de Chrome, qui aurait enregistré about:internet. Un cache recréé à 15:01:58Z et un historique qui commence à 15:02:41Z correspondent à un effacement des données de navigation peu avant 15:02, et non à une navigation privée, qui laisse le cache normal intact. Étapes suivantes : récupérer par carving les anciennes pages de la base History dans History-journal, l’espace non alloué et les clichés instantanés, vérifier dans $UsnJrnl la suppression de fichiers f_ vers 15:01Z, et examiner Edge ainsi que les autres profils Chrome, car un autre navigateur Chromium pourrait avoir écrit le même flux.

Ce qui ne peut pas être conclu. Ni SRUM ni Zone.Identifier n’indiquent ce qui a été téléversé ou que les 700 MiB ont été envoyés à transfer.example.com ; SRUM ne contient aucune destination. Les journaux du proxy ou du DNS du réseau sont nécessaires pour établir ce lien.

Points clés pour l’examen : Attendez-vous à lire l’URL, l’en-tête Date ou le type de contenu d’une entrée de cache, ou à calculer le décalage des métadonnées d’une entrée cache2 de Firefox à partir des 4 derniers octets. Préparez-vous à déterminer quels artefacts subsistent après une navigation privée, à relever une valeur HostUrl ou un nombre d’octets SRUM, et à reconnaître qu’une valeur HostUrl réelle sur un téléchargement Chromium n’est pas compatible avec le mode navigation privée. Les questions peuvent opposer l’historique effacé (copies éventuellement récupérables) à la navigation privée (rien n’est écrit).

Points essentiels

• Les entrées du cache contiennent le contenu, la clé URL et les en-têtes de réponse du serveur ; l’en-tête Date constitue une horloge externe pour vérifier les décalages.
• Chrome sous Windows utilise le format blockfile dans Cache_Data (index, data_0 à data_3, fichiers f_) ; Firefox 32 et versions ultérieures utilise un fichier cache2\entries par entrée, avec les métadonnées après le contenu.
• Les caches ont une taille limitée, ne conservent pas les réponses no-store et peuvent être vidés ; une entrée manquante ne prouve donc rien.
• La navigation privée n’écrit ni historique, ni cookies, ni données de formulaire, ni cache disque, mais les téléchargements, les marque-pages, Prefetch, BAM, SRUM, les fichiers LNK, la mémoire et les journaux réseau subsistent.
• Les téléchargements en mode navigation privée de Chrome portent ZoneId=3 avec HostUrl=about:internet ; une URL réelle oriente vers une autre explication.
• L’historique effacé est remplacé par des zéros dans la base de données principale par la suppression sécurisée, mais peut subsister dans les journaux, les fichiers WAL et les clichés instantanés ; la navigation privée n’y laisse rien.