多渠道多 Flavor App 如何选择加固 PoC 样本

从构建变体清单识别加固敏感差异

Android 构建可以把同一仓库组合成多个发布包：构建类型决定调试或发布配置，产品风味承载渠道差异，源码集覆盖对应代码和资源。选样前先从 Gradle 配置导出可发布变体，记录 applicationId、签名、资源和源码差异。这样才能知道一个内测包究竟代表哪些线上渠道。

发行多渠道 App 时，产品风味常按渠道、区域或品牌拆分，例如 free、pro 或 cn、global。这些风味不仅改变应用 ID，还可能引入完全不同的第三方 SDK、广告标识和后台环境。加固方案如果需要对特定 SDK 做兼容或白名单处理，未经差异化验证就把一个通用配置应用于所有渠道，轻则 SDK 功能异常，重则应用闪退或安全模块自检失败。因此，加固 PoC 的首要工作不是随机挑一个包，而是从构建系统中导出完整变体矩阵，并与产品发行清单进行比对。

source set 的文件合并顺序进一步放大了变体间的差异。比如 flavor pro 可以拥有自己 res/values/strings.xml 和 AndroidManifest.xml 片段，与 main source set 叠加后改变权限声明、组件导出状态甚至 networkSecurityConfig。加固过程常需要解析和重打包这些清单与资源，一处细小的合并差异就可能让加固壳的运行时校验误判篡改，导致启动即崩溃。所以必须记录每个变体特有的清单合并结果，作为后期样本筛选的依据之一。建议在 CI 中利用 aapt 或 manifest merger 报告比对变体差异。

变体差异不仅体现在代码逻辑上，更深刻地影响二进制文件的内部布局。不同的 build type 可能导致混淆规则不同，debug 版本通常关闭混淆而 release 版本开启，这会彻底改变类名和方法名的映射关系。加固工具若依赖特定的类名特征进行挂钩或保护，在混淆后的环境中可能找不到目标，从而导致保护逻辑失效。此外，资源 ID 的重排也可能因 flavor 而异，使得基于资源 ID 硬编码的校验逻辑在不同变体间表现不一致，必须逐一排查。

签名与密钥管理如何决定样本入选

发布渠道可能使用不同的应用签名密钥或上传密钥，甚至同一渠道的 debug 和 release 变体使用截然不同的证书。加固工具在保护 Dex 和资源时，常将签名散列或证书指纹嵌入壳代码，运行时与当前签名比对以检测二次打包。若 PoC 样本使用与最终发布不一致的证书，线上包将因签名校验失败直接被终止，所有安全保护形同虚设。因此 PoC 必须包含每个签名变体，尤其当某些渠道采用 Google Play App Signing 密钥托管，其他渠道使用自持有上传密钥时。

Play App Signing 把上传密钥与面向用户的应用签名密钥分开。本地用上传密钥生成的包，不能代表商店最终交付的签名环境。若保护逻辑读取证书信息，应从内部测试轨道取得实际派生包再复测；当前没有项目生产签名证据，文章不声称这一渠道已经验证。

密钥管理不仅影响加固后安装，还涉及动态加载的模块和插件。很多 App 集成了热修复或 RN/Flutter 等动态化方案，这些模块可能由独立证书签名。加固壳在加载 dex 或 so 时如果校验签名链，没覆盖对应变体就无法发现因证书链缺失导致的加载失败。建议将签名差异作为一个独立维度映射至变体矩阵，确保每个独特的签名组合至少有一个代表性样本进入 PoC 清单。

签名算法的选择也会影响加固兼容性。虽然目前主流使用 V2/V3 签名方案，但部分老旧设备或特殊渠道可能仍依赖 V1 签名。加固工具在重打包过程中若破坏了 V1 签名的完整性，会导致在这些设备上安装失败。因此，样本选择时需确认各变体启用的签名方案版本，特别是那些面向低端市场或特定区域市场的渠道，必须包含仅启用 V1 签名或混合签名方案的变体进行专项验证。

• 检查每个变体的 signingConfig，确认是否使用了不同的 keystore
• 如果部分渠道启用 Play App Signing，从 Play Console 获取预签名的内部测试 APK 作为该渠道样本
• 记录证书 SHA-256 指纹，用于后期加固校验比对
• 确认各变体启用的签名方案版本（V1/V2/V3）是否覆盖所有目标设备

SDK 与二进制依赖的变体选择判断

渠道常会替换广告、支付、统计或登录 SDK，连带改变代码、Native 库、资源和合并清单。把每个变体的实际依赖版本列出来，再按组合差异选样。Google Play SDK Index 可补充部分公开指引，但不覆盖所有 SDK，也不提供适用于本项目的风险排名。

