Navigateurs Chromium : historique, téléchargements, cookies et sessions

La plupart des ordinateurs Windows que vous examinez exécutent au moins un navigateur basé sur Chromium, et le navigateur est souvent l’endroit où l’intention devient visible : ce que l’utilisateur a recherché, quelle page il a ouverte, quel fichier il a téléchargé et depuis quelle source. Cette leçon traite du profil Chromium : son emplacement, les fichiers SQLite et JSON qu’il contient, la lecture des visites, des transitions et des téléchargements avec des heures UTC exactes, les implications du chiffrement des cookies et des mots de passe pour un examinateur, et la collecte des bases de données afin de ne pas perdre les enregistrements récents et supprimés. Le cache et la navigation privée sont abordés dans la leçon 4.3.

Un format de profil, de nombreux navigateurs

Google Chrome, Microsoft Edge, Brave, Opera et Vivaldi partagent le format de profil de Chromium ; les mêmes fichiers, tables et analyseurs s’appliquent donc à tous. Chaque navigateur conserve un dossier User Data, qui contient un dossier par profil : Default pour le premier profil, puis Profile 1, Profile 2, etc.

%LOCALAPPDATA% correspond à C:\Users\<user>\AppData\Local ; le chemin lui-même rattache donc le profil à un compte Windows. Vérifiez tous les dossiers de profil, pas seulement Default : un deuxième profil est un emplacement courant pour les activités que l’utilisateur souhaitait garder séparées.

Local State, situé un niveau plus haut dans User Data, est un fichier JSON commun à l’ensemble du navigateur. Sous profile.info_cache, il répertorie chaque dossier de profil avec son name d’affichage et, pour un profil connecté, l’adresse e-mail du compte dans user_name. Sous os_crypt.encrypted_key, il contient la clé encodée en Base64 qui protège les cookies et les mots de passe enregistrés. Une fois décodée, cette valeur commence par le texte ASCII DPAPI, suivi d’un bloc de données protégé par l’API de protection des données de Windows (DPAPI) pour cet utilisateur.

La base de données History

History est une base de données SQLite. Chromium stocke ses horodatages au format WebKit : en microsecondes depuis le 1601-01-01 UTC (leçon 3.1). Chrome supprime les visites datant de plus de 90 jours environ ; une période ancienne vide peut donc résulter de l’expiration des données, et non d’une absence d’activité.

urls et visits

La table urls contient une ligne par URL distincte : id, url, title, visit_count, typed_count (le nombre de fois où l’URL a été saisie dans l’omnibox, la barre combinant adresse et recherche) et last_visit_time. Il s’agit d’un récapitulatif. La table visits contient une ligne par visite, ce dont une chronologie a besoin :

• url : le urls.id de la page visitée (une clé étrangère, et non du texte) ;
• visit_time : le début de la visite (horodatage WebKit) ;
• from_visit : le visits.id de la visite d’origine, ce qui vous permet de reconstituer les chaînes de navigation ;
• transition : la manière dont l’utilisateur est arrivé ;
• visit_duration : la durée pendant laquelle la page est restée chargée dans son onglet, en microsecondes, jusqu’à la navigation de l’onglet vers une autre page ou sa fermeture.

Valeurs de transition

L’octet de poids faible de transition (transition & 0xFF) indique le type principal ; les bits de poids fort sont des qualificatifs.

Les bits qualificatifs comprennent 0x01000000 (précédent/suivant), 0x02000000 (depuis la barre d’adresse), 0x10000000 et 0x20000000 (début et fin d’une chaîne de redirections), 0x40000000 (redirection côté client) et 0x80000000 (redirection côté serveur). Ainsi, 805 306 368 = 0x30000000 correspond à un LINK qui a commencé et terminé une chaîne, et 838 860 805 = 0x32000005 correspond à GENERATED depuis la barre d’adresse. Certains outils affichent les valeurs dont le bit de poids le plus fort est positionné sous forme d’entiers négatifs ; le masque donne le même type principal dans les deux cas. Une visite TYPED constitue un indice plus fort de l’intention de l’utilisateur qu’une visite LINK, qu’une page ou un script peut déclencher.

downloads et downloads_url_chains

