HackBrowserData: Decrypting Browser Data on Windows, macOS and Linux

What HackBrowserData extracts and who actually needs it

HackBrowserData is a single command-line binary that reads a browser profile on disk and writes out the credentials and activity stored inside it. The README lists nine categories: passwords, cookies, bookmarks, history, downloads, credit cards, extensions, localStorage and sessionStorage. Coverage is not uniform. Chromium-based browsers support all nine. Firefox supports everything except credit cards and sessionStorage. Safari supports passwords, cookies, bookmarks, history, downloads, extensions and localStorage, but not credit cards or sessionStorage.

The intended audience is narrow and the README says so directly: the tool is "only intended for security research", and users carry the legal responsibility. In practice that means incident responders pulling credentials from a compromised workstation, forensic analysts who need browser artifacts in a readable format, and penetration testers validating what a post-exploitation step would yield. It is not an endpoint monitoring product, and it does not run as a background service.

The browser list is unusually wide. Beyond Chrome, Edge, Brave, Opera, Vivaldi and Firefox, it covers Windows-only builds such as DuckDuckGo, QQ, 360 ChromeX, 360 Chrome, DC Browser and Sogou Explorer. Those last entries matter because they are exactly the browsers a general-purpose tool tends to skip.

How the decryption pipeline is put together

The repository is organized around a small number of top-level packages: browser/, cmd/, crypto/, filemanager/, masterkey/, output/ and types/. That layout matches the data flow the README describes. A command under cmd/ selects browsers and categories, the browser/ package knows where each profile keeps its SQLite databases and LevelDB stores, and masterkey/ plus crypto/ recover the key material needed to turn encrypted blobs back into plaintext. Output is written through output/ in JSON, CSV or a cookie-editor format.

The dependency list confirms the platform-specific parts. On macOS, keychainbreaker and a plist parser handle Keychain access and Safari property lists; binarycookies parses Safari's cookie format. On Linux, the D-Bus libraries and go-dbus-keyring talk to the Secret Service. SQLite reading uses modernc.org/sqlite, a pure-Go implementation, and goleveldb reads Chromium's LevelDB stores. Nothing in the module graph requires cgo for the default build, which is why a plain go build produces a portable binary.

The interesting architectural choice is the split between key acquisition and data decryption. The dumpkeys, archive and restore commands exist to separate those two steps, and that separation is what makes cross-host work possible at all.

Installing HackBrowserData and running a first dump

The README's install path is to download the release for your system from the GitHub releases page and run the binary. There is no package manager step. It also warns that Windows Defender and other antivirus products may block the binary, and suggests compiling from source if that happens.

Building from source needs Go 1.20 or later. The README gives these commands:

git clone https://github.com/moonD4rk/HackBrowserData
cd HackBrowserData
go build ./cmd/hack-browser-data/

The Makefile offers a shorter route with the same result, producing a binary named hack-browser-data:

make build

Before extracting anything, list what the tool can see. The list command reports detected browsers and profiles, which tells you whether the profile you want is where you expect it:

hack-browser-data list

A first real extraction is the dump command, which is also the default command. Flags control the browser, the categories, the output directory and the format:

hack-browser-data dump -b chrome -c password,cookie -f json -d results

That writes JSON files into results/ for Chrome passwords and cookies only. Omitting -b and -c leaves both at their default of all, so a bare hack-browser-data run attempts every supported browser and every category. On macOS, some Chromium-based browsers require the current user password to decrypt, and the --keychain-pw flag exists to supply it non-interactively.

Cross-host decryption with archive, dumpkeys and restore

The v1.1.0 release is titled "Cross-host Decryption and Restore", and the README treats it as a headline capability rather than a footnote. The workflow has three commands. On the origin machine, archive packs the profile files that matter for decryption into a zip. Also on the origin machine, dumpkeys exports the Chromium master keys as JSON. On the analyst machine, restore decrypts the copied profile using those exported keys.

The README gives the example of a Windows-only browser whose data is decryptable on any OS: pull the files with archive, export the keys with dumpkeys, then decrypt on macOS or Linux with restore. That is a genuine architectural difference from tools that must run on the same host and OS as the browser they target. It also changes the operational model. Key extraction and data decryption become two separate actions that can happen in different places, at different times, under different privilege requirements.

