本项目是 Chrome App-Bound Encryption (ABE) Cookie 解密工具的纯 Python 实现版本。
Chrome 127（2024年7月）引入了 App-Bound Encryption 机制：
- Cookie 的加密主密钥不再仅用 DPAPI 保护
- 密钥由运行在 SYSTEM 权限下的 IElevator2 COM 服务二次加密
- IElevator2 会验证调用者的进程身份（必须是真实的 chrome.exe）
本工具通过将 payload_dll.dll 注入到 Chrome Browser Process 内部，
让 Chrome 自身调用 IElevator2，从而合法地获取明文 AES-256 主密钥，
最终完成 Cookie 数据库的 AES-256-GCM 解密。
本工具仅供安全研究、渗透测试学习和授权环境下使用。
- 在未经授权的设备上运行属于违法行为
- 作者不对任何滥用行为承担责任
- 请遵守当地法律法规
| 要求 | 说明 |
|---|---|
| Python | 3.8 或以上（64位） |
| 操作系统 | Windows 10/11 x64 |
| 权限 | 管理员权限（High IL） |
| Chrome | 127+ 已运行 |
| 依赖 | pycryptodome >= 3.0.0 |
| 前提 | payload_dll.dll 已编译完成 |
pip install pycryptodomepython-abe-injector/
├── README.md
├── .gitignore
├── requirements.txt
├── separated/ # 分离版：职责清晰，便于维护
│ ├── injector.py # 注入器核心（Hell's Gate + DLL 注入）
│ ├── decrypt_cookies.py # Cookie 解密（AES-256-GCM）
│ └── run.py # 入口脚本
└── combined/ # 合并版：单文件，方便分发
└── all_in_one.py # 完整实现 + 详细注释
# 1. 修改 injector.py 中的 PAYLOAD_DLL 路径
# 2. 运行
# 使用默认参数（过滤 threatbook 域名）
python separated/run.py
# 过滤 google 域名的 Cookie
python separated/run.py --domain google
# 提取所有 Cookie
python separated/run.py --domain ""
# 指定输出路径
python separated/run.py --out C:\Temp\my_cookies.json# 1. 修改 all_in_one.py 顶部的路径常量
# 2. 运行
python combined/all_in_one.py如果已经有了主密钥文件，可以跳过注入步骤，直接解密：
python separated/decrypt_cookies.py key.bin Cookies.db google┌─────────────────────────────────────────────────────┐
│ Python进程(Admin) Chrome进程 │
│ │ │ │
│ ├─VirtualAllocEx──────────►│ 分配RW内存 │
│ ├─WriteProcessMemory──────►│ 写入DLL路径+参数 │
│ ├─VirtualAllocEx──────────►│ 分配RWX内存 │
│ ├─WriteProcessMemory──────►│ 写入shellcode │
│ ├─NtCreateThreadEx────────►│ 执行shellcode │
│ │ │ └─LoadLibraryW │
│ │ │ └─DLL加载完成 │
│ ├─ReadProcessMemory───────◄│ 读取hModule地址 │
│ ├─NtCreateThreadEx────────►│ 执行PayloadEntry │
│ │ │ └─CoCreateInstance
│ │ │ └─IElevator2 │
│ │ │ └─DecryptData │
│ │ │ └─句柄复制 │
│ │ │ └─读Cookies DB │
│ ◄─命名管道─────────────────│ 返回key+cookies │
│ └─AES-256-GCM解密 │ │
└─────────────────────────────────────────────────────┘
-
Hell's Gate 直接系统调用
- 从 ntdll 内存中动态提取
NtCreateThreadEx的 SSN（系统服务号） - 构建 trampoline 跳板，直接执行 syscall 指令
- 绕过 EDR 在 ntdll 用户态函数上的 JMP Hook
- 从 ntdll 内存中动态提取
-
Chrome 多进程架构识别
- 通过进程树分析识别 Browser Process（父进程不是 chrome.exe 的那个）
- 只有 Browser Process 才有 IElevator2 COM 服务的访问权限
-
NULL DACL 命名管道
- Python 进程（高完整性）创建管道
- Chrome 进程（中完整性）通过 NULL DACL 允许连接
-
64 位 HMODULE 回传
GetExitCodeThread只能返回 32 位值，无法获取完整地址- shellcode 直接将 64 位 hModule 写入共享内存槽
- 通过
ReadProcessMemory安全读回
-
v20 AES-256-GCM 解密
- 密文格式：
[v20(3)][IV(12)][ciphertext(N)][Tag(16)] - 使用 pycryptodome 的
AES.MODE_GCM解密并验证完整性
- 密文格式：
[HRESULT(4字节)] [keyLen(4字节)] [key(keyLen字节)] [cookiesLen(4字节)] [cookiesData(N字节)]
解密结果为标准 JSON 格式，兼容 Chrome DevTools / Netscape Cookie 导入工具：
[
{
"name": "SAPISID",
"value": "abc123def456...",
"domain": ".google.com",
"path": "/",
"expires": 1735689600,
"secure": true,
"httpOnly": false,
"sameSite": "None"
}
]Q: 运行时报错 "Could not resolve NtCreateThreadEx SSN"
A: ntdll 中的函数可能被 EDR 的 Hook 覆盖了 B8 特征字节。 尝试：
- 关闭杀毒软件后重试
- 使用 Halo's Gate 技术（从相邻函数推算 SSN）
Q: Chrome 未运行或 PID 找不到
A: 确保 Chrome 已经打开并完全加载（不只是启动中）。 Chrome 的主进程需要一点时间初始化各子进程。
Q: 管道连接超时（30秒无响应）
A: 检查 C:\payload_log.txt（DLL 写入的调试日志）。
常见原因：
- payload_dll.dll 版本与 Chrome 版本不匹配
- COM 服务注册问题（IElevator2 CLSID 变化）
- Chrome 更新导致 CLSID 变化
Q: GetExitCodeThread 返回 0 但 hModule 读到了 NULL
A: DLL 加载失败，可能原因：
- DLL 路径包含特殊字符
- DLL 依赖的 C++ 运行时未安装
- 目标 Chrome 进程是 32 位（不支持）
Q: 解密成功但 Cookie 数量为 0
A: DOMAIN_FILTER 可能过于严格，尝试 --domain "" 提取全部 Cookie，
再用 jq 或 Python 过滤。
Q: 需要在没有网络的机器上运行
A: 提前在有网络的机器上：
pip download pycryptodome -d ./packages
# 然后传输 packages/ 目录到目标机器
pip install --no-index --find-links=./packages pycryptodome