为什么需要判断 APK 是否被二次打包
二次打包是指攻击者获取原始 APK 后，反编译、修改代码或资源，再重新签名并分发。常见动机包括植入广告、窃取账号、绕过付费，或把应用包装成“破解版”引流。对开发者和运营来说，二次打包不仅影响收入，还可能让用户把篡改版本的问题归咎于官方。因此，判断 APK 是否被二次打包，是应用安全的基础能力。
判断思路可以分成三层：签名校验、资源完整性校验、运行时检测。三层各有侧重，组合使用才能覆盖从静态到动态的篡改场景。
第一层：签名校验——最直接的入口
安卓系统要求每个 APK 必须签名，签名信息是判断 APK 是否被重新打包的第一道线索。二次打包者修改内容后必须重新签名，因此签名指纹通常会变化。
- 对比签名证书指纹：在构建流水线中记录原始 APK 的签名证书 SHA-256 指纹，分发或安装时读取实际 APK 的签名信息进行比对。如果指纹不一致，基本可以判定为二次打包。
- 检查签名方案：现代安卓支持 V1、V2、V3 等多种签名方案。二次打包工具可能只保留 V1 签名，或使用与原始应用不同的签名方案组合。可以检查 APK 的签名块是否完整。
- 注意签名校验的局限：如果攻击者获取了原始签名私钥（例如私钥泄露），他们可以重新签名并保持指纹一致。因此签名校验不能单独作为唯一依据。
在工程实践中，可以把签名校验放在应用启动早期，但不要只依赖客户端本地判断，因为本地判断本身也可能被绕过。更稳妥的做法是结合服务端下发的校验结果，或使用 应用加固与签名校验服务 来增加篡改成本。
第二层：资源完整性校验——覆盖静态篡改
二次打包往往伴随资源文件修改，例如替换图片、修改字符串、插入广告 SDK 的配置文件。资源完整性校验的目标是发现这些静态改动。
- 文件哈希清单：在构建时生成关键资源（如 dex、so、assets 下的配置文件）的哈希清单，运行时或安装后计算实际哈希并与清单比对。注意清单本身也要保护，避免被一并替换。
- APK 整体摘要：对 APK 文件计算摘要并记录，但 APK 在安装后会被系统优化，直接读取安装包可能不可行。可以改为校验安装后的关键文件。
- 资源与代码一致性：检查 AndroidManifest.xml 中的组件、权限是否与预期一致。二次打包者常添加新的权限或服务，这些异常可以作为线索。
资源完整性校验的难点在于误报和性能。建议只对核心资源做校验，并采用异步方式，避免拖慢启动。
第三层：运行时检测——发现动态篡改
有些二次打包会通过动态加载、Hook 或反射在运行时修改行为，静态校验可能无法覆盖。运行时检测关注应用运行过程中的异常。
- 检查调试与注入：检测是否处于调试状态、是否存在常见的 Hook 框架（如 Xposed、Frida）痕迹。这类环境常被用于分析或篡改应用。
- 校验关键代码段：在运行时对关键方法的字节码或内存中的代码段做校验，发现被替换或修改的迹象。
- 行为一致性：监控应用是否发起了非预期的网络请求、是否加载了非官方渠道的广告 SDK。这些行为异常往往指向二次打包版本。
运行时检测需要平衡用户体验和误报率。过于激进的检测可能导致正常用户被误判，建议结合服务端风控，对可疑行为做二次确认。
三层校验如何组合落地
单独任何一层都不够。推荐的做法是：
- 构建阶段生成签名指纹和资源哈希清单，并安全存储。
- 应用启动时做签名校验和关键资源校验，结果上报服务端。
- 运行过程中做轻量级运行时检测，发现异常时由服务端决定是否限制功能或提示用户。
- 定期更新校验策略，避免攻击者摸清固定规则。
对于需要更高防护等级的应用，可以结合 APK 加固与完整性保护，把校验逻辑本身也保护起来。但要注意，加固不是万能的，合理的校验层次和持续运营才是关键。
总结
判断 APK 是否被二次打包，不能只看一个点。签名校验能快速发现重新签名，资源完整性校验能覆盖静态篡改，运行时检测能捕捉动态行为。三层结合，并配合服务端风控，才能有效识别和应对二次打包风险。