Exynos 990 / Exynos9830 统一 BootROM 漏洞利用

针对 Exynos 990 Galaxy S20、S20 FE 和 Note20 系列的统一 CVE-2024-56426 工具。该漏洞利用接受全部十种型号名称，并将其映射到六个已验证的出厂引导加载程序系列。

[!CAUTION] 跟踪的密钥包和生成的镜像具备熔断（fusing）能力。熔断是不可逆的。熔断到某个密钥的手机只能启动与该密钥兼容的镜像。错误的型号、回滚版本、补丁集或密钥包可能导致设备陷入熔断启动循环。在迭代过程中请使用开发密钥和 UFS 载荷。除非明确打算进行自定义密钥熔断，否则请在每条准备/签名命令中添加 --no-fuse。

支持的型号

所选型号同时控制 BL1 型号 ID 和精确型号 LK 补丁 TSV。运行时工件 控制预检使用哪个出厂固件和加密拆分镜像。四个使用配对 5G 运行时工件的非 5G 标志也会修补 LK 的型号 ID 检查和型号 ID 编程路径。

型号标志	运行时工件	运行时固件	型号 ID	EVT	回滚	已测试
`G780F`	`G780F`	`G780FXXSOFYJ1`	`0x154`	`11`	`24`	❌
`G980F`	`G981B`	`G981BXXSNHYB1`	`0x143`	`11`	`23`	✅
`G981B`	`G981B`	`G981BXXSNHYB1`	`0x13D`	`11`	`23`	❌
`G985F`	`G986B`	`G986BXXSNHYB1`	`0x142`	`11`	`23`	✅
`G986B`	`G986B`	`G986BXXSNHYB1`	`0x13C`	`11`	`23`	✅
`G988B`	`G988B`	`G988BXXSNHYB1`	`0x13E`	`11`	`23`	❌
`N980F`	`N981B`	`N981BXXSIHYH3`	`0x153`	`11`

Exynos 990 KVM 和 EL2 模式

全部十种受支持的 Galaxy S20、S20 FE 和 Note20 型号标志都具有可选的仅限 CLI 的 KVM 启动配置文件。构建一个 Exynos 990 内核的分支，其名称包含 kvm，并在精确型号命令中添加 --kvm，例如：```bash python3 exploit/exploit.py --build-sboot --model G985F --no-fuse --kvm

此配置文件移除 LK H-Arx/UH 路径，要求 EL3 在 EL2 进入内核，并应用匹配的
解密/重新加密 EL3 监视器补丁表。它仍不适用于原厂/篡改引导加载程序刷写模式。
Web 控制中心有意不提供 KVM 控制。配合匹配的内核
和 [WindowsInQemu](https://github.com/Creeeeger/WindowsInQemu)，Windows 可在手机上的 QEMU 中通过 KVM 全速运行。

## 快速开始

不要将每种模式视为一个编号安装序列。请选择一个目标：

| 目标                              | 路径                                                                                                                     |
|-----------------------------------|--------------------------------------------------------------------------------------------------------------------------|
| 安装已签名的自定义 ROM            | 精确型号/设置 → EUB → 临时 `--signed --no-fuse` 链 → 刷写 ROM 的完整签名输出 → UFS 首次启动 |
| 测试漏洞利用                      | 可选 `--prepare --no-fuse` → EUB → `--signed --no-fuse` → 停止                                                       |
| 开发引导链（仅 CLI）              | 临时 no-fuse 测试 → 构建 → 刷写生成的 SBoot/TZSW/LDFW → UFS                                                   |
| 转储 / 恢复                       | 使用其独立工作流程及熔丝状态检查                                                                          |

`--prepare` 是推荐的试运行，并非必需的前置步骤：`--signed`
会重复预检。生成的三部分 Heimdall 命令是引导链开发工具；它不是自定义 ROM
刷写。

在接触设备前，请阅读 [USER_GUIDE.md](https://github.com/creeeeger/cve-2024-56426/blob/exynos990/USER_GUIDE.md) 并选择其匹配的工作流程。它包含
完整 ROM 交接以及未熔断、已熔断和不确定状态恢复规则。

## 可选本地 UI

浏览器 UI 仅使用 Python 标准库，并调用现有的
`exploit/exploit.py` CLI。引导链开发及其生成的三部分 Heimdall 命令仍为仅终端
工具。

从仓库根目录启动它：```bash
python3 exynos990_control_center.py