The trade-off is that the exported master keys are themselves sensitive material. dumpkeys writes them to JSON, and the README does not describe any encryption or access control on that file. Anyone holding the key file and the archived profile can decrypt the data, which is the point, but it also means the key file deserves the same handling as the plaintext output.

Where HackBrowserData fails or is the wrong tool

The README is candid about several failure modes, and they are worth reading before trusting a run. On macOS, some Chromium-based browsers require the current user password to decrypt, and password decryption may fail on macOS 26.4 or later. Safari extraction requires Full Disk Access, granted in System Settings under Privacy & Security; without it, the README says extraction returns empty results. An empty result set is a silent failure, not an error, which is the worst kind for a forensic workflow.

On Windows, cookies from Chromium 127 and later in Chrome, Chrome Beta, Edge, Brave and CocCoc are protected by App-Bound Encryption. Decrypting them requires a C payload built through make payload and embedded with make build-windows. The standard cross-compiled Windows build does not include it. If you build with GOOS=windows and skip the payload step, those cookies will not decrypt, and the README flags that limitation in the build comment itself.

The wrong-tool cases follow from that. If you need a defensible chain of custody, hashing and a report format, this tool writes JSON, CSV or cookie-editor files and nothing more. If you need to monitor a live endpoint continuously, there is no daemon mode. And if the target profile belongs to a browser version newer than the one the tool was built against, expect gaps rather than an error message telling you what changed.

How it compares with a general forensic suite

The closest alternative in this space is a full digital forensics platform, and the difference is scope rather than quality. A suite such as Autopsy or a commercial tool like Magnet AXIOM ingests a disk image, indexes artifacts across the whole filesystem, and produces a report with timestamps and provenance. HackBrowserData does one thing: it reads browser profiles that are already accessible to the process and writes the decrypted contents to files.

That narrowness is the reason it works where a suite is awkward. A single Go binary with a pure-Go SQLite reader runs on a workstation without an install step, and the archive/dumpkeys/restore split means the decryption host does not need to be the host that captured the data, or even run the same operating system as the browser. A full suite normally expects to mount an image and work from there.

The other comparison point is browser-specific extractors, which typically target one engine or one OS. HackBrowserData's table spans Chromium variants, Firefox and Safari across three platforms, with the Windows-only Chinese browsers covered through the cross-host path. The cost of that breadth is that each browser's quirks are handled inside one codebase, and a change in one browser's storage format can leave that entry behind while the rest keep working.

Maintenance, licence and what upgrades cost you

The repository is not archived, and the last push was on 2026-09-01. The release history shows real movement in 2026: v1.0.0 on 2026-04-29 was an architecture rewrite that added Safari and Chrome App-Bound Encryption support, and v1.1.0 on 2026-06-14 added cross-host decryption and restore. Before that, the previous release was v0.4.6 in July 2024, so the project sat quiet for roughly twenty months and then changed substantially in two releases.

That pattern carries an upgrade cost. The v1.0.0 rewrite and the v1.1.0 command additions mean anything written against the 0.4.x interface will not map cleanly onto the current one, which now has archive, dump, dumpkeys, list, restore and version subcommands. Pinning a version and reading the release notes before moving is cheaper than discovering a changed output shape mid-investigation.

The licence is MIT, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are included. MIT offers no warranty and no patent grant. That is a description of the licence text, not legal advice; if you plan to redistribute the binary inside a product, have counsel read the LICENSE file rather than this paragraph.

Editorial conclusion

Adopt HackBrowserData for authorized incident response, forensic triage or lab work where you need a single binary that covers Chromium, Firefox and Safari and can decrypt a copied profile on a different operating system. Do not adopt it for routine endpoint monitoring, for any host you do not own or have written authorization to examine, or as a substitute for a full forensic suite with evidence handling. Before trusting it in a case, verify on a test profile that the build you have matches the browser version you face: Chromium 127 and later cookies need the ABE payload from make build-windows, Safari needs Full Disk Access, and the README notes that password decryption may fail on macOS 26.4 or later.

Frequently asked questions

Official sources

1. License: MIT
2. moonD4rk/HackBrowserData on GitHub
3. Project website
4. README
5. Releases