SDK 版本之间的差异不仅限于 API，还包括其内部的代码乱序、字符串加密或资源文件名。加固方案如果采用特定版本的 SDK 做兼容适配白名单，一旦线上渠道使用的 SDK 微版本号与白名单不匹配，加固逻辑会失效甚至主动终止运行。由于《Google Play SDK Index》不覆盖所有私有或开源 SDK，需结合二进制清单（如 APK Analyzer 或 dependency tree）人工核对每个变体的实际 SDK 版本。建议生成每个变体的 SDK 列表并进行交叉对比。

另外，Native 库依赖很可能随 SDK 组合而变化，比如渠道 A 的支付 SDK 要求存在 lib/armeabi-v7a 下的.so 文件，而渠道 B 的广告 SDK 则只提供 arm64 版本。加固工具对 Native 库的提取、加密和重打包是按文件列表完成的，若缺少某个 so 的路径，可能导致整个 ABI 目录被忽略，进而引发 UnsatisfiedLinkError。所以从 SDK 维度筛选 PoC 样本时，不能只看类依赖，还要检查 lib 目录下的文件集合差异。

部分 SDK 会在初始化阶段进行环境检测，如 Root 检测、模拟器检测或调试器检测。加固壳本身也具备类似功能，两者若同时运行且策略冲突，可能导致应用无法正常启动。例如，某 SDK 检测到被 Hook 后直接退出，而加固壳正是通过 Hook 实现保护，这种矛盾在单一变体测试中难以发现。因此，必须选择集成了多种敏感 SDK 的变体作为 PoC 样本，验证加固壳与这些 SDK 的共存兼容性。

资源拆分与过滤对加固产物的区别

构建变体通过 resConfigs、屏幕密度过滤和语言精简，可能使不同渠道的 resources.arsc 及资源文件列表截然不同。加固工具在保护应用时通常要解析资源表并重打包资源 ID，若资源映射因过滤而产生偏移，加固后再进行资源合并（如 AAB dynamic feature）就会出现 ID 冲突或引用错误。尽管资源差异对加固成功率的影响低于签名和 SDK，但对于使用了高级资源加密或隐藏等特性的产品，不覆盖极端资源裁剪的渠道可能留下运行时白屏隐患。只要有一个渠道启用了非默认的资源配置，就应将该渠道变体作为候选样本。

Android App Bundle (AAB) 本身不是最终安装 APK，而是根据设备配置由 Play Store 生成多个 split APK。根据《Android App Bundle format》的说明，AAB 包含 base、feature、配置与资产模块，最终生成的 APK 集会因屏幕密度、语言和 CPU 架构而千差万别。如果加固服务直接在 AAB 层面操作，需要在将 AAB 转换为通用 APK 后再进行加固，但这就改变了原生 split 结构，可能影响到 Play 的动态交付效率。PoC 样本必须包括由 bundletool 本地生成的特定设备 spec 的 APK 集，以验证加固处理是否破坏 split 配置的完整性。

《Build and test Android App Bundles》指出，bundletool 可重现和验证设备交付行为，但本地生成无法完全替代 Play 线上交付回执。实践中，某些资源分割条件（如纹理压缩格式）依赖 Play 服务端数据，本地模拟可能不触发相同的资源筛选路径。如果加固工具在 APK 级修改了资源压缩表，线上交付时可能因哈希校验失败被拒绝安装。因此，选择 PoC 样本时如果涉及 AAB 分布，建议至少在一个渠道中通过 Play 内部测试轨道获取真实 split APK，否则无法完全排除资源交付差异带来的加固副作用。

资源文件的加密和保护也是加固的重要环节。不同变体可能包含不同的图片、音频或配置文件，这些文件的大小和格式会影响加固工具的压缩算法和加密强度。例如，某个变体包含大量高分辨率图片，加固后包体积激增可能导致下载转化率下降；而另一个变体资源极少，加固开销占比过高可能影响启动速度。因此，在样本选择时需考虑资源总量的分布，选取资源量最大和最小的变体分别测试，以评估加固对包体积和性能的综合影响。

Native 库、ABI 与平台适配的样本覆盖

加固技术常常需要将其自身的.so 文件注入应用，这些 so 文件又是按 ABI 编译的，如 armeabi-v7a、arm64-v8a、x86、x86_64。如果某个渠道只支持 armeabi-v7a，而加固提供的保护库仅提供 arm64 版本，则该渠道无法被保护。反过来，如果应用内不同的变体勾选了不同的 ABI 支持集（例如国内渠道移除了 x86 以减小包体积，海外渠道保留模拟器支持），PoC 样本必须分别覆盖这些 ABI 组合，确认加固方案在每种 ABI 子集下都能正确注入且不影响原有库加载。