La table downloads contient une ligne par téléchargement : target_path (chemin final), current_path (chemin pendant le téléchargement, normalement égal à target_path une fois le téléchargement terminé), start_time, end_time, received_bytes, total_bytes, state (1 terminé, 2 annulé, 4 interrompu), danger_type (0 signifie qu’aucun avertissement n’a été affiché), tab_url et referrer (la page depuis laquelle le téléchargement a démarré), mime_type, opened (1 si le fichier a été ouvert depuis l’interface de téléchargement du navigateur) et last_access_time. downloads_url_chains lui est reliée par id et contient une ligne par chain_index ; l’indice le plus élevé correspond à l’URL depuis laquelle le fichier a réellement été fourni, et les indices inférieurs montrent les redirections qui y ont conduit. Le fichier sur disque possède souvent un flux Zone.Identifier dont le HostUrl devrait correspondre à cette URL finale (leçon 1.4).

keyword_search_terms

keyword_search_terms stocke les termes de recherche saisis dans l’omnibox (term, et normalized_term en minuscules), avec url_id pointant vers la ligne urls de la page de résultats. Une jointure avec visits donne l’heure de chaque recherche.

Autres fichiers du profil

Tous les horodatages de Chromium ne sont pas au format WebKit : date_created et date_last_used dans la table autofill sont exprimés en secondes Unix. Vérifiez l’ordre de grandeur de chaque valeur avant de la convertir.

Sessions

Les versions récentes conservent les fichiers Session_<n> et Tabs_<n> dans le dossier Sessions, où <n> est un horodatage WebKit ; les anciennes versions utilisaient Current Session, Last Session, Current Tabs et Last Tabs dans le dossier du profil. Ce sont des fichiers SNSS : la signature SNSS, une version sur 32 bits, puis une série de commandes qui enregistrent les fenêtres, les onglets et les entrées de navigation de chaque onglet, avec les URL et les titres. Ils peuvent révéler les pages qui étaient ouvertes à la fermeture du navigateur, y compris certaines qui ne figurent plus dans History.

Cookies et chiffrement

Depuis Chrome 96, la base de données des cookies est Network\Cookies (auparavant, Cookies dans le dossier du profil). La table cookies contient creation_utc, host_key, name, path, expires_utc, last_access_utc et la valeur dans encrypted_value, tous les horodatages étant au format WebKit. Depuis Chrome 80, les valeurs portent le préfixe v10 et sont chiffrées en AES-256-GCM à l’aide de la clé de Local State, elle-même protégée par DPAPI. Leur déchiffrement hors ligne nécessite donc la clé principale DPAPI de l’utilisateur, généralement récupérée à l’aide du mot de passe de celui-ci. Depuis Chrome 127 sous Windows, le chiffrement lié à l’application protège les nouveaux cookies (préfixe v20) à l’aide d’une clé supplémentaire que seul un service Chrome exécuté en tant que SYSTEM accepte de fournir, et uniquement à l’application Chrome. Le déchiffrement hors ligne des valeurs v20 issues d’une collecte de triage est bien plus difficile et souvent irréalisable en pratique. Vous avez rarement besoin des valeurs des cookies : l’hôte, le nom et les trois horodatages montrent généralement qu’un compte a visité un service ou s’y est connecté, et à quel moment. Les mots de passe enregistrés dans Login Data sont également chiffrés ; l’URL, le nom d’utilisateur et les dates sont en clair.

Collecte et analyse en toute sécurité

Collectez chaque base de données avec ses fichiers associés. Un journal de restauration (History-journal) contient des copies de pages antérieures à une modification et peut contenir des enregistrements écrasés depuis. Une base de données en mode journalisation anticipée possède des fichiers -wal et -shm ; le WAL contient les modifications récentes qui n’ont pas encore été écrites dans le fichier principal. Collectez tous les fichiers présents et travaillez sur des copies : l’ouverture d’une base de données WAL peut y intégrer le journal et modifier les éléments de preuve. Chromium compile SQLite avec la suppression sécurisée activée ; les lignes supprimées sont donc normalement écrasées par des zéros dans le fichier principal. Des copies plus anciennes peuvent subsister dans le journal ou le WAL, dans les clichés instantanés de volumes ou dans l’espace non alloué, et leur récupération par carving nécessite un outil de récupération SQLite ainsi qu’une vérification en hexadécimal.

DB Browser for SQLite (ouvert en lecture seule) suffit pour les requêtes manuelles. Hindsight (obsidianforensics) analyse un profil Chromium entier pour produire une chronologie unique, BrowsingHistoryView de NirSoft lit plusieurs navigateurs à la fois, et Plaso dispose de modules d’analyse Chrome tels que chrome_27_history (leçon 3.3). Vérifiez toute valeur issue de l’analyse par rapport à la table brute.