启动器绑定到 127.0.0.1，生成一个新的访问令牌，打印完整的本地 URL，并在默认浏览器中打开它。当不应自动打开浏览器时，请使用 --no-browser：```bash python3 exynos990_control_center.py --no-browser

界面提供：

- 红色/绿色依赖项与仓库资源检查；
- 一个全局目标型号选择，以及恰好两个熔断决策：保持未熔断或熔断；
- 一个工作流选择器，仅显示并编号所选工作流的步骤；
- 安装ROM、漏洞利用测试、BootROM转储和原厂恢复工作流；
- 一个精确型号的篡改加载器操作，用于验证UH并通过Heimdall将其刷写到BOOTLOADER分区以进入EUB；
- 一个永久熔断警告，以及已配置的密钥/eFuse SHA-256指纹；
- 一个仅限未熔断状态的原厂启动链恢复卡片，在选择熔断后不可用；
- 实时进程输出、取消操作，以及各阶段验证标记。

它还显示一条仅限CLI的Exynos 990 KVM通知，但刻意不暴露KVM选项，也不向任何Web操作转发`--kvm`。

USB访问遵循启动控制中心的进程权限。在启动前，请先配置随附的udev/驱动权限。界面不会请求、保留或转发特权凭据。请将打印出的令牌URL保密，并在使用后立即停止服务器。

终端用户可以忽略`exynos990_control_center.py`；下文记录的每条CLI命令均保持不变并完全受支持。

## 要求

需要Python 3.10或更高版本。

Windows 10/11（原生PowerShell）：```powershell
.\windows\setup.ps1
. .\windows\activate.ps1
python .\exploit\exploit.py --prepare --model G985F --no-fuse

安装过程会固定安装原生 AArch64 工具链、LZ4、Heimdall 以及仓库虚拟环境，然后构建所有载荷。BootROM WinUSB 驱动需要管理员显式选择安装，因为其上游自签名证书会更改计算机的信任存储。完整的安装、驱动安装、Download Mode 区分、验证及故障排查流程，请参阅 WINDOWS.md。

Windows 激活后，在其余跨平台示例中使用 python3 的地方，请改用 python。

Linux：```bash sudo apt-get update sudo apt-get install -y gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu lz4

macOS:```bash
brew tap messense/macos-cross-toolchains
brew install aarch64-unknown-linux-gnu lz4

仓库结构

预检

准备、签名和载荷模式均运行相同的型号感知预检：

将所选型号解析为其规范工件系列。
用未经改动的加密拆分镜像的干净副本替换 exploit/extra/images/<model>/。
应用匹配的 LK TSV，并进行严格的原厂字节检查。使用 --no-fuse 时，首先生成禁用五个熔断行的有效 TSV 副本。使用 --kvm 时，同时启用标记为 kvm 的 LK 行，解密并修补匹配的 EL3 监视器 TSV，并重新加密其受保护区域。
构建 mem.bin、loader.bin 和 Exynos990_boot_custom_key.bin。
确认 EPBL 和 EL3 监视器已加密，仅在必要时重新加密。
在签名前验证原厂 FWBL1 型号/EVT/回滚元数据及每个 Stage2 回滚尾部。
使用所选型号 ID 对 FWBL1 签名，并使用原厂回滚版本对所有 Stage2 组件签名。
在 USB 传输前验证每个生成的 Stage2 签名。

该过程在首次出现固件、补丁、元数据或签名不匹配时停止。它绝不会就地修补不可变的源目录。

漏洞利用模式

所有命令均需 --model。

--no-fuse 是修饰符，而非独立模式。它在重建工作 LK 时禁用五个已识别的自定义密钥 OTP 行。请将其用于每个准备、发送或构建未熔断开发链的命令。它不会撤销现有熔断。

CLI 接受该修饰符与 UFS 和转储模式一起使用，因为这些命令也会运行预检，但其 USB 操作不会传输重建的 LK。手机上已刷写的 LK 决定 UFS 熔断行为。因此，UI 有意不为 UFS 或 BootROM 转储模式提供无熔断控制。两种引导加载程序刷写模式均拒绝 --no-fuse，因为它们不执行任何 LK 修补或签名。

