【鸿蒙PC】二进制签名实战：三类签名、沙箱权限矩阵，以及一张调试证书的坑
内容提要
鸿蒙PC仅允许合法签名的二进制运行。自签名二进制可运行但无法声明权限；调试证书签名可声明权限，但必须使用自行申请的证书，DevEco自动签发的证书会被内核PKCS7校验拒绝。签名后需执行chmod +x，并在module.json中写入设备UDID。实测五种组合，失败时内核日志报E_HM_KEYREJECTED。
延伸解读
签名类型选择：自签名与调试证书的核心差异
自签名（adhoc）二进制无需证书即可运行，但无法声明权限，适合本机开发自用。调试证书签名可声明权限，但必须使用自己申请的证书，且需在module.json中写入设备UDID。DevEco自动签发的调试证书会被内核PKCS7校验拒绝，实测报E_HM_KEYREJECTED。选择时需权衡权限需求与分发范围。
沙箱权限矩阵：应用拉起二进制的限制
弱沙箱应用（具备CUSTOM_SANDBOX权限）可拉起所有类型二进制；强沙箱应用必须申请ALLOW_EXTERNAL_NATIVE_CODE，但仍无法拉起adhoc二进制。交叉编译产物默认是adhoc类型，若需在强沙箱应用中被拉起，必须补调试证书签名转为debug bin。这一矩阵决定了二进制在应用中的可用性。
调试证书签名实操：关键步骤与常见坑
签名后必须执行chmod +x，因为工具沿用outFile旧权限位，不会自动添加执行位。module.json中必须包含device-ids（设备UDID），缺失会导致运行时被拒，日志报udid not in module.json。此外，/data/local/tmp因SELinux label无法被code_protect读取，二进制应放在普通目录如家目录。
故障排查：内核日志是定位签名问题的关键
应用侧日志仅提示EKEYREJECTED，真正原因需查看内核kmsg。通过hilog -k on开启内核日志持久化，复现问题后搜索fsverity或hmcrypt，可看到PKCS7签名验证失败的具体信息。若报E_HM_KEYREJECTED，应优先检查证书链，而非文件系统或路径权限。
Q&A
鸿蒙PC上二进制签名有哪几种类型？它们的主要区别是什么？
鸿蒙PC支持三类签名：二进制证书签名（华为颁发，可无限制分发，支持声明权限）、调试证书签名（华为颁发，仅限指定设备，需开发者模式，支持声明权限但共享库不支持）、自签名adhoc（无需证书，无限制分发，不支持声明权限）。
自签名（adhoc）的二进制程序能声明权限吗？
不能。自签名（adhoc）的二进制程序权限策略段运行过程不会生效，即使写了requestPermissions也没用。要声明权限必须使用调试证书签名。
调试证书签名后运行报Operation not permitted，可能是什么原因？
可能原因包括：未在module.json中正确填写设备UDID（报udid not in module.json），或使用了DevEco自动签发的调试证书（内核PKCS7校验失败，报E_HM_KEYREJECTED）。需使用自己申请的调试证书并确保UDID正确。
调试证书签名时，module.json中必须包含哪些内容？
必须包含requestPermissions数组（声明所需权限）和debug-info对象，其中device-id-type为udid，device-ids数组填入运行设备的UDID。缺少device-ids会导致运行时被拒。
签名后为什么还需要执行chmod +x？
因为binary-sign-tool是向预先存在的outFile写入签名数据，文件权限位沿用旧文件。如果outFile是从没有执行位的文件复制而来，签名后仍然不可执行，运行时会报Permission denied。所以必须手动chmod +x。
如何获取鸿蒙PC设备的UDID？
可以通过命令hdc shell bm get --udid获取设备UDID。
应用拉起二进制时，强沙箱和弱沙箱的权限有什么区别？
弱沙箱应用（具备ohos.permission.CUSTOM_SANDBOX）可以拉起所有类型的二进制（normal bin、debug bin、adhoc bin）；强沙箱应用（不具备该权限）必须申请ALLOW_EXTERNAL_NATIVE_CODE才能拉起normal bin和debug bin，但即使申请了也无法拉起adhoc bin。
DevEco自动签发的调试证书为什么会导致签名失败？
实测发现，DevEco自动签发的调试证书会被内核的PKCS7签名校验拒绝，报错E_HM_KEYREJECTED。而使用自己申请的调试证书（即使证书链结构相同）则可以正常运行。该问题已提工单，根因待官方确认。
