Browser forensics, end to end

Nearly every browser an examiner meets is one of two families. Chromium (the Blink engine) powers Chrome, Edge, Brave, Opera, Vivaldi, Yandex, and the browser hidden inside Electron apps like Slack, Discord and Teams. Gecko powers Mozilla Firefox and its forks (LibreWolf, Waterfox, Tor Browser). These two families cover 99% of the browsers in the wild.

Before opening a single artifact, the containers come first. Almost everything a browser stores lives in one of five formats. Recognising the container already settles how to read the file — and, crucially, how to recover what was "deleted" from it.

A timestamp is only as good as the epoch it counts from. Browsers use two different origins, and getting them wrong throws every event off by centuries. This is the single most common browser-forensics mistake.

Two acronyms run through this section. DPAPI is the Windows Data Protection API, the operating system service that encrypts a blob against the logged-on user's credentials so only that user on that machine can decrypt it. NSS is Network Security Services, the Mozilla cryptography library Firefox uses instead. Saved passwords and cookie values are encrypted at rest by one or the other. The key chain is what decides exactly what has to be preserved to decrypt them later — and why simply reading Login Data yields ciphertext, not passwords.

This is the heart of browser forensics: not just which pages were open, but the difference between a link that was clicked and an address that was typed — and even text the user typed into the address bar and then thought better of. Typed navigation is intent.

Who is behind the keyboard? Cookies, saved logins, autofill, addresses and payment methods answer that — and they are exactly the artifacts protected by the encryption chain from Section 4.

Modern sites are applications. WhatsApp Web, Slack, crypto wallets and password-manager extensions keep real state on disk — chat fragments, tokens, wallet vaults — in LevelDB and IndexedDB. This is where a lot of the richest, least-expected evidence hides.

What was on screen when the browser last closed? And what did those pages actually contain? Session state and the disk cache answer both — including tabs a user closed and pages the live web no longer serves.

Beyond pages and logins, the browser keeps low-level network memory — which servers it has spoken to, which enforce HTTPS, and which sites tried to track a user across others. Niche, but decisive in the right case.

"I cleared my history" is rarely the end of the story. Because of how the substrates work, deleted browsing leaves echoes in several places at once.

Two artifacts sit outside the usual history-and-cookies story, and both get skipped far too often. One decides where every address-bar search is sent; the other records hardware the browser found on the local network. Neither is a page visit, so neither shows up in a history review — and that is exactly why they survive one.

Everything above is engine behaviour, true of any tool. Here is how Crow-Eye turns it into evidence — the one place this guide talks about the product.

Parsing writes 37 tables (all listed below). The Charts button on any browser tab opens the same browser_analysis.db as an interactive dashboard, and two rules hold everywhere in it: activity type is the colour, and the site is the pivot. Those two settle how every chart on the page is read.

Everything above is behaviour. This is the wire format — every magic number and byte layout the parser actually reads. Pick a structure, then click any byte to see which field it belongs to, what it decodes to, and why it matters.

The bytes are real. Every map below was measured off a live Chromium, Edge or Firefox profile, and each structure was validated against its own magic number before a single field was trusted. A decoder that cannot confirm its magic returns nothing rather than a plausible guess, because a wrong offset in a forensics tool produces convincing wrong evidence — three of the offsets on this page were wrong at some point, and each one decoded to something that looked entirely reasonable.

Anywhere a byte could carry real browsing, it has been replaced with a placeholder of exactly the same length, so every offset shown stays true. Bytes that no field claims are greyed out and say so when clicked: undocumented space is a finding, not a gap.

All Chromium structures are little-endian; Firefox cache2 is big-endian. That single difference is the most common source of garbage values when people write their own parsers.

A column that is empty proves nothing on its own. It could mean the artifact held nothing, or it could mean the tool did not look. Those are completely different findings, and a report that cannot separate them is not evidence. So this section states, for every column that comes back empty, which of the two it is.

Section 12 ended on "one case database". This is that database, table by table — all 37 of them, so nothing in this guide is left without an address in the product. They live in Target_Artifacts\browser_analysis.db, and the same set is produced for Chromium, Gecko and Electron targets alike, and for a live system, a collected folder or a forensic image. On a collected folder or an image, user_name is the Users folder the profile was found in and sid comes from that evidence’s own SOFTWARE hive when the case holds a single source (otherwise it is left empty).

Every table carries the same seven provenance columns — browser, vendor, user_name, sid, profile, source_path and parsed_at. That is what keeps two users' Default\History from blurring together, and it is why the columns below list only what is specific to each table.