--kvm 也是修饰符。它可与每个运行预检的精确型号工作流一起使用。TSV 中的 KVM 行在未提供此标志时会被忽略，且浏览器 UI 从不提供该标志。

示例：```bash python3 exploit/exploit.py --signed --model N986B --no-fuse

生成对应的已签名引导加载程序，无需打开USB：```bash
python3 exploit/exploit.py --build-sboot --model N986B --no-fuse

该命令从干净的原始输入重建模型镜像目录，应用LK补丁，对每个组件进行签名和验证，合并sboot.bin，检查嵌入的组件和尾部，并打印其大小、SHA-256以及一条Heimdall命令，该命令发送sboot.bin、已签名的tzsw.img和已签名的ldfw.img。

仅当设备已知未熔断时，从所选型号的原始BL tar包中恢复精确的原始启动链：```bash python3 exploit/exploit.py --flash-stock --model N986B --wait

该命令仅提取 `sboot.bin.lz4`、`tzsw.img.lz4` 和 `ldfw.img.lz4`，在临时目录中解压它们，验证所有三个输出文件均存在且非空，然后执行一次 Heimdall 刷写操作。临时文件随后会被删除。同时支持 `--no-reboot` 和 `--verbose` 参数。手机必须已处于 Heimdall 兼容的下载模式，且所选型号必须与物理设备完全匹配。

此操作不会恢复 Android、AP、调制解调器、CSC、用户数据或完整的原厂 ROM。切勿在已熔断自定义密钥的设备上运行。此类手机需要使用与熔断密钥完全匹配的密钥重新签名的基于原厂的软件；自定义信任根将永久保留。如果熔断状态未知，请停止操作。

## FRP / 持久分区恢复说明

> [!CAUTION]
> 此过程仅适用于您个人拥有且有权维修的设备。在他人设备上使用此操作
> 严格禁止。错误的分区路径可能导致永久性数据丢失或使设备无法启动。
> 在写入任何内容之前，请备份目标分区并验证其解析后的块设备路径和大小。

本仓库不会自动移除出厂重置保护（FRP）。在使用 Android 的
`PersistentDataBlockService` 的设备上，FRP 状态存储于通常名为 `PERSISTENT` 的分区中。请参阅
[AOSP 实现](https://android.googlesource.com/platform/frameworks/base/+/bc56632da95b/services/core/java/com/android/server/PersistentDataBlockService.java)。

在利用链启动提供 `adb` 和 `dd` 的自定义恢复环境后，请识别并备份该分区。不要使用猜测的数字块设备路径：```bash
adb shell ls -l /dev/block/by-name/PERSISTENT
adb shell dd if=/dev/block/by-name/PERSISTENT of=/tmp/PERSISTENT.backup.img bs=4096
adb pull /tmp/PERSISTENT.backup.img

仅在备份已拉取之后，将分区清零，并让 Android 初始化一个全新的持久数据块结构：```bash adb shell dd if=/dev/zero of=/dev/block/by-name/persistent reboot

此方法经过测试且有效，FRP 已被移除，设备已解锁。

## LK 补丁

补丁选择遵循工件映射：```text
G780F -> lk_g780f_selected_patches.tsv
G980F -> lk_g980f_selected_patches.tsv  (applied to G981B LK)
G981B -> lk_g981b_selected_patches.tsv
G985F -> lk_g985f_selected_patches.tsv  (applied to G986B LK)
G986B -> lk_g986b_selected_patches.tsv
G988B -> lk_g988b_selected_patches.tsv
N980F -> lk_n980f_selected_patches.tsv  (applied to N981B LK)
N981B -> lk_n981b_selected_patches.tsv
N985F -> lk_n985f_selected_patches.tsv  (applied to N986B LK)
N986B -> lk_n986b_selected_patches.tsv

