Cross-Host Decryption
Collect Chromium keys and profile data on the origin machine, then decrypt offline on another supported operating system.
Chromium master keys are bound to the machine that created them, so you usually cannot copy a profile elsewhere and decrypt protected fields. HackBrowserData separates getting the key from doing the decryption: export the key on the origin host, then restore the matching profile data offline on another supported OS. This is the tool’s flagship capability for DFIR and remote engagements.
Note
Cross-host decryption is Chromium-only. Firefox and Safari re-derive or read their keys locally, so there’s nothing to carry across machines.
The model: three commands, two hosts
| Step | Host | Command | Produces |
|---|---|---|---|
| 1 | Origin | dumpkeys | keys.json — the Chromium master keys |
| 2 | Origin | archive | data.zip — the decryption-relevant profile files |
| 3 | Analyst | restore | results/ — the decrypted export |
archive needs no keys and performs no decryption, but data.zip is still sensitive: it can contain encrypted credential databases alongside plaintext history, bookmarks, download paths, extensions, and storage. keys.json contains the plaintext master keys needed to decrypt matching protected fields.
Walkthrough
On the origin machine — export the keys and bundle the profile files:
hack-browser-data dumpkeys --output keys.json
hack-browser-data archive --output data.zipMove both files to the analyst machine over an authenticated, encrypted channel approved for the engagement.
On the analyst machine — decrypt with the keys plus the archive:
hack-browser-data restore --keys keys.json --data-zip data.zipThat’s it — results/ now holds the decrypted data, one file per category, exactly as a local dump would produce.
Variations
A single browser from a copied User Data directory — skip archive and point restore at a directory instead of a zip:
hack-browser-data restore --keys keys.json --data-dir ./chrome-userdata --browser chromerestore takes exactly one of --data-zip or --data-dir.
Stream the keys over SSH — never write keys.json to disk on the origin host; pipe it straight into restore (--keys - reads from stdin). The data archive is transferred separately:
ssh origin "hack-browser-data dumpkeys" | hack-browser-data restore --keys - --data-zip data.zipDecrypt browsers the analyst OS can’t even install
Because restore works only from the keys file and dispatches by key length, not OS, you can decrypt data from a Windows-only browser — say Sogou or QQ Browser — on a macOS laptop, even though those browsers don’t exist for macOS. App-Bound Encryption (v20) keys are reusable cross-host the same way.
Handle both artifacts as sensitive data
keys.json contains plaintext master keys — anyone with it and the matching profile data can decrypt protected fields. dumpkeys requests mode 0600 where Unix permissions are supported, but you must verify the resulting mode or ACL. data.zip has no guaranteed restrictive mode and remains sensitive even without the keys.
- Prefer streaming (the SSH pipe above) over leaving the file on disk.
- If you must store either artifact, use encrypted media with access limited to the engagement team.
- Never commit either file, attach it to a public issue, or send it over an unencrypted channel.
- Delete both artifacts according to the engagement’s retention policy when analysis ends.
See also
dumpkeys,archive,restore— full flag references.- How It Works — why key retrieval and decryption are decoupled.