Native 依赖也会随变体变化：有的渠道静态链接运行库，有的携带独立 SO 或保护组件。应从每个候选包提取已编译 SO 列表，再用只读工具比较 ABI、依赖和导出差异。与当前代表样本差异明显的变体，应单独进入 PoC 清单，并记录需要复测的加载与启动路径。

部分加固方案提供"so 保护”选项，会对整个 lib 目录进行加密和自加载。这种改造对 so 的文件名、段对齐和 DT_NEEDED 字段非常敏感。如果变体 A 和变体 B 虽然都引用 libnative.so，但编译时使用的 NDK 版本或构建标记不同，一个加了-fstack-protector 而另一个未加，加固后还可能因栈保护检测不一致触发强制终止。在无法确认所有生产构建参数的情况下，安全的 PoC 覆盖策略是：对于包含 Native 代码的渠道，至少选择具有最多 so 数量、最小 so 数量和使用了不常见 ABI（如 mips）特征的变体各一个，作为测试样本。

Native 库的加载顺序和初始化时机也是关键变量。某些变体可能在 Application onCreate 之前通过 System.loadLibrary 预加载核心库，而另一些变体则延迟到特定业务模块初始化时加载。加固壳如果需要拦截或监控这些加载过程，必须适应不同的时序。若样本选择不当，可能遗漏那些在极早期加载 Native 库的变体，导致加固壳未能及时挂钩而失去保护作用。因此，需审查各变体的启动流程，确保覆盖最早和最晚加载 Native 库的场景。

基于发布占比的样本优先级排序

预算、时间和加固测试精力的限制使得不可能对所有变体逐一完成完整的 PoC 测试。此时需要引入发布占比作为优先级权重。应统计各个渠道变体在用户设备上的激活占比或下载量分布，极大占比（如>80%）的渠道即便签名和 SDK 组合与其他渠道接近，也必须独立测试，因为它代表了绝大多数用户的运行环境。若某个小占比渠道使用了截然不同的 Native 库或签名，也不能完全忽略，因其可能成为安全攻击的跳板，但在 PoC 阶段可以降低测试深度，仅做基础兼容验证。建议结合业务负责人提供的渠道分级名单，将变体划分为“必测”“按风险抽查”“可暂缓”三类。

发布占比数据通常来自应用市场后台或第三方统计 SDK 导出报表，不属于构建过程信息。由于运营数据通常不属于构建过程信息，可暂时以渠道标识及业务重要性作为替代因子。例如，品牌合作渠道、应用宝主推渠道等即使占比不高也可能具有极高的业务重要性，应将其变体等级提升至“必测”。在决策表中，可以通过加权打分：占比权重*业务关键度*技术差异度，将结果映射到必测、抽查和暂缓。但必须说明，这种打分缺乏真实的占比数字，只是逻辑框架，后续需要产品运营填入真实百分比。

关于 AAB 派生 APK 的占比复杂性：一个 AAB 可能为一个渠道生成多个针对不同设备的 split APK，每个 APK 的下载量又不同。若按照 APK 维度去计算占比会非常庞大，因此应退回到 flavor/build type 维度，将渠道视为整体，并对该渠道覆盖的设备谱系做一次抽样，使用 bundletool 生成极端设备 spec（如低密度 armeabi-v7a 和高密度 arm64-v8a）的 APK 集作为代表。此方法不能保证一切设备，但可以在现有资源下最大化发现兼容问题。

优先级排序还需考虑历史故障记录。如果某个变体在过去曾因加固或 SDK 升级出现过严重问题，即使当前占比不高，也应优先纳入 PoC 测试范围。历史数据能反映该变体的特殊性和脆弱性，帮助团队规避已知风险。此外，新上线的渠道或即将大规模推广的变体，由于缺乏历史数据支撑，更应作为高优先级样本进行多环节验证，防止因准备不足导致上线事故。

利用构建证明校验变体身份

候选列表确定后，再确认手里的 APK 确实来自所标注的构建变体。若 CI 已生成构建证明，可核对产物摘要、构建者、参数和依赖记录；没有构建证明时，至少比对签名、versionCode、applicationId 与归档记录。身份核对只解决拿错包的问题，不证明运行时保护有效。

《SLSA Provenance v1.1》指出，provenance 应包含 subject（绑定产物摘要）、builder.id、buildType、externalParameters 和 materials 等信息。如果每个变体在发布构建时都已产生独立的 provenance 文件，就可以编写自动化脚本对 PoC 候选 APK 做摘要比对，确认其与构建时记录一致。但这种校验存在明确边界：provenance 只能证明记录的构建过程，不能单独证明运行时安全性。应用加固后，provenance 将失效，因为产物已经改变，所以必须在加固前完成身份确认，将原始 APK 和其 provenance 一并存档。

