软件加固交付报告阅读指南：配置、静态、运行与边界验证

报告结构与阅读顺序

一份典型的加固交付报告包含多个信息层，涵盖加固配置说明、基于静态分析的保护生效检查、基于运行日志或符号化堆栈的动态证据，以及未覆盖到的代码入口或检查项。阅读时不能从头到尾平铺直叙，而应先找到报告的产物标识部分，通常是 APK 包名、版本名、版本号和文件 SHA-256 摘要，并用系统工具核对候选包。如果文件摘要对不上，说明报告可能属于另一构建产物，后续所有结论直接失效。

接着追溯报告的生成时间与构建任务标识。加固工具通常在一次构建中同时生成加固报告与候选包，报告内的任务 ID、构建时间应与 CI/CD 记录一致。若报告时间早于最终签名时间，报告中缺少签名相关检查则属于正常范围；反之，若最终包已签名但报告中声称未签名，就是配置证据错乱。这一步的目的是把报告时序锚定到交付流程中，避免用错误阶段的中间产物替代最终候选包。

最后按依赖关系阅读：先确认静态检查是否基于正确的产物摘要，再看运行证据所引用的符号文件、设备指纹是否与测试环境匹配，最后处理未覆盖项。这种顺序可以保证每个结论都有上游可查的绑定证据，而不是孤立地阅读某一项数值。任何跳过绑定关系直接采信数字的读法，都会让报告失去可审计性。

• 将报告首页的产物摘要与待交付 APK/AAB 使用 sha256sum 比对
• 检查报告生成任务 ID 是否与 CI 平台构建记录一致
• 确认报告覆盖的打包阶段（未签名、已签名、已对齐）与拿到手的候选包阶段一致
• 按依赖顺序阅读，不跳过绑定验证

配置声明：从工具意图到真实存在

配置声明部分列出用户在加固控制台勾选的功能组合，例如字符串加密、类重命名、反调试、完整性保护等。报告中常以功能开关表的形式出现，每一行标有“已启用”或类似字样。这一部分表达的是工具收到的操作意图，而非产物中真实生效的保护指令。单看配置声明，无法判断编译器、混淆器或签名工具是否在后续流程中丢弃了某些保护逻辑。

验证配置是否生效，需要从报告中提取对应配置项到静态检查结果中寻找证据。例如，若配置启用字符串加密，静态检查结果应列出常量池中已被替换为解密回调的条目数量或比例。如果静态检查部分缺失该条目，或者只提供方法数而未提供引用地址，说明报告没有给出足够证据，读者不能自行推论“启用即生效”。在此类判断中，缺乏证据通常意味着该功能未在当前构建中实际覆盖。

配置声明还与 ABI 拆分、多 dex 结构有关。一份报告可能声明“全架构已启用反调试”，但静态检查可能只覆盖了 arm64-v8a 的 .so 文件，armeabi-v7a 的 native 库未被检测。此时配置声明与静态检查范围之间的差距就是风险留存区。读者必须把配置项、产物目标架构和静态提取范围三者放到同一个对照表中才能判断是否实际覆盖。

静态检查：把报告摘要绑定到单一候选包

静态检查部分是报告中最可直接复验的部分，通常包括 DEX 中方法数量的变化、混淆后的类名映射、assets 或 so 文件的哈希列表等。静态检查结论的效力完全取决于是否能把这些数字与当前待上线的候选包严格绑定。读者必须使用报告中提供的所有产物摘要至少进行一次手工校验：用 openssl dgst 或 apksigner verify 的输出与报告值比对，任何一个摘要不匹配都意味着报告与候选包有可能不是同一次构建产物。

关键静态检查项往往包含保护后方法的特征数量，例如被加密的方法数量、被重命名的类数量等。这些数字只有在与原始未加固包做比对时才有意义。但交付报告中通常不附带原始未加固包的摘要，读者需要在内部构建系统中回溯到与加固任务关联的同一源代码版本、同一 commit、同一构建指令生成的原包，再提取相同维度的统计。缺少原始比对基线，单纯看“新增 2000 个加密方法”无法判断生效范围。

针对 native 代码的静态检查高度依赖符号表的有无。如果 so 文件在加固后被进一步 strip，报告中的 offset 列表可能因符号丢失而无法与反汇编对应。阅读时需确认报告中是否声明了 strip 状态以及使用的符号库版本。如果报告声称“已隐藏导出函数”，静态检查中却又列出导出表条目，这就是明显的结论冲突。读者遇到此类自矛盾项必须向加固服务方要求澄清，不能自行选择相信某一半。

