RFC-001: Project Architecture & Data Model

Author: moonD4rk Status: Living Document Created: 2026-04-05

1. Project Positioning

HackBrowserData is a CLI security research tool that extracts and decrypts browser data from Chromium-based browsers and Firefox across Windows, macOS, and Linux.

Key constraints:

• Go 1.20 — the module must build with Go 1.20 to maintain Windows 7 support. Features from Go 1.21+ (log/slog, slices, maps, cmp) must not be used.
• Supported engines: Chromium (including Yandex and Opera variants), Firefox, and Safari.
• Supported platforms: Windows (DPAPI), macOS (Keychain), Linux (D-Bus Secret Service).
• No root-level library API — the CLI calls browser.DiscoverBrowsersWithKeys() directly; there is no importable pkg/ surface.

2. Directory Structure

HackBrowserData/
├── cmd/hack-browser-data/    # CLI entrypoint: cobra root, dump, dumpkeys, archive, restore, list, version
├── browser/                  # Browser interface, DiscoverBrowsersWithKeys(), platform browser lists
│   ├── chromium/             # Chromium engine: extraction, decryption, profile discovery
│   ├── firefox/              # Firefox engine: extraction, NSS key derivation
│   └── safari/               # Safari engine: Keychain, Bookmark, History, Downloads (macOS only)
├── types/                    # Data model: Category enum, Entry structs, BrowserData
├── crypto/                   # Encryption primitives, cipher version detection
├── masterkey/                # Platform-specific master key retrieval (Keychain/DPAPI/D-Bus)
├── filemanager/              # Temp file session, locked file handling (Windows)
├── output/                   # Output Writer: CSV, JSON, CookieEditor formatters
├── log/                      # Logging with level filtering
└── utils/                    # SQLite query helpers, file utilities

3. Core Data Model

3.1 Category

Category is an int enum representing 9 browser-agnostic data kinds: Password, Cookie, Bookmark, History, Download, CreditCard, Extension, LocalStorage, SessionStorage.

Three categories are classified as sensitive (Password, Cookie, CreditCard) via IsSensitive(), enabling safe-by-default export scenarios.

3.2 Entry Types

Each category has a corresponding Entry struct with json and csv struct tags. All structs are flat (no nesting) and use time.Time for timestamps.

StorageEntry is shared by both LocalStorage and SessionStorage.

3.3 BrowserData Container

BrowserData is the per-profile data container holding typed slices — one per category, populated field-by-field during extraction. Extract() returns []ExtractResult, where each element pairs a Profile identity with a *BrowserData. The output layer uses makeExtractor[T]() generics to pull the correct slice for serialization.

4. Browser Interface & Registration

4.1 BrowserKind

Each config declares an engine kind that determines source paths and extraction logic. Kinds fall into three engine families:

• Chromium (Chromium, ChromiumYandex, ChromiumOpera) — the standard Chromium layout plus two variants that override file names or storage paths for Yandex and Opera forks. See RFC-003.
• Firefox — NSS-based key derivation from key4.db, SQLite + JSON source files. See RFC-005.
• Safari — macOS only, with direct Keychain-based credential extraction. See RFC-006 §7.

See types/category.go for the authoritative enum definition.

4.2 BrowserConfig

BrowserConfig is the declarative, platform-specific browser definition containing: Key (CLI matching; also the Windows ABE / winutil.Table identifier when WindowsABE is true), Name (display), Kind (engine), KeychainLabel (macOS Keychain / Linux D-Bus Secret Service label), WindowsABE (bool — enable Windows App-Bound Encryption v20 path), UserDataDir (data path).

4.3 Browser Selection Flow

There are two entry points, one for extraction and one for discovery:

DiscoverBrowsersWithKeys(opts)                    // used by `dump` — ready to Extract
  → discoverFromConfigs(configs, opts)     // shared discovery core
      → platformBrowsers()             // build-tagged list for this OS
      → filter by name / profile path
      → newBrowser(cfg)                // dispatch to chromium/firefox/safari.NewBrowser
          → discoverProfiles()          // scan profile subdirectories
          → resolveSourcePaths()        // stat candidates, first match wins
  → newCredentialInjector(opts)          // build-tagged: returns a browserInjector
      → for each browser:               // closure captures retriever + keychain pw lazily
          inject(b)                     // type-assert KeyManager / KeychainPasswordReceiver

DiscoverBrowsers(opts)                 // used by `list` / `list --detail`
  → discoverFromConfigs(configs, opts)     // same shared discovery core, NO injection

DiscoverBrowsersWithKeys does discovery + decryption setup in one call; the returned browsers are ready for b.Extract. DiscoverBrowsers skips injection entirely, so list-style commands never trigger the macOS Keychain password prompt — they have no use for the credential. Both entry points share the same discoverFromConfigs core, so filtering/profile-path/glob semantics stay consistent.

Key design decisions:

• One Retriever chain per process — built lazily inside newCredentialInjector and reused across every Chromium browser and every profile to prevent repeated keychain prompts on macOS.
• Discovery is decoupled from injection — discoverFromConfigs is injection-free; DiscoverBrowsers stops after it, DiscoverBrowsersWithKeys continues into injection.
• Profile discovery differs by engine: Chromium looks for Preferences files in subdirectories; Firefox accepts any subdirectory containing known source files.
• Flat layout fallback — Opera-style browsers that store data directly in UserDataDir (no profile subdirectories) are handled by falling back to the base directory.

4.4 Platform Browser Lists

Browser configs are defined per-platform via build tags in platformBrowsers() (browser/browser_{darwin,linux,windows}.go). The supported set groups by engine family:

• Chromium-based — the largest family, covering mainstream browsers (Chrome, Edge, Brave, Vivaldi, Opera, Chromium) across all three platforms plus regional variants and forks. Windows carries the longest list because of China-region Chromium forks (360, QQ, Sogou, DC, …) and MSIX-packaged browsers with dynamic install paths (Arc, DuckDuckGo).
• Firefox — all three platforms, via internal NSS key derivation (RFC-005).
• Safari — macOS only, via direct Keychain InternetPassword extraction (RFC-006 §7).

Adding a new browser is a config-only change in platformBrowsers(); this section does not need updates for new variants within an existing family.

5. Extract() Orchestration

Both Chromium and Firefox engines follow the same per-profile extraction pattern (Firefox runs it inside each profile.extract() call; for Firefox the master key comes from key4.db rather than a platform API):

Extract(categories)   // per-profile: one invocation per profile
  1. NewSession()               → create isolated temp directory
  2. acquireFiles(session)      → copy source files to temp dir (with dedup and WAL/SHM)
  3. getMasterKey(session)       → platform-specific key retrieval (Firefox: key4.db)
  4. for each category:
       extractCategory(data, cat, masterKey, path)
  5. defer session.Cleanup()    → remove temp directory

For details on file acquisition, see RFC-008. For encryption details, see RFC-003 (Chromium) and RFC-005 (Firefox). For key retrieval, see RFC-006.

5.1 Collect-and-Continue Pattern

The extraction loop maximizes data recovery. Each category is extracted independently — a failure in one does not affect others. Errors are handled at three levels:

Master key failure is non-fatal. If the key cannot be retrieved, categories requiring decryption (passwords, cookies, credit cards) produce empty values, while non-encrypted categories (history, bookmarks, downloads) still succeed.

5.2 Custom Extractors

The categoryExtractor interface allows browser-specific extraction logic. Yandex uses custom extractors for passwords and credit cards; Opera uses a custom extractor for extensions. All other categories fall through to the default Chromium implementation.

6. Dependency Constraints

The module is pinned to go 1.20 in go.mod. This is enforced by a CI lint check that fails if the directive changes.

Related RFCs