验证TSV文件与库存LK的一致性，而不对其进行修改：```bash python3 external/tools/apply_lk_patches.py
bootLoaderFiles/sbootSplitParts_original/G986B/lk.bin
external/ghidra/lk_g986b_selected_patches.tsv
--check

`external/ghidra/ApplyLkPatches.java` 接受相同的六列 TSV 格式，现在会在旧字节不匹配时失败，而不是盲目应用补丁。第一列为 `kvm` 的行需要额外的 `--kvm` 脚本参数。传统的 `check_signature` 和 `check_ext4_signature` 返回零的行使用配置文件 `0`：它们记录了旧的绕过位置，但有意不应用，因此构建出的镜像必须满足 LK 真实的三星签名检查。

## 签名

`external/tools/sign_sboot_images.py` 需要指定一个型号，并从 [model_data.py](https://github.com/creeeeger/cve-2024-56426/blob/exynos990/external/tools/model_data.py) 中推导出型号 ID、EVT 和回滚版本：```bash
python3 external/tools/sign_sboot_images.py \
  --images-dir exploit/extra/images/G986B \
  --keys-dir external/keys/exynos9830_crecker \
  --model G986B

Stage2 签名在签名后进行验证。该工具不会为 ldfw.img 或 tzsw.img 重新生成 Samsung AVB 元数据；更改这些包装器内的安全启动字节仍需要目标启动流程所使用的单独 AVB 策略。完整的签名 ROM 必须使用精确的 AVB 模型和相同的密钥包，然后使用其完整的生成包进行刷写。请参阅 CreckerROM 仓库以及 USER_GUIDE.md 中的安装工作流程。

被篡改的加载器

包含的被篡改包保留了除 sboot.bin.lz4 之外的所有原厂 BL 成员。该成员被移除，且包的解压 uh.bin 存储为 sboot.bin，与触发 EUB 的布局相匹配。

UI 可以直接执行相应的 Heimdall 流程。它选择精确物理型号的被篡改归档，验证 sboot.bin 与解压后的 uh.bin.lz4 字节完全一致，然后将验证过的 UH 载荷刷写到 BOOTLOADER 槽位：```bash python3 exploit/exploit.py --flash-tampered --model G986B --wait

这会故意阻止正常启动，并强制下一次启动进入 EUB。它不会刷写 BL tar 中的其余成员。

使用以下命令重新生成一个包：```bash
python3 external/tools/build_tampered_loader.py \
  bootLoaderFiles/originalBl/G986B/BL_G986BXXSNHYB1.tar \
  bootLoaderFiles/tamperedLoader/G986B/BL_G986BXXSNHYB1_tampered.tar

使用物理模型被篡改的加载器（当其目录存在时）。耦合的运行时映射适用于漏洞利用预检和签名，而不适用于归档的库存/被篡改 BL 包选择。

请记住，如果你已融合设备，则需要将已签名的 uh.bin 刷入你的 BOOTLOADER 分区，因为库存 uh 当前使用错误的密钥签名。

分析工具

拆分与合并：```bash python3 exploit/split.py sboot.bin -o /tmp/G986B-splits python3 exploit/merge.py /tmp/G986B-splits

独立合并器要求 `tzsw.img` 和 `ldfw.img` 位于 parts 目录中，并输出对应的三部分 Heimdall 命令。仅当这两个镜像已针对所选型号签名时才使用该命令；`--build-sboot` 会自动执行并验证该签名过程。

提取单独的 LDFW 记录：```bash
python3 external/tools/extract_ldfw.py ldfw.img -o LDFWs

所提供的拆分布局可逐字节重建每个规范库存 sboot.bin。当 EPBL 头保持不变时，EPBL 和 EL3 监视器的解密/重新加密也能在所有固件系列中逐字节往返。

载荷兼容性

所有受支持的手机共享相同的 Exynos 990 BootROM。载荷使用通用的 BootROM 入口点和 IRAM 地址，而非特定于型号的 LK 偏移量。生成的二进制文件解析到以下入口点：

特定于型号的行为仅限于 LK TSV、FWBL1 型号 ID 和库存回滚修订版本。

镜像布局

致谢与归属

Chimera Tool：最早发现并实际使用此漏洞的已知来源，约在 2021–2022 年。
三星 CVE-2024-56426 公告：记录了本项目所使用的漏洞。
Christopher Wade：向三星报告了 CVE-2024-56426。
Umer Uddin (halal-beef)，通过 halal-beef/hubble：提供了 exploit/exploit.py 所使用的后端代码；exploit/split.py 和 exploit/merge.py 所使用的 SoC 布局；以及实现地址/覆写操作的 run_exploit()。
VDavid003 (David)，通过 VDavid003/exynos-usbdl：提供了派生 Exynos990 自定义密钥载荷所基于的载荷骨架。