运行证据：符号化、行为日志与设备绑定

运行证据通常包含从真机或模拟器上采集的崩溃堆栈、logcat 片段、检测点命中记录等。这些证据的价值在于证明工具植入的保护措施在运行时确实被触发了，而不是仅仅存在于二进制中。但符号化过程是其中最大的误差源。报告中的堆栈必须是经过与本构建精确匹配的符号文件还原后才能用于判断。若符号文件与构建产物不匹配，还原出的函数名和行号会指向错误的位置，导致“反调试已触发”这类结论丧失可信度。

验证运行证据的第一步是确认符号文件身份。对于 Java/Kotlin 层，报告需给出 mapping 文件本身的 SHA-256 并声明它来自哪次构建任务。读者在本地使用 retrace 工具输入同一 mapping 文件和报告中的原始混淆堆栈，应能从标准输出得到与报告中一致的还原结果。如果还原结果不同，要么 mapping 文件版本不对，要么报告中的原始堆栈被截断或转义出错。对于 native 层，ndk-stack 同样要求未剥离的符号目录与报告中的地址基础一致。

运行证据还隐含对测试设备环境的依赖。反调试行为在不同 Android 版本、不同 ROM 上可能表现不同。报告如果声称“成功绕过某版本 ptrace 检测”，但没有记录设备指纹（制造商、型号、Android API level、内核版本），读者就无法重现该结论。作为验证方，必须要求报告附带设备描述字段，并判断该设备是否足够接近生产环境中的主流机型。如果测试设备过于陈旧或经过定制的 ROM 允许过度权限，运行证据可能无法证明通用有效性。

供应链证据：构建证明与签名校验闭环

加固交付报告如果附带供应链证据，应包含构建证明（如 SLSA Provenance）和签名验证记录。构建证明描述构建者身份、构建参数、源码仓库状态和产物摘要，它的作用是回答“这份包是谁、用什么方式、在什么环境下生成的”。阅读时首先应校验证明文件本身的签名，确认签发者属于可信的构建服务实体。然后提取其中声明的产物摘要，与本地的 APK 摘要比对，防止证明与包体错配。

签名校验是另一个闭环关键。构建证明可以声明产物在打包后被特定证书签名，但报告必须额外提供 apksigner 或类似工具的校验输出，表明签名覆盖了所有必需方案（v1/v2/v3）且证书链受信任。仅凭构建证明中的“已签名”字段不足以替代实际的签名方案校验，因为证明中的声明只是一个字符串，不具备密码学绑定。读者需要实际执行 apksigner verify --verbose，并把输出中的证书指纹、公钥算法、签名方案完整记录到验收文档中。

供应链证据的价值还在于提供变更追溯能力。如果报告引用了 in-toto 证明格式，产物摘要与声明负载的绑定可以用 in-toto 的 statement 结构来验证。审查者需要确认声明类型与产物用途一致，例如一份证明意图是“完成字符串加密”的产物不应被当作“完成全类加密”的产物。这种声明类型错配如果未被及时发现，会在合规性审查中造成根本性错误。因此阅读供应链证据时，一定要比对声明类型与被交付加固报告所描述的功能范畴是否一致。

#!/usr/bin/env bash
set -euo pipefail

REPORT_SUBJECT_DIGEST="${1:-report_subject_sha256.txt}"
APK_FILE="${2:-candidate.apk}"
SIGNER_CERT="${3:-signer.crt}"

echo "== 校验 APK 签名方案覆盖 =="
apksigner verify --verbose --print-certs "${APK_FILE}" | tee apk_signer_info.txt

echo "== 检查 APK SHA-256 =="
LOCAL_SHA256=$(sha256sum "${APK_FILE}" | awk '{print $1}')
if [ ! -f "${REPORT_SUBJECT_DIGEST}" ]; then
  echo "FAIL: 报告摘要文件不存在" >&2
  exit 1
fi
REPORTED_SHA256=$(awk '{print $1}' "${REPORT_SUBJECT_DIGEST}")
if [ "${LOCAL_SHA256}" != "${REPORTED_SHA256}" ]; then
  echo "FAIL: APK 摘要与报告不符，候选包身份错误" >&2
  exit 1
fi

echo "== 校验签名证书链 =="
if [ ! -f "${SIGNER_CERT}" ]; then
  echo "FAIL: 签名证书文件不存在" >&2
  exit 1
