How It Works

A short tour of what hack-browser-data does under the hood: discover, copy, decrypt, export.

A short tour of what hack-browser-data does when you run it — enough to use the tool well and to make sense of partial results. For the commands, see the CLI reference ; for the output schema, Output & Data Formats .

At a high level, every extraction follows the same path:

discover browsers + profiles
   → copy live files into an isolated temp directory
   → retrieve the platform master key
   → decrypt sensitive fields / read plaintext fields
   → export one file per data category

#The five-step pipeline

The Chromium and Firefox engines use the same five-stage orchestration, with engine-specific readers and key handling inside it:

The tool copies first, then reads — it never touches the browser’s live files in place, which may be locked or changing.

#What’s encrypted, and what isn’t

Most browser data is plaintext. For Chromium, only 3 of the 9 categories are encrypted and need the master key:

This is why a run can partly succeed: if a master key cannot be retrieved, records may still be exported with blank encrypted fields while the six categories that do not require decryption continue normally. Extraction is best-effort — a missing file can skip one category, a bad row can skip one record, and master-key failure is non-fatal.

#Cipher tiers at a glance

Each encrypted value carries a 3-byte prefix that picks the cipher and where its key comes from. You rarely need this — except for the two troubleshooting cases below.

• v20 cookies come back empty on Windows? You’re on the standard build — use the Windows App-Bound Encryption build .
• Blank fields from a Flatpak profile? Chromium’s v12 SecretPortal provider is not implemented yet. Extractors currently omit the per-row decryption error, so the affected field can be blank without a dedicated message in the output.

Keys come from DPAPI on Windows, the login Keychain on macOS (each browser’s Safe Storage item), and either a fixed v10 fallback or the D-Bus Secret Service for v11 on Linux. On macOS, the tool asks for the current login password when the selected browser needs Keychain access; a system Keychain dialog may appear as a fallback. Keychain-backed password decryption may fail on macOS 26.4 or later. See the macOS FAQ .

#Export model

Results are aggregated across all profiles into one file per non-empty category. See Output & Data Formats for the file model and the per-category schema.

#Cross-host decryption

For Chromium-based browsers, key retrieval and file copying are separate steps. You can export keys on the origin host and restore the matching profile data on another supported OS — even when that browser cannot be installed on the analyst system. See Cross-Host Decryption for the dumpkeys → archive → restore workflow.

#Other engines

This pipeline describes Chromium. The two non-Chromium engines handle keys differently and have their own pages:

• Firefox — per-profile key derived from key4.db (NSS); no OS keychain.
• Safari — macOS-only, Keychain-backed passwords, needs Full Disk Access.

Yandex is a Chromium fork with additional password and credit-card formats that HackBrowserData handles separately. Profiles protected by Yandex Master Password skip protected saved-password records; cookies and other requested categories can still export. For per-browser coverage, see Supported Browsers .