网络安全应用安全密码学CLI【免费下载链接】HackBrowserDataExtract and decrypt browser data, supporting multiple data types, runnable on various operating systems (macOS, Windows, Linux).项目地址https://gitcode.com/gh_mirrors/ha/HackBrowserData点击查看免费下载本指南以 rfcs/006-key-retrieval-mechanisms.mdRFC-006为骨架结合 HackBrowserData 仓库中masterkey、browser、crypto等包的源码实现系统讲解 Chromium 系浏览器主密钥Master Key在 macOS、Windows、Linux 三个平台上的存储方式与检索策略。读完本文你将掌握Retriever接口与ChainRetriever链式语义、按密文版本前缀分层的MasterKeysV10/V11/V20机制、macOS 的三种取钥手段含 CVE-2025-24204 内存转储、Windows 的 DPAPI 与 App-Bound EncryptionABE双轨方案以及 Linux 上peanuts硬编码密钥与 D-Bus Secret Service 的搭配并理解 Safari 为何独立于这套体系。1. 概述Chromium 主密钥的三种平台存储形态Chromium 系浏览器Chrome、Edge、Brave、Opera、Vivaldi 等并不会直接用明文保存密码、Cookie、信用卡等敏感数据而是先派生出一个主密钥master key再用它加密落盘。主密钥本身按平台存放在不同的保险柜中RFC-006 给出了权威对照表平台存储位置密钥类型macOSmacOS Keychain钥匙串密码字符串 → PBKDF2 → AES-128WindowsLocal StateJSONDPAPI 加密原始 AES-256 密钥LinuxGNOME Keyring / KDE Wallet经 D-Bus密码字符串 → PBKDF2 → AES-128要点是每个平台可能存在多种取钥途径例如 macOS 既能靠 root 权限的内存转储拿密码也能用登录密码直接解锁钥匙串还能退化为调用security命令。HackBrowserData 用Retriever接口与ChainRetriever链式模式把这些策略抽象成按优先级逐个尝试、先成功者胜出的管线。关于 Chromium 密文本身的加密细节AES-CBC/GCM、密文版本前缀等属于 RFC-003 的范畴Firefox 通过key4.db自管密钥见 RFC-005。2. Retriever 抽象Hints、接口与链式取钥2.1 Hints显式传参而非位置参数接口的入参是一个Hints结构体目的是让调用方的意图显式化而不是靠一堆位置参数拼凑。源码定义见 masterkey/retriever.gotype Hints struct { KeychainLabel string // macOS Keychain account / Linux D-Bus Secret Service item label (e.g. Chrome, Chrome Safe Storage) WindowsABEKey string // Windows ABE browser key used by ABERetriever to locate the elevation-service COM interface (e.g. chrome, edge). → ABE not applicable; ABERetriever returns (nil, nil) silently. LocalStatePath string // path to Local State JSON. Only used on Windows (DPAPI ABE both read it). }每个 retriever 只读取与自己平台相关的字段其余字段一律忽略。调用方从BrowserConfig填充HintsKeychainLabel直接拷贝配置值WindowsABEKey则在cfg.WindowsABE为 true 时置为cfg.Key。这一组装逻辑实现在 browser/chromium/chromium.go 的buildHints中V10 的 DPAPI 与 V20 的 ABE 都依赖它。2.2 Retriever 接口与返回值语义// Retriever obtains a Chromium master key from one platform source (DPAPI, Keychain, D-Bus, …). type Retriever interface { RetrieveKey(hints Hints) ([]byte, error) }返回值就是拿来即用的解密密钥Windows 上是 32 字节原始 AES-256 密钥macOS/Linux 上则是经 PBKDF2 派生后的 16 字节 AES-128 密钥。也就是说取钥这一层已经把 PBKDF2 派生完成了下游拿到[]byte即可直接喂给解密器。2.3 ChainRetriever先成功者胜出type ChainRetriever struct { retrievers []Retriever } func (c *ChainRetriever) RetrieveKey(hints Hints) ([]byte, error) { var errs []error for _, r : range c.retrievers { key, err : r.RetrieveKey(hints) if err nil len(key) 0 { return key, nil } if err ! nil { log.Debugf(retriever %T failed: %v, r, err) errs append(errs, fmt.Errorf(%T: %w, r, err)) } } return nil, fmt.Errorf(all retrievers failed: %w, errors.Join(errs...)) }语义有三个关键点对应 masterkey/retriever.go先成功者胜出只要某个 retriever 返回err nil且密钥非空立即返回后续 retriever 不再执行静默降级单个 retriever 失败只打Debugf日志不中断链路全失败合并错误所有 retriever 都失败时用errors.Join把每个 retriever 的错误合并成一个整体错误返回方便诊断是哪个环节出了问题。2.4 MasterKeys / Retrievers按密文版本分层而不是单链RFC-006 的关键设计是不能只有一个获胜密钥因为一个 profile 里可能混有多种密文版本Windows 的 v10v20、Linux 的 v10v11。因此masterkey包提供了按密文版本前缀分层的容器见 masterkey/masterkeys.go// MasterKeys holds one key per cipher tier; a profile can mix tiers (Win v10v20, Linux v10v11), // so each is populated independently. A nil tier that cipher version cant be decrypted. type MasterKeys struct { V10 []byte json:v10,omitempty V11 []byte json:v11,omitempty V20 []byte json:v20,omitempty } // Retrievers is the per-tier retriever configuration; unused slots are nil. type Retrievers struct { V10 Retriever V11 Retriever V20 Retriever } // NewMasterKeys fetches each non-nil tier and joins per-tier errors. func NewMasterKeys(r Retrievers, hints Hints) (MasterKeys, error) { // ...对每个非 nil 的 tier 独立调用 RetrieveKey错误用 errors.Join 合并 }NewMasterKeys会独立评估每一个非 nil 的 tier某个 tier 失败不影响其他 tier 成功返回的错误是各 tier 错误的errors.Join。日志级别由调用方决定——browser/chromium.(Browser).masterKeys()browser/chromium/chromium.go目前把各 tier 的错误统一以Warnf输出理由是对于一个短生命周期 CLI默认输出即可见所有 warn 行而言部分失败与全部失败的区分价值不高。2.5 缓存与注入每个进程只建一次检索链检索链在整个进程内只创建一次browser包按平台分别实现的newCredentialInjector见 browser/browser_darwin.go、browser/browser_linux.go、browser/browser_windows.go负责把masterkey.DefaultRetrievers()的产物注入到每一个 Chromium 浏览器、每一个 profile 上并通过能力接口分派详见第 8 节。macOS 的 retriever 内部还用了sync.Once源码见 masterkey/retriever_darwin.go 的GcoredumpRetriever与KeychainPasswordRetriever因此多 profile 的浏览器只会触发一次钥匙串弹窗或内存转储。3. macOS 密钥获取三种策略与一条链Chromium 在 macOS 上把加密密码存放在用户登录钥匙串login keychain中账号名与浏览器相关如Chrome、Brave、Microsoft Edge。3.1 三种检索策略① GcoredumpRetriever —— 利用 CVE-2025-24204 漏洞需 root原理利用gcore二进制持有的com.apple.system-task-ports.read权限绕过 TCC 保护直接读取securityd系统安全守护进程的内存从中提取钥匙串密钥。整体流程实现见 masterkey/gcoredump_darwin.go构建标签为darwin keychain_gcore通过sysctlkern.proc.all定位securityd的 PID用gcore转储该进程内存用vmmap解析堆区域在MALLOC_SMALL区域中扫描 24 字节的密钥模式拿每个候选密钥尝试解锁login.keychain-db。该策略的显著特征是失败时返回(nil, nil)静默放行——因为需要 root是常态而非异常不值得报警告淹没真正的错误与 ABERetriever 的设计哲学一致。② KeychainPasswordRetriever —— 直接解锁钥匙串无需 root、非交互使用用户的 macOS 登录密码来自--keychain-pw参数直接解锁login.keychain-db。底层依赖项目作者自研的keychainbreaker库——一个纯 Go 实现的 macOS Keychain 文件解析与解密器。实现见 masterkey/retriever_darwin.go 的loadKeychainRecordskeychainbreaker.Open()打开钥匙串文件Unlock(keychainbreaker.WithPassword(password))解锁再枚举GenericPasswords()记录。③ SecurityCmdRetriever —— 调用security命令最后手段执行security find-generic-password -wa label获取密码。这会触发 macOS 密码对话框属于交互式操作所以被放在链路最后。实现上有三个工程细节masterkey/retriever_darwin.go使用exec.CommandContext包裹设置30 秒超时securityCmdTimeout防止用户挂起对话框导致进程卡死按存储名label做结果缓存sync.Mutexmap[string]securityResult每个浏览器的密钥只弹一次框对用户拒绝授权或输错密码的模糊错误security以非零退出但 stderr 为空做了可读化处理而不是抛出晦涩的exit status 128 ()。3.2 链式顺序macOS 只有 V10 这一层由DefaultRetrievers(keychainPassword)组装masterkey/retriever_darwin.go链的首元素永远是GcoredumpRetriever仅当密码非空时才插入KeychainPasswordRetriever最后固定追加SecurityCmdRetriever。顺序如下优先级策略前置条件是否交互1GcoredumpCVE-2025-24204Root否2钥匙串密码--keychain-pw参数否3security命令行无是弹窗3.3 PBKDF2 派生参数无论走哪条路最终得到的都是原始密码字符串必须经 PBKDF2 派生为 AES-128 密钥。参数在 masterkey/retriever_darwin.go 的darwinParams中硬编码与 Chromium 上游os_crypt_mac.mm一致参数值说明盐值SaltsaltysaltChromium 上游 os_crypt_mac.mm 中定义的固定盐迭代次数1003刻意压低保证解密性能密钥长度16 字节AES-128哈希算法HMAC-SHA1派生由 masterkey/params.go 的pbkdf2Params.deriveKey统一封装底层调crypto.PBKDF2Key。3.4 Keychain 标签映射每个浏览器在钥匙串里用一段短账号字符串标识自己的条目通常是浏览器基础名Chrome、Brave、ArcEdge 是Microsoft Edge。变体浏览器共享标签而非各自定义Chrome Beta 别名到ChromeOpera GX 别名到Opera。权威映射表位于platformBrowsers()各条目的KeychainLabel字段见 browser/browser_darwin.go例如 Chrome 的KeychainLabel: Chrome、Edge 的KeychainLabel: Microsoft Edge。4. Windows 密钥获取DPAPI 与 App-Bound 双轨4.1 先决认知Windows 上有两把主密钥Chromium 在 Windows 的Local StateJSON 里可能存两把主密钥v10 旧版密钥os_crypt.encrypted_keyDPAPI 包裹v20 App-Bound Encryption 密钥os_crypt.app_bound_encrypted_keyIElevator 包裹Chrome 127 引入。两者可以在同一个 profile 中共存Chrome 127 对新 Cookie用 v20 加密但升级前已有的密码和旧 Cookie 仍留在 v10 上。因此取钥层必须独立获取两把密钥而不是用 ChainRetriever 串起来详见 4.4 与 issue #578。4.2 DPAPI 背景Windows Data Protection APIDPAPI是Crypt32.dll提供的内置对称加密服务以当前登录用户的 Windows 凭据由其登录密码派生作为根密钥材料。应用只需调用CryptProtectData加密、CryptUnprotectData解密无需自行管理密钥。三个关键特性用户作用域一个 Windows 用户加密的数据另一个用户即使在同一台机器上也解不开机器绑定加密的 blob 无法在其他机器上解密除非使用漫游凭据无密码提示只要调用进程运行在正确的用户会话下解密对进程是透明的。4.3 检索流程Local State → os_crypt.encrypted_key (base64 字符串) | DPAPI 前缀 | DPAPI 加密的 AES 密钥 | |--------------|-----------------------| | 5B (ASCII) | 剩余字节 | → 去掉前缀 → CryptUnprotectData (Crypt32.dll) → 32 字节 AES-256 主密钥实现层面DPAPIRetrievermasterkey/retriever_windows.go的步骤是读取Local State→ 用gjson取os_crypt.encrypted_key→ base64 解码 →校验DPAPI前缀前缀不符或长度过短都会报错防止拿到损坏数据→ 调用crypto.DecryptDPAPI解开剩余字节。运行时通过syscall.NewLazyDLL加载Crypt32.dll以DATA_BLOB结构传入密文Windows 内部用用户凭据派生解密密钥并返回明文主密钥。4.4 无需 PBKDF2与 macOS/Linux 不同DPAPI直接给出最终的 AES-256 密钥没有中间密码、没有派生步骤。该密钥原样用于 AES-256-GCM 解密算法细节见 RFC-003。4.5 双 Tier 检索器V10 V20Windows 的masterkey.Retrievers结构体填两个槽二者独立运行、互不干扰而不是先成功者胜出的链槽位检索器数据来源字段机制V10DPAPIRetrieveros_crypt.encrypted_keyCryptUnprotectDataCrypt32.dllV20ABERetrieveros_crypt.app_bound_encrypted_keyIElevator 反射注入见 RFC-010V11 在 Windows 上保持 nilChromium 在 Windows 不产生 v11 前缀。装配发生在browser/browser_windows.go的newCredentialInjector中masterkey.DefaultRetrievers()返回Retrievers{V10: DPAPIRetriever{}, V20: ABERetriever{}}再通过Browser.SetRetrievers(r)注入。提取时masterkey.NewMasterKeys独立跑每个槽——一个 tier 失败不影响另一个 tier 成功因为从 pre-127 升级而来的混合 tier profile 需要部分成功才有价值。为什么不用 ChainRetrieverChainRetriever是先成功者胜出语义一旦 ABE 返回密钥DPAPI 就永远不被调用。这对正交的两个 tier是错误的语义——这正是 issue #578 的根因升级后的 profile 其 v10 加密密码因只取到 v20 密钥而静默解密失败。NewMasterKeys独立评估各 tier 并返回errors.Join合并的逐 tier 错误。非 ABE 的 Chromium 分支Opera、Vivaldi、Yandex、360、QQ、Sogou在platformBrowsers()中不设WindowsABE默认 false。调用方因此把Hints.WindowsABEKey留空ABERetriever对空值直接返回(nil, nil)masterkey/abe_windows.go 第 31-34 行NewMasterKeys将其视为不适用——对这些分支尝试 ABE 是无操作no-op而非失败它们的 V10 DPAPI 密钥照常工作。5. Linux 密钥获取peanuts 与 D-Bus 双槽5.1 双 Tier 检索器V10 V11Linux 的Retrievers结构体填两个槽一一对应 Chromium 在本平台可能产生的两个密文前缀槽位前缀检索器机制Chromium 对应物V10v10PosixRetrieverPBKDF2(peanuts)kV10Key对应上游PosixKeyProviderV11v11DBusRetrieverPBKDF2(D-Bus Secret Service 密码)kV11Key对应上游FreedesktopSecretKeyProviderV20 在 Linux 上保持 nilApp-Bound Encryption 仅限 Windows。v12Chromium 的SecretPortalKeyProviderFlatpak / xdg-desktop-portal 方案是独立的一层尚未实现——decryptValue的CipherV12分支会抛出可操作的已知缺口错误见 browser/chromium/decrypt.go 与 crypto/version.go。DBusRetrievermasterkey/retriever_linux.go查询 D-Bus Secret Service API由gnome-keyring-daemon或kwalletd提供连接dbus.SessionBus()→keyring.GetSecretService→OpenSession→ 遍历所有 collections 与 items查找标签与浏览器存储名匹配的条目 → 取回密钥并派生。它填 V11 槽因为Chromium 只有在钥匙串访问成功时才会发出 v11 前缀。PosixRetriever使用硬编码密码peanuts派生出的固定 16 字节 AES-128 密钥即 kV10Key。它填 V10 槽因为 Chromium 对用此密钥加密的数据发出 v10 前缀。该检索器永远确定性成功——即使没有任何钥匙串守护进程。5.2 为什么是两个槽而不是一条链一个 profile 完全可以同时携带 v10 与 v11 密文——只要主机在有钥匙串的桌面会话与无钥匙串的 headless 会话之间切换过例如一台先跑 headless shell、后进完整桌面的笔记本。旧实现ChainRetriever{DBus, Fallback}是先成功者胜出只要 D-Bus 成功peanuts 就永远不被调用导致 v10 密文无法解密。现在的拆分正是对 Windows V10/V20 修复4.5 节与 issue #578 根因逻辑的镜像不同密文前缀对应不同密钥来源取钥层必须独立产出两把密钥而不是挑一个获胜密钥。5.3 PBKDF2 派生参数远弱于 macOS两种策略产出的都是密码字符串经 PBKDF2 派生。参数在 masterkey/retriever_linux.go 的linuxParams中定义与 Chromium 上游os_crypt_linux.cc一致参数值说明盐值Saltsaltysalt与 macOS 相同的固定盐迭代次数1与 macOS 的 1003 形成鲜明对比密钥长度16 字节AES-128哈希算法HMAC-SHA1迭代次数为 1意味着 PBKDF2 退化成带密钥的 HMAC完全没有密钥拉伸key-stretching效果。再叠加广为人知的回退密码peanutsLinux 上不依赖钥匙串的 Chromium 加密几乎可以被任意破解——这是 RFC-006 明确指出的安全事实也是取证工具能够工作的基础。5.4 Keychain 标签映射Linux 的 D-Bus 标签遵循name Safe Storage惯例但多数浏览器别名到一个小集合上真正的独立标签只有三个Chrome Safe Storage、Chromium Safe Storage、Brave Safe Storage其余浏览器全部映射到三者之一。权威映射在 browser/browser_linux.go 的platformBrowsers()中例如Chrome / Chrome Beta / Vivaldi →Chrome Safe StorageChromium / Edge / Opera →Chromium Safe StorageBrave →Brave Safe Storage。6. 平台汇总平台检索器填充的槽位PBKDF2密钥尺寸macOSV10 链(Gcoredump → KeychainPassword* → SecurityCmd)1003 次迭代AES-128WindowsV10 DPAPIRetrieverV20 ABERetrieverChrome 127无AES-256LinuxV10 PosixRetrieverpeanuts kV10KeyV11 DBusRetriever钥匙串 kV11Key1 次迭代AES-128* 仅当解析出非空密码时包含——要么来自--keychain-pw参数要么来自交互式 TTY 提示。7. Safari 凭据提取刻意独立于 Retriever 体系Safari不是Retriever接口的使用者。它有自己的凭据提取路径browser/safari/extract_password.go直接使用 keychainbreaker 库列出login.keychain-db中的InternetPassword记录browser/safari/extract_password.go 的getInternetPasswordskeychainbreaker.Open()→ 若有密码则TryUnlock→ 枚举 InternetPassword 记录。这是刻意的架构选择而非疏漏。7.1 为什么 Safari 不共享 Chromium 链维度Chromium 链Safari 直接访问输出16 字节 AES-128 密钥InternetPassword记录列表用途解密 Login Data 数据库记录本身就是凭据消费者数量10 个 Chromium 变体1仅 Safari失败模式硬失败无密钥 → 无法解密软失败降级为仅元数据缓存收益高多 profile、多浏览器无单浏览器、单次调用把 Safari 硬塞进Retriever接口需要返回与[]byte不同的类型与接口主密钥抽象的既定用途矛盾为单一消费者再造一条平行的 InternetPassword 链 则属于过度设计——它没有任何值得链式串联的回退策略。注意失败模式一行Chromium必须拿到主密钥否则提取整体失败所以需要不断升级的策略链Safari 可以优雅降级——即使钥匙串无法解锁仅导出元数据URL 和用户名无明文密码仍有价值所以试一次 keychainbreaker失败就告警足够。7.2 通用规则每个浏览器包拥有自己的凭据获取策略。masterkey存在的意义仅限于在 Chromium 变体家族间共享检索逻辑。新增浏览器实现应效仿 Safari 与 Firefox——自己掌控凭据代码。该规则在仓库中已经生效的证据Firefoxbrowser/firefox/firefox.go不 importmasterkey或keychainbreaker从key4.db经内部 NSS PBE 派生密钥见 RFC-005Safari直接用 keychainbreaker 取InternetPassword记录Chromium 变体全部走masterkey因为它们共享同一条链并受益于共享的sync.Once缓存。未来贡献者若要新增一个从 Keychain 读凭据的 macOS 浏览器应把访问逻辑写进该浏览器的包而不是扩展masterkey只有新浏览器是契合现有主密钥链的 Chromium 变体时才值得扩展masterkey。7.3--keychain-pw密码的去向两个刻意不统一的能力接口macOS 登录密码在启动时由 browser/browser_darwin.go 的resolveKeychainPassword解析一次然后通过按平台实现的闭包newCredentialInjector分发给两个消费者。该闭包捕获检索链和原始密码按每个 Browser 恰好满足的能力接口分发消费者能力接口定义位置载荷Chromium 浏览器KeyManagerbrowser/browser.gomasterkey.Retrievers结构体V10/V11/V20 槽未用 tier 为 nilSafariKeychainPasswordReceiverbrowser/browser.go原始string两个接口刻意不统一它们承载的抽象不同——一个交给浏览器预先组装好的检索链另一个交给浏览器一个凭据令牌去解锁自己的访问路径。强行统一会造出一个泄漏抽象的、无真实共享语义的多态接口。工程细节resolveKeychainPassword在构建检索链之前还会先用 keychainbreaker 做一次提前TryUnlock校验于是错误的密码会在启动时就以告警形式暴露而不是拖到提取中途才失败。为此付出的打开钥匙串两次一次校验、一次在KeychainPasswordRetriever内的小成本换来了明显更好的用户体验。此外该函数遵循严格的降级逻辑无--keychain-pw且 stdin 非 TTY 时直接返回空字符串受钥匙串保护的数据将以元数据形式导出。8. 从密钥到明文解密链路的版本分派拿到MasterKeys之后解密由 browser/chromium/decrypt.go 的decryptValue完成它按密文版本前缀分派到对应 tier版本识别见 crypto/version.go 的DetectVersionv10→masterKeys.V10。这里有一个跨平台精巧设计v10 密文的算法由密钥长度决定——32 字节密钥走 AES-GCMWindows16 字节密钥走 AES-CBCmacOS/Linux。按密钥长度分派让跨主机解密例如在 macOS 上解密 Windows 导出的密钥与操作系统无关v11→masterKeys.V11Linux 专用 AES-CBC算法与 Linux v10 相同但密钥来自钥匙串kV11Key而非 peanutskV10Key因此两个 tier 需要不同密钥v20→masterKeys.V20跨平台 AES-GCMChrome 127 ABE线格式与 Windows v10 相同v12→ 明确报未实现错误Chromium SecretPortal / Flatpak 的已知缺口而不是模糊的不支持缺失 tier 密钥会以密文级解密错误呈现提取层将其当作空明文处理而非致命错误browser/chromium/decrypt.go 注释明确说明。从取钥到解密的完整调用链是DiscoverBrowsersWithKeys→newCredentialInjector注入Retrievers→Browser.Extract→b.masterKeys()sync.Once缓存内部走ExportKeys→masterkey.NewMasterKeys→decryptValue。buildHints还会把Local State拷贝进临时目录Windows DPAPI/ABE 从一个进程拥有的路径读取见 browser/chromium/chromium.go。9. 实战主密钥的跨主机导出与离线解密主密钥检索能力不止服务于本机提取还能支撑跨主机解密在来源主机上导出主密钥dumpkeys在分析主机上离线解密拷贝过来的数据甚至可解出分析主机无法安装引擎的浏览器如在 macOS 上解密 Sogou/QQ 浏览器数据。这得益于MasterKeys的 JSON 可序列化结构masterkey/dump.go 中Dump/Vault类型每个Vault携带Keys MasterKeys。标准工作流详见 README.md 的 Cross-host decryption 一节# 来源主机导出主密钥 打包解密所需的文件 hack-browser-data dumpkeys -o keys.json hack-browser-data archive -o browser-data.zip # 拷贝到分析主机后离线解密 hack-browser-data restore --keys keys.json --data-zip browser-data.zipkeys.json包含明文主密钥须按秘密对待dumpkeys -o以0600权限落盘。macOS 场景下dumpkeys同样接受--keychain-pw参数来免交互解锁钥匙串标志简写默认说明--browser-ball目标浏览器all|chrome|edge|...--output-ostdout输出文件0600权限省略则输出到 stdout 便于 SSH 管道--keychain-pwmacOS 钥匙串密码restore不依赖分析主机的本地浏览器表可恢复的浏览器恰好是keys.json中的 vaults数据可经--data-ziparchive产物或--data-dir手工拷贝的 User Data 目录提供。这是第 2.4 节按 tier 独立取钥设计在跨主机场景下的直接红利——一个 profile 若同时含 v10 与 v20 密文两把密钥都会被完整导出并逐层解密。10. 小结与延伸阅读RFC-006 描绘的取钥架构可以概括为三句话按平台找对保险柜Keychain / DPAPI / D-Bus按密文版本分对槽V10/V11/V20按失败成本排好队链式 vs 独立分层。ChainRetriever只用于 macOS 上同层不同手段的递进Windows 与 Linux 的不同层不同来源则用MasterKeys的多槽结构独立求值——这个区分是 issue #578 用教训换来的正确语义。Safari 与 Firefox 则证明当消费者形态与 Chromium 差异过大时自管凭据代码反而是更清晰的选择。关键实现与文档索引检索抽象与链式实现masterkey/retriever.go、分层容器 masterkey/masterkeys.gomacOS 检索器与 PBKDF2 参数masterkey/retriever_darwin.go、CVE-2025-24204 转储 masterkey/gcoredump_darwin.goWindows DPAPI / ABE 检索器masterkey/retriever_windows.go、masterkey/abe_windows.goLinux D-Bus / peanuts 检索器与参数masterkey/retriever_linux.go注入与平台浏览器表browser/browser.go、browser/browser_darwin.go、browser/browser_linux.go、browser/browser_windows.go版本分派解密browser/chromium/decrypt.go、crypto/version.goSafari 独立路径browser/safari/extract_password.go跨主机导出格式masterkey/dump.goCLI 用法见 README.md外部参考资料RFC-006 原文标注此处仅作文字说明Chromium 上游os_crypt_mac.mm/os_crypt_win.cc/os_crypt_linux.cc中的盐值与密钥派生常量CVE-2025-24204 的公开 PoC 与 Apple 安全公告微软文档中CryptUnprotectData的 DPAPI 说明。相关 RFCRFC-003Chromium 加密机制、RFC-005Firefox NSS 加密与密钥派生、RFC-010Chrome ABE 集成。赞分享网络安全应用安全密码学CLI【免费下载链接】HackBrowserDataExtract and decrypt browser data, supporting multiple data types, runnable on various operating systems (macOS, Windows, Linux).项目地址https://gitcode.com/gh_mirrors/ha/HackBrowserData点击查看免费下载相关推荐HackBrowserData 深度解析RFC-012 与 Yandex 浏览器两级密钥解密方案HackBrowserData 深度解析RFC 012 与 Yandex 浏览器两级密钥解密方案 本篇技术指南以仓库内 RFC 012: Yandex Bro网络安全应用安全密码学CLIHackBrowserData 源码级解析Chromium 多平台加密体系RFC-003与 v10/v11/v20 密文解密实战HackBrowserData 源码级解析Chromium 多平台加密体系RFC 003与 v10/v11/v20 密文解密实战 HackBrowserD网络安全应用安全密码学CLIWuWa-Mod AES密钥获取加密解密技术的深度解析WuWa Mod AES密钥获取加密解密技术的深度解析 欢迎来到WuWa Mod AES密钥获取的终极指南作为一款专门为《鸣潮》 Wuthering Wav游戏开发创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考