Exemple détaillé : visites d’ana et téléchargement

La collecte de triage contient C:\Users\ana\AppData\Local\Google\Chrome\User Data\Default\History et History-journal. Dans Local State, profile.info_cache ne répertorie que Default, avec une adresse e-mail dans user_name. La requête est SELECT v.id, u.url, datetime(v.visit_time/1000000 - 11644473600, 'unixepoch') AS utc, v.transition & 0xFF AS core, v.from_visit, v.visit_duration FROM visits v JOIN urls u ON v.url = u.id ORDER BY v.visit_time;. La division entière supprime les microsecondes ; écrivez le résultat au format ISO 8601 avec T et Z.

Vérifiez manuellement la ligne clé. visit_time vaut 13 417 970 987 412 563. Division par 1 000 000 : 13 417 970 987 s depuis 1601. Soustraction de 11 644 473 600 : Unix 1 773 497 387. Puisque 1 773 446 400 correspond à 2026-03-14T00:00:00Z, les 50 987 s restantes = 14 h (50 400) + 9 min (540) + 47 s, ce qui donne 2026-03-14T14:09:47Z. La durée, 1 275 384 220 µs, correspond à 1 275 s, soit 21 min 15 s ; la page est donc restée chargée jusqu’à environ 14:31:02Z, ce qui concorde avec l’intervalle SRUM se terminant à 14:31:09Z (leçons 2.8 et 3.4). keyword_search_terms contient send large files free avec un url_id égal au urls.id de la visite 4180.

La table downloads contient une ligne avec target_path égal à C:\Users\ana\Downloads\xfer.exe, start_time à 13 417 892 317 250 948 et end_time à 13 417 892 320 031 776, received_bytes et total_bytes tous deux à 1 482 752, state à 1 et danger_type à 0. Début : 13 417 892 317 − 11 644 473 600 = 1 773 418 717 ; la soustraction de 1 773 360 000 (2026-03-13T00:00:00Z) laisse 58 717 s = 16 h (57 600) + 18 min (1 080) + 37 s, soit 2026-03-13T16:18:37Z. Fin : 3 s plus tard, 2026-03-13T16:18:40Z. downloads_url_chains donne l’indice 0 https://files.example.net/get/xfer-latest et l’indice 1 https://cdn.files.example.net/b/7f3a/xfer.exe, la source du fichier. L’heure de fin correspond à l’heure de modification $SI et à l’horodatage Shimcache de xfer.exe (leçon 2.3), la taille correspond à celle d’Amcache, et la première exécution à 16:20:02Z a eu lieu 82 secondes plus tard. Le constat : le profil Chrome du compte d’ana a téléchargé xfer.exe depuis cdn.files.example.net entre 16:18:37Z et 16:18:40Z.

Points clés pour l’examen : Attendez-vous à convertir les horodatages WebKit de visits, downloads ou cookies en UTC au format ISO 8601, à joindre visits.url à urls.id pour retrouver la page correspondant à une visite, et à lire l’URL finale dans downloads_url_chains. Connaissez les types principaux de transition après application du masque 0xFF, sachez que visit_duration est exprimé en microsecondes et quel fichier répond à quelle question, notamment Local State pour les profils et les comptes. Rappelez-vous que les horodatages d’autofill sont exprimés en secondes Unix, et non au format WebKit.

Points essentiels

• Chrome, Edge, Brave, Opera et Vivaldi partagent un même format de profil sous User Data\<Profile> ; Local State répertorie les profils et contient la clé protégée par DPAPI.
• History : urls récapitule chaque URL ; visits enregistre chaque visite avec visit_time, from_visit, transition (type principal = octet de poids faible) et visit_duration en microsecondes.
• downloads fournit les chemins, les horodatages, les tailles et l’état ; downloads_url_chains fournit les redirections, le chain_index le plus élevé correspondant à l’URL finale du fichier.
• Les valeurs des cookies sont chiffrées (v10 avec la clé protégée par DPAPI, v20 avec le chiffrement lié à l’application depuis Chrome 127), mais les hôtes, les noms et les horodatages sont en clair et suffisent généralement.
• Collectez les fichiers -journal, -wal et -shm avec chaque base de données et travaillez sur des copies ; la suppression sécurisée remplit de zéros les lignes supprimées, recherchez donc des copies plus anciennes dans les journaux, les fichiers WAL et les clichés instantanés.