If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/moonD4rk/HackBrowserData shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1w ago
• 9 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 64% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live moonD4rk/HackBrowserData repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/moonD4rk/HackBrowserData.

What it runs against: a local clone of moonD4rk/HackBrowserData — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in moonD4rk/HackBrowserData | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 37 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of moonD4rk/HackBrowserData. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/moonD4rk/HackBrowserData.git
#   cd HackBrowserData
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of moonD4rk/HackBrowserData and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "moonD4rk/HackBrowserData(\\.git)?\\b" \\
  && ok "origin remote is moonD4rk/HackBrowserData" \\
  || miss "origin remote is not moonD4rk/HackBrowserData (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 37 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~7d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/moonD4rk/HackBrowserData"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

HackBrowserData is a CLI tool that decrypts and exports sensitive data (passwords, cookies, bookmarks, history, credit cards, extensions, localStorage, sessionStorage) from Chromium-based browsers and Firefox across Windows, macOS, and Linux. It handles platform-specific encryption schemes (DPAPI on Windows, Keychain on macOS, Secret Service on Linux) and supports 15+ browsers including Chrome, Edge, Brave, Opera, and Yandex. Modular monorepo structure: browser/ package contains platform-agnostic logic, with browser_darwin.go/browser_windows.go/browser_linux.go for OS-specific integration. browser/chromium/ handles all Chromium decryption (decrypt.go, decrypt_mixed_test.go) and data extraction (extract_password.go, extract_cookie.go, extract_creditcard.go, etc.). CLI entrypoint in root with Cobra framework.

Security researchers, penetration testers, and system administrators who need to audit browser data exposure or perform forensic analysis on machines. Contributors are typically Go developers interested in cross-platform cryptography and browser internals.

Production-ready and actively maintained. The project has 26.9k stars on GitHub, comprehensive CI/CD via GitHub Actions (build.yml, test.yml, lint.yml, release.yml), extensive test coverage across decrypt_test.go and extract_*_test.go files, and regular releases via goreleaser. Active development visible in platform-specific implementations (browser_darwin.go, browser_windows.go, browser_linux.go).

Low risk for a security tool. Dependencies are minimal and well-maintained (godbus/dbus, keychainbreaker, sqlite modernc driver). Single maintainer (moonD4rk) is potential concern for long-term maintenance. No breaking changes apparent in recent commits. Legal risk exists — tool is explicitly for security research only per disclaimer in README.

Active maintenance with regular test additions for new encryption versions (decrypt_v20_test.go). Support expanding to more browsers (DuckDuckGo, QQ, 360 ChromeX visible in README but partial implementation). Recent work on mixed encryption scenarios (decrypt_mixed_test.go) for newer Chrome versions. GitHub workflows indicate automated testing, linting, and release processes running.

Clone the repo and build with Make:

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

Or run tests with make test (uses Go 1.20+ per go.mod). Requires platform-specific tools on macOS (Keychain access) and Linux (D-Bus for Secret Service).

Daily commands: Build and run the CLI directly:

make build
./hack-browser-data -h                    # Show help
./hack-browser-data -b all                # Extract all browser data
./hack-browser-data -b chrome -t password # Extract Chrome passwords only
./hack-browser-data -h                    # List all supported browsers and data types

Run tests with make test. Development setup via make lint (golangci-lint).

• browser/chromium/decrypt.go: Core encryption/decryption engine handling DPAPI, AES-GCM, and OS Keychain integration for all Chromium browsers
• browser/browser.go: Abstraction layer defining Browser interface; controls which data types are extracted for each browser type
• browser/browser_windows.go: Windows-specific implementation using DPAPI for automatic encryption key retrieval from DPAPI secret store
• browser/browser_darwin.go: macOS-specific implementation using keychainbreaker for Keychain access and AES decryption
• browser/chromium/extract_password.go: Pattern example for sensitive data extraction; handles Chrome's encrypted password database parsing
• browser/chromium/chromium.go: Chromium base implementation routing all extraction calls to specific extract_*.go handlers
• .goreleaser.yml: Build and release configuration generating binaries for Windows/macOS/Linux across multiple architectures

For adding new data extraction types: create extract_[datatype].go in browser/chromium/ (follow pattern of extract_password.go). For new browser support: extend browser/browser.go and add browser_[name].go. For platform integration: modify browser_[os].go files. Tests must accompany all changes: extract_[type]test.go and use testutil_test.go helpers. Encryption logic goes in decrypt.go with corresponding decrypt[version]_test.go.

