解读

面试官问“签名验证绕过”，并不是想听你背“v1/v2/v3 签名流程”，而是考察：

1. 对 Android 安装器、PackageManager、系统守护进程（installd、vold）以及第三方 SDK 自检逻辑中“哪一步可能跳过签名校验”有具象认知；
2. 能否把攻击面拆成“系统级”与“应用级”，并给出国内真实场景（如加固、多渠道、热更新、插件化）的防御方案；
3. 是否具备“攻击者视角”——知道黑产在国内常用的 Xposed/Frida 脚本、Magisk 模块、重打包工具（NP 管理器、MT 管理器）如何插入 bypass 逻辑；
4. 最终能把防御动作落地到 CI/CD、运行时、合规上架三条线，形成闭环。

一句话：讲清“哪里能绕、怎么绕、怎么防”，并体现国内落地经验。

知识点

1. 签名机制演进：JAR 签名（v1）→ APK 签名方案 v2（整文件哈希）→ v3（轮替）→ v4（仅用于 ADB 快速部署）。
2. 系统校验路径：
   • PMS.installStage → PackageInstallerSession.commit → installd 的 cmd_install → verify_v2_signature()；
   • 若系统被 root 或 boot 镜像被修补，installd 可被重打包，直接返回 0。
3. 应用自检路径：JNI 层 getSignatureHash、Kotlin 层 packageManager.getPackageInfo().signingInfo、第三方加固壳的签名校验。
4. 典型绕过手法：
   • 系统级：hook installd、篡改 /system/etc/security/mac_permissions.xml、关闭 SELinux；
   • 应用级：逆向 so 后 patch 跳转指令、动态加载 Frida 脚本修改 compareHash、重打包后删除 META-INF 并在 AndroidManifest 插入 android:extractNativeLibs 混淆；
   • 国内特供：利用厂商“分身”或“平行空间”双开漏洞，让系统只校验第一个 APK，第二个 APK 用空签名。
5. 防御模型：CI 签名锁定 + 运行时多重校验 + 合规上架检测。
   • CI：私钥放 HSM，Gradle 使用 signingConfig.v2SigningEnabled true，关闭 v1 可选；
   • 运行时：JNI 层双校验（签名字段 + 公钥模 n 的硬编码 hash）、防 hook（ptrace 反调试 + /proc/self/maps 校验）、服务器二次验签；
   • 上架：国内商店使用“腾讯乐固/360 加固”强制 v2 校验，Google Play 开启 Play App Signing，拒绝任何 getSignature 返回空或异常渠道包。

答案

APK 签名验证绕过是指攻击者在不破坏系统完整性的前提下，让安装器或应用自身的签名校验逻辑“误以为”APK 来源可信，从而成功安装或运行被篡改的代码。国内常见两类场景：

1. 系统级绕过：通过 root 后替换 installd、刷入 Magisk 模块“Disable Signature Check”，使 PackageManagerService 在安装阶段直接返回 INSTALL_SUCCEEDED；
2. 应用级绕过：重打包后删除 META-INF，再用 NP 管理器插入空签名，随后利用 Frida 脚本 hook 应用自身 JNI 层的 signatureCompare 函数，强制返回匹配哈希。

开发者应建立“三层防护”：

1. 构建层：私钥写入专用 HSM，CI 脚本强制开启 v2+v3 签名，关闭 v1；同时用 R8 规则 keep 住验签 native 方法，防止被优化掉；
2. 运行时：在 JNI 层硬编码公钥模 256-bit 哈希，启动时通过 /proc/self/maps 检测 Xposed/Frida 模块，发现异常直接退出；对热更新插件采用与宿主相同签名，并在服务器下发前做二次签名校验；
3. 合规层：上架前使用国内商店提供的“签名指纹白名单”功能，拒绝任何指纹漂移包；Google Play 开启 Play App Signing，把私钥托管到 Google，彻底杜绝本地泄漏风险。

通过以上闭环，可在国内真实环境中把签名绕过概率降到商业级安全要求。

拓展思考

1. 折叠屏/多窗口场景下，系统可能通过“拆分 APK”方式安装，签名校验逻辑会走新的 SplitAssetLoader 路径；若你的应用支持动态功能模块，需确保 split 配置也强制 v2 签名，否则黑产可在传输环节替换 split apk。
2. 国内小程序容器（如微信、支付宝）允许网页端“拉端”启动本地 APK，此时容器会二次校验签名；但容器版本碎片化，旧版本只校验 md5，存在降级攻击。开发者应在 AndroidManifest 里声明 android:targetSandboxVersion="2"，强制系统拒绝旧容器调用。
3. 未来 AOSP 14 引入“APK 签名方案 v4 + 签名线（signature lineage）”与“终端身份密钥（Device Identity Credential）”绑定，可做到硬件级远程认证；提前在 NDK 层适配 KeyMint 2.0，能直接把验签逻辑下沉到 TEE，实现“即使系统被 root，签名仍不可绕过”的长期目标。