fi
CERT_FINGERPRINT=$(openssl x509 -in "${SIGNER_CERT}" -noout -fingerprint -sha256 | cut -d= -f2 | tr -d ':')
REPORTED_FINGERPRINT=$(grep -Po '(?<=cert SHA-256 digest: ).*' apk_signer_info.txt || true)
if [ -z "${REPORTED_FINGERPRINT}" ]; then
  echo "FAIL: 未提取到报告证书指纹" >&2
  exit 1
fi
if [ "${CERT_FINGERPRINT^^}" != "${REPORTED_FINGERPRINT^^}" ]; then
  echo "FAIL: 签名证书指纹不匹配" >&2
  exit 1
fi

echo "供应链证据验证通过"

未覆盖项：明确报告未回答的问题

未覆盖项会列出尚未处理或尚未检查的代码入口、ABI、组件与执行路径。阅读时把每一项映射回应用架构，确认它是否位于关键业务路径。例如“反射调用的方法未加密”只说明保护范围，不足以单独判断该路径是否可被利用。

未覆盖项必须结合应用实际运行时特性判断风险高低。如果未覆盖的是某个仅在 Android 4.x 设备上加载的 native 模块，而当前发布已不兼容该版本，则实际风险可控；但如果未覆盖的是登录模块的核心方法，即便业务声称已弃用，都应视为高风险。读者需要将未覆盖项映射到自身应用的架构图上，标注哪些模块被排除在保护范围之外，为后续渗透测试或安全审查提供明确的入口点。

报告对未覆盖项往往只给类别，不给风险等级。内部团队可以先按数据敏感度和调用可达性排序；无法判断的项，再交给独立测试人员设计用例。未覆盖表示尚无当前结论，既不能直接视为漏洞，也不能被整体结论带过。

结论边界：报告没有回答的关键安全问题

加固交付报告中的每条结论都存在天然的边界，超出边界的问题该报告无法提供答案。例如，静态检查断言“所有 .so 文件导出函数已隐藏”，它的边界仅限于 ELF 动态符号表的可见性，不能自动得出攻击者无法通过 dlsym 或内存扫描定位函数的结论，因为导出表隐藏不消除内存中的代码特征。阅读时要在每条结论的旁边做笔记，记录“这最多能证明什么”，而不能扩充含义。

另一类边界涉及平台的耐久性。报告可能基于测试时的 Android 安全补丁级别得出结论，例如“成功绕过 SELinux 限制”。该结论仅对相同的内核版本和策略有效。每当目标设备的安全补丁级别更新或厂商修改了策略规则，原来生效的绕过手段可能立即失效。交付报告无法预测平台未来的变化，因此审核者必须为每一个环境依赖型结论标注有效期和失效条件，以免将实验证据当成永久保证。

性能数字也要连同测试条件阅读。报告若写“启动耗时增加 3%”，它只对应当时的机型、系统负载、样本和统计口径，不能直接推广到全部设备。审核者应保存这些条件，并在目标设备上复测；没有覆盖的环境继续标为未知。

• 为每条结论标注它最多能证明什么，以及不能证明什么
• 对环境依赖型结论明确记录适用设备的指纹和失效条件
• 对性能观察值仅视为特定条件下的测量，不泛化
• 任何结论不能自动从静态推导到运行时，反之亦然

报告归档与版本变更后的重验决策

交付报告的最终用途是在发布门禁中作为安全验收的证据。因此报告必须与候选包、符号文件、签名证书、构建证明一同归档，并建立不可变快照。仅保存报告 PDF 而不保存对应的验证工具链和原始产物，未来在事故响应时将无法回溯当时的保护状态。归档的最小集合包括：候选包、加固报告、mapping 文件、符号目录、签名验证输出以及在门禁步骤中运行的验证脚本日志。

当应用因版本变更重新构建时，上一版本的交付报告不能延用到新版本。代码的任何变动都可能改变方法签名、类结构和调用图，导致原有保护路径失效或偏移。版本变更后的再次加固必须生成全新报告，并重新执行上述全部验证步骤。试图用旧报告的结论覆盖新包是工程事故的常见起源，工程决策必须严格遵循每版本一报告、每包一验证的原则。

如果第三方安全评估或渗透测试指出原报告未覆盖项被实际利用，归档的报告应立即被标记为“已知缺口”，并将利用条件补充到未覆盖项的后续评估中。同时应触发对同类保护措施的全面回归，而不是仅修补单个漏洞。这种事故反馈循环只有建立在报告可追溯、可检索的存档之上才能高效运转，否则每次事件都要重复手工分析，成本极高且易出错。