On macOS, Keychain password prompts may fail silently if Chrome is running (file locks on Keychain database). DPAPI Windows decryption requires running as the same user who encrypted the data. Linux requires D-Bus session access (may fail in containers/ssh without DBUS_SESSION_BUS_ADDRESS). Chrome v80+ uses DPAPI encryption on Windows but earlier versions use simpler salted cipher. Some Chromium clones (Yandex) have custom encryption schemes requiring special handling (see yandex_key.go). Firefox and Safari use entirely different data storage formats (SQLite plain text, binary Mach-O keychain) requiring separate extraction logic.

• DPAPI (Data Protection API) — Windows-specific encryption protecting Chrome/Edge passwords; understanding DPAPI entropy derivation and CryptUnprotectData is essential for Windows decryption in browser/browser_windows.go
• AES-GCM (Authenticated Encryption with Associated Data) — Chrome v81+ uses AES-256-GCM for password encryption with OS-derived keys; critical to decrypt.go's modern encryption handling
• OS Keychain/Credential Storage — macOS Keychain, Linux Secret Service, Windows Credential Manager each store encryption master keys; browser/[os].go files must interface with each to retrieve keys
• SQLite Database Forensics — Browser password/history/cookie databases are SQLite; modernc.org/sqlite driver used to query encrypted tables in extract_*.go files
• LevelDB (Key-Value Store) — Chrome uses LevelDB for LocalStorage and SessionStorage; goleveldb dependency handles parsing these non-SQL databases in extract_storage.go
• Binary Cookie Format (Mach-O) — Safari stores cookies in proprietary binary Mach-O format; binarycookies library (direct dependency) decodes these for Safari support
• D-Bus Secrets API (Linux) — Linux uses D-Bus for Secret Service (Keyring, KWallet); godbus/dbus dependency enables key retrieval from system keyring in browser_linux.go

• fortra/impacket — Provides DPAPI decryption utilities (dpapi.py) for Windows that inspired HackBrowserData's Windows decryption approach
• n0fate/Mempixie — Similar browser forensics tool for macOS focusing on in-memory extraction; complementary technique to HackBrowserData's disk-based approach
• unode/firefox_decrypt — Standalone Firefox password decryption tool; HackBrowserData integrates this logic for multi-browser support
• moond4rk/keychainbreaker — Separate macOS Keychain parsing library (direct dependency in go.mod); handles secure key extraction from Keychain DB
• moond4rk/binarycookies — Separate Safari binary cookie parser library (direct dependency); enables HackBrowserData's Safari support

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for cross-platform browser data extraction

The repo has platform-specific files (browser_darwin.go, browser_linux.go, browser_windows.go) and extensive extract_* test files, but lacks integration tests that verify end-to-end extraction across all supported browsers (Chromium variants, Firefox) on each platform. This would catch regressions when decryption logic or file parsing changes, and ensure the CLI tool works correctly in real-world scenarios.

• [ ] Create browser/integration_test.go with test fixtures for multiple browser data directories
• [ ] Add test data samples in browser/testdata/ for Chromium (cookie, password, history) and Firefox databases
• [ ] Write integration tests that call the top-level browser.GetAllBrowserData() or similar entry point
• [ ] Ensure tests run on all three platforms via GitHub Actions (update .github/workflows/test.yml if needed)

Add unit tests for browser/chromium/yandex_key.go and browser/chromium/source.go

These files exist but have minimal test coverage (yandex_testutil_test.go and source.go lack dedicated test files). Yandex browser has custom key derivation logic and source.go handles browser detection/path resolution—critical for correctness. Adding focused tests would improve reliability for Yandex users and ensure browser detection works across edge cases.

• [ ] Create browser/chromium/source_test.go with tests for browser path detection on each platform
• [ ] Create browser/chromium/yandex_key_test.go with tests for Yandex-specific key derivation (mocking system keyring if needed)
• [ ] Add test cases for missing/invalid browser paths and fallback scenarios
• [ ] Verify tests pass locally and in CI on Linux (for dbus keyring mocking)

Add missing decrypt test coverage for Safari/webkit-based browsers on macOS

The file structure shows browser/chromium/ has extensive decrypt_*.go test files (decrypt_test.go, decrypt_v20_test.go, decrypt_windows_test.go, decrypt_mixed_test.go), but there's no corresponding Safari decryption module or tests in browser/. Given that macOS users need Safari data extraction and the repo supports multiple OSes, adding Safari cookie/password decryption (which uses different keychain mechanisms than Chromium) would be a high-value feature with proper test coverage.