`bootLoaderFiles/originalBl/<model>/`	全部十款型号的干净精确型号 `BL_<firmware>.tar` 包。
`bootLoaderFiles/sbootSplitParts_original/<model>/`	未经改动的精确型号加密 SBoot 拆分文件，包括 `ldfw.img`、`tzsw.img`、清单及尾部。
`bootLoaderFiles/exynos9830Decrypted/<model>/`	精确型号的解密 EPBL、EL3、TZSW 和 LDFW 分析文件。
`bootLoaderFiles/tamperedLoader/<model>/`	精确型号的触发 EUB 的 BL 包。
`bootLoaderFiles/MODEL_COMPARISON.md`	精确型号与耦合固件对比及补丁兼容性说明。
`bootLoaderFiles/exynos990Bootrom/`	共享的 Exynos 990 BootROM 转储。
`bootromNotes/`	共享的 BootROM 流程和 USB 上下文说明。
`drivers/windows/winusb/`	固定的 Houston WinUSB 包，用于 BootROM/EUB `04e8:1234`。
`windows/`	原生 Windows 设置、环境激活及哈希校验驱动安装程序。
`exploit/extra/images/<model>/`	可丢弃的型号特定预检输出。
`external/ghidra/`	精确型号的 LK 和 KVM EL3 TSV 文件及 Ghidra 补丁脚本。
`external/decompiled_G985F/`	仅限 G985F 的反编译参考文件。
`exynos990reverseEng_G985F/`	仅限 G985F 的 Ghidra 项目。
`external/keys/exynos9830_crecker/`	共享的自定义密钥包。
`exploit/exploit.py`	稳定的 CLI 入口点和工作流协调器。
`exploit/build_payloads.py`	跨平台原生载荷构建器，由预检在 Windows、Linux 和 macOS 上使用。
`exploit/preflight.py`	工作镜像准备、LK 补丁、签名及合并验证。
`exploit/usb_transport.py`	PyUSB 帧封装、设备发现、覆写及转储传输。
`exploit/tampered_loader.py`	精确型号 UH 提取、篡改加载器验证及 Heimdall EUB 刷写。
`exploit/stock_restore.py`	精确型号原厂归档提取及 Heimdall 命令构建。
`control_center/`	浏览器后端操作、依赖检查、任务及 HTTP API。
`external/tools/*_crypto.py`	共享的 EPBL/EL3 AES 和 ECDSA 编码/签名原语。

`--prepare`	运行预检而不打开 USB。
`--build-sboot`	运行预检并在型号镜像目录中构建经过验证的已签名 `sboot.bin`。
`--signed`	从 EUB 发送自定义密钥载荷和已签名启动链。
`--ufs`	使用 `loader.bin` 启动 UFS 启动路径。
`--dump`	运行 `mem.bin` 并转储 `0x20000` 字节的 BootROM。
`--flash-tampered`	验证精确型号 UH 并将其刷写到 BOOTLOADER 以强制 EUB。
`--flash-stock`	从原始 BL tar 中提取并刷写精确型号的原厂 SBoot、TZSW 和 LDFW。

`fwbl1.img`	BL1 私钥加 Stage2 TEE/REE 公共 blob
`epbl.img`, `el3_mon.img`	Stage2 TEE
`bl2.img`, `lk.bin`	Stage2 REE
`ldfw.img`, `tzsw.img`	Stage2 TEE，内部和外部 Stage2 页脚

`mem.bin`	`0x02022010`	`0x02022010`
`loader.bin`	`0x02022010`	`0x02022010`
`Exynos990_boot_custom_key.bin`	`0x02022000`	位置无关的第一阶段

`fwbl1.img`	`0x000000`	`0x003000`
`epbl.img`	`0x003000`	`0x016000`
`bl2.img`	`0x016000`	`0x082000`
`lk.bin`	`0x0DB000`	`0x35B000`
`el3_mon.img`	`0x35B000`	`0x39B000`

BL1	`0x02022000`
EPBL	`0x02026000`
BL2	`0x15600000`
LK	`0xE8000000`
EL3 监视器	`0xBFE80000`

CVE-2024-56426

最受欢迎