红米MTK CUST制作中固件签名失败如何解决？

Question

在红米MTK CUST分区固件定制过程中，常因签名密钥不匹配导致刷机失败。问题表现为：使用SUW或SP Flash Tool写入自定义CUST镜像后，设备卡在开机LOGO、系统无法启动或提示“signature verification failed”。此问题多源于未使用官方授权的私钥对镜像进行正确签名，或签名工具配置错误（如未启用SECURE BOOT及正确的AVB/DM-Verity配置）。此外，部分机型要求CUST分区与PROINFO、ODM等分区联合签名，遗漏任一分区签名均会导致验证失败。如何在无官方密钥的情况下，通过逆向分析签名机制并使用适配的测试密钥完成合法签名？

Answer 1

红米MTK CUST分区固件定制中的签名机制深度解析与绕过方案

1. 问题背景与常见现象分析

在基于联发科（MTK）平台的红米设备固件定制过程中，CUST分区常用于存储运营商或地区特定配置信息。开发者通过SUW（Smart Update Wizard）或SP Flash Tool写入自定义CUST镜像时，若未正确处理签名验证机制，极易导致设备无法正常启动。

• 现象一：设备卡在开机LOGO界面，无进一步启动日志输出
• 现象二：系统提示“signature verification failed”并自动重启
• 现象三：刷机工具报错“SEC_AUTH_EXCEPTION”或“AUTH_FAIL”

这些问题的根本原因在于Android系统的安全启动链（Secure Boot Chain）对分区镜像进行了完整性与来源验证，而CUST作为受保护分区之一，必须通过合法签名才能被加载。

2. 签名验证机制的技术原理

MTK平台采用多层级的安全启动架构，涉及以下关键组件：

层级	验证主体	使用密钥类型	作用范围
BL (Bootloader)	ROM Code	OEM Root Key	验证PL
PL (Pre-loader)	BL	Device Key	验证LK
LK (Little Kernel)	PL	AVB Public Key	验证boot、system等AVB分区
AVB/DM-Verity	LK/kernel	VBMeta Key	验证CUST、ODM、PROINFO等客制化分区

CUST分区通常由LK阶段通过AVB（Android Verified Boot）进行校验，其签名依赖于编译时嵌入的公钥证书。若私钥缺失或签名方式错误，则验证失败。

3. 官方签名流程与权限限制

小米官方在构建固件时使用高度保密的私钥对所有受信分区进行联合签名。典型流程如下：

# 示例：官方签名脚本逻辑（简化版）
sign_image --key oem_signing_key.pem \
           --cert oem_certificate.x509.pem \
           --algorithm SHA256_RSA2048 \
           --input cust.img \
           --output cust_signed.img
    

由于这些私钥不对外公开，第三方开发者无法直接生成合法签名。此外，部分机型要求CUST、PROINFO、ODM三个分区以“联合哈希”方式打包签名，即：

graph TD
            A[CUST.img] --> D{Concatenate}
            B[PROINFO.img] --> D
            C[ODM.img] --> D
            D --> E[Hash(SHA256)]
            E --> F[Sign with Private Key]
            F --> G[Signed Metadata]
            G --> H[Embed into VBMeta]

4. 逆向分析签名机制的方法论

在缺乏官方密钥的前提下，需通过逆向工程手段还原签名算法与结构特征。常用技术包括：

1. 提取已签固件中的vbmeta.img，使用avbtool verify_image分析签名算法
2. 反汇编LK镜像，定位AVB公钥存储位置（常位于.rodata段）
3. 比对多个版本固件中CUST头部字段差异，识别签名头格式（如Magic Number: 0x4D4D4D4D）
4. 利用IDA Pro或Ghidra追踪verify_cust_partiton()函数调用链
5. 通过fastboot oem read_config命令尝试读取设备当前签名状态
6. 监控SP Flash Tool日志，捕获Authentication Fail的具体阶段
7. 使用binwalk对scatter文件关联的img进行结构分解
8. 分析preloader中SEC_CTRL寄存器配置是否启用EFUSE烧录模式
9. 检测是否存在test key fallback路径（某些工程机保留）
10. 构造dummy image测试不同签名模式下的响应行为

5. 测试密钥适配与合法签名实现路径

尽管无法获取官方私钥，但可通过以下策略实现“逻辑合法”的签名替代：

# 构造测试密钥对（适用于实验环境）
openssl genrsa -out testkey_rsa2048.pem 2048
openssl req -new -x509 -key testkey_rsa2048.pem -out testkey.x509.pem -days 3650

# 使用AVB工具重新签名CUST分区
avbtool add_hash_footer --image cust.img \
                        --partition_name cust \
                        --partition_size 4194304 \
                        --key testkey_rsa2048.pem \
                        --algorithm SHA256_RSA2048 \
                        --salt $(hexdump -n 32 /dev/urandom | awk '{print $2$3...}')
    

此方法的前提是目标设备处于“unlocked bootloader”状态且支持用户自定义VBMeta替换。对于锁定设备，还需配合修改dtbo或lk patch跳过特定校验分支。

6. 联合签名与多分区协同处理

针对需联合签名的机型（如Redmi Note 10 Pro MTK版），应将CUST、PROINFO、ODM统一纳入签名包：

分区	大小（KB）	是否需单独签名	联合签名角色
CUST	4096	否	主数据源
PROINFO	1024	否	附加元数据
ODM	8192	否	扩展配置区
VBMeta	64	是	承载签名摘要

实际操作中，可编写Python脚本自动化拼接三者哈希值，并注入至vbmeta结构体中，从而模拟原厂签名行为。