• [ ] Create browser/safari/safari.go to handle Safari profile detection on macOS (using browser_darwin.go patterns)
• [ ] Create browser/safari/decrypt.go for Safari's custom keychain decryption (leveraging keychainbreaker dependency)
• [ ] Add browser/safari/extract_cookie.go and browser/safari/extract_password.go following chromium module patterns
• [ ] Create comprehensive tests in browser/safari/*_test.go with fixtures for Safari Cookies.binarycookies and keychain data

• Add support for extracting Firefox login.json (currently only password table is parsed in browser/firefox); start by examining existing extract_password.go pattern and create browser/firefox/extract_password.go with test coverage
• Create comprehensive integration tests comparing extracted data across browsers in browser/browser_test.go; currently missing end-to-end tests verifying data consistency between Chrome, Edge, and Brave extractions on the same system
• Document decrypt.go's AES-GCM implementation with comments explaining the evolution from v1-v80 DPAPI to v81+ AEAD schemes; requires explaining algorithm changes in browser/chromium/decrypt_v20_test.go context

• High · Insecure Dependency: outdated golang.org/x/sys — go.mod - golang.org/x/sys v0.30.0. The dependency golang.org/x/sys v0.30.0 is used for system-level operations. While version numbers appear current, this is a critical system package used in sensitive operations like keyring access and credential handling. Any vulnerability here could compromise the entire extraction pipeline. Fix: Regularly update golang.org/x/sys to the latest version. Implement automated dependency scanning with tools like Dependabot (already in use) and establish a policy for patching critical system packages within 48 hours.
• High · Sensitive Data Handling in Memory — browser/chromium/decrypt.go, browser/chromium/extract_password.go, browser/chromium/extract_creditcard.go. The tool extracts and processes sensitive browser data including passwords, credit cards, cookies, and encryption keys. The codebase lacks visible evidence of secure memory handling practices (memory wiping after use, preventing sensitive data dumps in logs, etc.). Sensitive credentials could remain in memory longer than necessary or be dumped in crash reports. Fix: Implement secure memory handling: 1) Zero memory containing sensitive data after use, 2) Avoid logging passwords/keys, 3) Use secure enclaves where available, 4) Implement panic recovery that securely wipes memory, 5) Add memory scrubbing utilities using unsafe.Pointer for critical sections.
• High · Keyring/Credential Access Without Validation — browser/chromium/decrypt.go, go.mod (keychainbreaker dependency). Dependencies like github.com/moond4rk/keychainbreaker (v0.2.5) and github.com/ppacher/go-dbus-keyring (v1.0.1) access system keyrings and credential stores. Without proper validation and error handling, these could be exploited to extract credentials even when user consent is absent or when running with unexpected privileges. Fix: 1) Validate that keyring access requires proper authentication, 2) Implement explicit user consent mechanisms, 3) Log all keyring access attempts with timestamps, 4) Verify the tool only extracts from the current user's keyrings, 5) Add checks to prevent privilege escalation attempts.
• Medium · Third-party Library Risk: moond4rk/keychainbreaker — go.mod - github.com/moond4rk/keychainbreaker v0.2.5. The keychainbreaker library (v0.2.5) is a custom package from the same author. While this reduces supply chain risk, it's a specialized cryptographic library for keychain access. Any vulnerability in this library directly compromises the security of the entire credential extraction process. Fix: 1) Conduct regular security audits of keychainbreaker, 2) Monitor its repository for security issues, 3) Implement version pinning with regular update reviews, 4) Consider adding SBOM (Software Bill of Materials) to track this dependency, 5) Document the rationale for using a custom keychain library.
• Medium · Unvalidated Decryption Operations — browser/chromium/decrypt.go. Multiple decrypt functions exist (decrypt.go, decrypt_test.go, decrypt_mixed_test.go, decrypt_v20_test.go, decrypt_windows_test.go) handling various encryption schemes. Insufficient validation of decryption results could lead to processing corrupted/malicious data or exposing decryption keys through side-channel attacks. Fix: 1) Implement strict validation of decryption outputs, 2) Add integrity checks (HMAC/signatures) before processing decrypted data, 3) Implement constant-time comparisons for sensitive operations to prevent timing attacks, 4) Add error handling that doesn't leak key material in error messages.
• Medium · Temporary File Handling Risk — go.mod - github.com/otiai10/copy v1.14.1, modernc.org/sqlite v1.31.1. The file structure shows copy operations (otiai10/copy v1.14.1) and temporary database access (modernc.org/sqlite v1.31.1) for browser data extraction. Temporary files containing sensitive data may not be securely deleted and could be recovered. Fix: 1) Use secure temporary file creation that overwrites data before deletion, 2) Implement secure temp directory handling specific to the OS,

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.