为什么需要判断 APK 是否被二次打包
二次打包是指攻击者反编译原始 APK，插入恶意代码、广告 SDK 或修改资源后重新签名分发。这类篡改包不仅威胁用户数据安全，也会损害开发者声誉。判断 APK 是否被二次打包，不能只靠单一手段，而应从签名、资源、运行时三个层次建立校验链条。
第一层：签名校验——最直接的入口
Android 要求所有 APK 必须签名，二次打包后签名必然改变。因此校验签名是识别篡改的第一道关卡。
- 比对签名证书指纹：在代码中读取当前应用的签名信息（如通过 PackageManager 获取签名证书的 SHA-256 指纹），与官方发布的指纹比对。不一致则说明 APK 被重新签名。
- 检查签名方案：Android 7.0 及以上支持 APK Signature Scheme v2/v3，二次打包工具可能只保留 v1 签名。校验签名方案版本可作为辅助判断。
- 注意签名校验的绕过风险：攻击者可能通过 Hook 或修改代码绕过校验，因此签名校验需要结合其他层次，并适当混淆校验逻辑。
签名校验实现简单、成本低，适合作为基础防线。但需注意，部分渠道会要求重新签名（如部分应用市场），此时应使用渠道包专用校验策略。
第二层：资源完整性校验——发现文件篡改
二次打包常伴随资源文件替换（如图片、布局、配置文件）或 Dex 文件修改。资源完整性校验通过比对关键文件的哈希值来发现篡改。
- 计算关键文件哈希：在构建时生成资源文件（如 assets 下的配置文件、so 库、dex 文件）的哈希清单，运行时重新计算并比对。哈希清单本身需要加密或混淆存储，防止被篡改。
- 校验 Dex 文件完整性：Dex 文件是代码载体，二次打包常修改 Dex。可校验 Dex 的 CRC32 或 SHA-1 值，但需注意加固或热修复可能改变 Dex，需与正常发布流程兼容。
- 检查资源文件结构：例如 AndroidManifest.xml 中的组件声明是否被添加，resources.arsc 是否被修改。可通过解析二进制 XML 与预期值比对。
资源完整性校验能发现更隐蔽的篡改，但计算开销较大，建议对关键文件抽样校验，或采用增量校验策略。
第三层：运行时检测——动态环境下的对抗
签名和资源校验属于静态检查，攻击者可通过动态 Hook 绕过。运行时检测从行为和环境层面发现异常。
- 检测调试与 Hook 框架：检查是否被调试（如 Debug.isDebuggerConnected()）、是否存在 Xposed/Frida 等 Hook 框架的痕迹（如检测特定类加载、端口、进程名）。
- 校验运行时内存完整性：对关键代码段或 Dex 在内存中的映射进行校验，发现内存补丁。实现难度较高，需结合 Native 层。
- 监控异常行为：如应用启动后出现非预期的网络请求、权限申请或组件调用，可结合日志上报进行风控分析。
运行时检测对抗性强，但可能影响性能或误报，建议在关键业务场景（如支付、登录）启用，并建立灰度机制。
三层校验的配合与落地建议
单一层次的校验都容易被针对性绕过，建议采用分层策略：签名校验作为快速筛查，资源完整性校验作为深度检查，运行时检测作为动态兜底。同时，校验逻辑本身应进行混淆和加固，避免被轻易定位。对于需要进一步加固的应用，可参考站内的APK 加固服务，了解完整性校验与防篡改的集成方案。
在实际运营中，还应建立签名指纹和哈希清单的版本管理，确保每次发版更新校验基准。若发现二次打包样本，及时通过渠道投诉和下架流程处理，并更新检测规则。
小结
判断 APK 是否被二次打包，需要从签名、资源、运行时三个层次构建校验体系。签名校验快速直接，资源校验发现文件篡改，运行时检测对抗动态绕过。三者结合，才能有效提升应用防篡改能力。更多关于完整性校验的实践，可查看相关服务说明。