即便项目尚未实现 SLSA 级别的构建产物签名，至少可以通过比较 AndroidManifest 中的 versionCode、versionName、applicationId 和已记录 commit sha 来初步确认变体来源。更严格的方式是使用构建系统内置的 hash（如 Gradle 生成的 output-metadata.json 内的 task outputs），与手头 APK 的解压摘要做对比。这些操作并不能替代 provenance 的不可抵赖性，在当前约束下可作为轻量级可信度校验，降低因用错包而进行无效加固测试的风险。

构建证明的校验还应包括对构建环境的验证。不同的构建服务器、JDK 版本或 Gradle 插件版本都可能产生物理字节码不同的 APK，即使源代码完全一致。如果 PoC 样本是在本地开发机构建的，而生产包是在 CI 服务器构建的，两者的字节码差异可能导致加固工具行为不一致。因此，理想的 PoC 样本应直接取自 CI/CD 流水线的产出物，并附带完整的构建日志和环境快照，以确保测试环境与生产环境的高度一致性。

• 检查 CI 系统是否生成 provenance 或构建元数据
• 用 sha256sum 对比记录值和实际 APK 值
• 加固前备份原始 APK 及其 provenance 以用于事后追溯
• 确认构建环境（JDK、Gradle 版本）与生产环境一致

生成样本覆盖与排除说明的技术步骤

综合代码、签名、SDK、资源、Native 和发布占比维度的分析后，最终需输出一份有据可查的样本选择清单和排除理由。清单应包含变体标识、选择的理由（如签名与生产一致、含关键 SDK）、将被排除的变体及其排除原因（如 debug 证书、未被发布等）。这份文档不仅用于内部评审，也常作为加固服务商理解渠道复杂性的输入，避免沟通偏差导致加固方案遗漏处理。清单的格式建议为表格或机器可读的 JSON，方便后续与自动化测试管线集成。

可配套以下只读诊断脚本，根据 APK 路径读取签名、包名、Native 目录结构和资源表特征，输出与预期清单的比对结果。脚本仅执行只读操作，不会修改或删除任何文件，失败时返回非零退出码。通过此脚本可在加固前快速确认样本的基本维度，确保没有选择错误的 APK 变体。脚本依赖 apksigner、aapt 和 unzip 等公开工具，这些工具属于 Android SDK 或构建环境标配，无需额外风险软件。

完成样本清单和诊断验证后，进入加固 PoC 执行阶段前，必须建立一个版本锁定机制：所有被选样的 APK 文件连同其构建 commit、签名证书指纹、provenance（如有）一起归档，后续任何构建环境的升级或 SDK 版本变更，都需要重新评估是否影响代表性。如果某个渠道后续更新了广告 SDK 或增加了新的 Native 库，该渠道就要被重新纳入 PoC 清单。这种持续性的覆盖评审是安全加固工作融入 DevSecOps 的基本前提，而非一次性检验。

样本选择文档还应包含明确的回滚策略。一旦加固后的样本在测试中发现严重问题，能够迅速定位到具体的变体和构建版本，并恢复到未加固状态。这需要详细的版本控制记录和清晰的命名规范，确保每个样本都有唯一的标识符。同时，文档中应记录每次测试的结果和发现的问题，形成知识库，为后续的加固迭代提供参考，避免重复犯错。

#!/usr/bin/env bash
set -euo pipefail
APK="$1"
if [[ ! -f "$APK" ]]; then
  echo "错误：文件不存在" >&2
  exit 1
fi
echo "签名证书指纹："
apksigner verify --print-certs "$APK" 2>/dev/null || {
  echo "签名验证失败" >&2
  exit 2
}
echo "----------"
echo "应用包名和版本："
PACKAGE=$(aapt dump badging "$APK" | sed -n "s/.*package: name='\([^']*\)'.*/\1/p")
if [[ -z "$PACKAGE" ]]; then
  echo "无法提取包名" >&2
  exit 3
fi
echo "$PACKAGE"
echo "----------"
echo "Native 库支持的 ABI："
NATIVE_DIRS=$(unzip -l "$APK" | grep -oP 'lib/([^/]+)/' | sort -u | sed 's|lib/||;s|/||')
if [[ -z "$NATIVE_DIRS" ]]; then
  echo "（无 Native 库）"
else
  echo "$NATIVE_DIRS"
fi
echo "----------"
echo "DEX 文件列表："
unzip -l "$APK" | grep 'classes.*\.dex' || {
  echo "未发现 DEX 文件" >&2
  exit 4
}
echo "----------"
echo "诊断完成：该 APK 为有效变体样本候选。"