📚 课程目录第3章 APK签名校验的常见方式

3. APK签名校验的常见方式：代码检查、JNI检查、运行时验证

提到签名校验，很多人的第一反应是「在 Java 代码里调一下 PackageManager 拿签名对比」。嗯，确实有这做法。但真正上过生产环境的同学都知道——纯 Java 层的校验，一捅就破。

我个人习惯把签名校验分成三个层级：代码层、JNI 层、运行时层。每一层的对抗难度指数级上升，但相应的，开发成本也在涨。今天咱们就逐个聊透。

3.1 代码检查 —— 最常见的做法，也是最容易绕过的

说白了，就是在 Java 或 Kotlin 代码里直接读取 APK 的签名信息，然后跟硬编码的值做比对。我早期做过的一个电商 App 就用的这种方案——当时觉得挺好的，直到被一个实习生反编译两小时就给干掉了。

典型写法长这样：

public boolean checkSignature(Context context) {
    try {
        PackageInfo info = context.getPackageManager().getPackageInfo(
                context.getPackageName(),
                PackageManager.GET_SIGNATURES);
        // 取出签名哈希，跟预置值比较
        Signature[] sigs = info.signatures;
        String localSig = calcSignatureHash(sigs[0].toByteArray());
        return CUSTOM_SIGN_HASH.equals(localSig);
    } catch (Exception e) {
        return false;
    }
}

你们觉得这个代码问题在哪？对，PackageManager.GET_SIGNATURES 这个 API 完全暴露给了调用方。攻击者只要用 Xposed 或者 Frida hook 一下 getPackageInfo，返回假签名，校验就形同虚设。

⚠️ 注意：从 Android 9（API 28）开始，PackageManager.GET_SIGNATURES 已被标记为 deprecated，推荐改用 PackageManager.GET_SIGNING_CERTIFICATES。但即便换了新 API，只要还是在 Java 层校验，hook 的难度几乎没有增加。

我曾经在某家金融 SDK 里看到过一段代码，它把签名哈希拆分存到了 5 个不同的 SharedPreferences key 里，然后运行时再拼回去对比。说实话，这想法值得点赞，但可惜——攻击者直接 hook SharedPreferences.getString() 就能全部拿到。嗯，这里要注意：不要相信任何 Java 层的输入，包括系统服务返回的数据，因为 hook 框架可以拦截任何 Java 方法。

3.2 JNI 检查 —— 把战场拉到 Native 层

既然 Java 层不安全，那就把校验逻辑放到 .so 里面。JNI 检查的核心思路是：在 C/C++ 代码里调用 JNI 函数获取签名，然后做对比。为什么这么做？因为 Native 代码的 hook 门槛比 Java 层高得多。你想想看，攻击者得先过掉反调试，还得定位到 .so 里的校验函数。

我个人的推荐做法是这样的：

// native-lib.cpp
extern "C" JNIEXPORT jboolean JNICALL
Java_com_example_SigChecker_nativeCheck(JNIEnv* env, jobject thiz, jobject context) {
    // 获取 jclass 和 jmethodID
    jclass contextClass = env->GetObjectClass(context);
    jmethodID getPackageManager = env->GetMethodID(contextClass, "getPackageManager",
                                                   "()Landroid/content/pm/PackageManager;");
    jobject pm = env->CallObjectMethod(context, getPackageManager);

    // 获取包名
    jmethodID getPackageName = env->GetMethodID(contextClass, "getPackageName",
                                                 "()Ljava/lang/String;");
    jstring pkgName = (jstring)env->CallObjectMethod(context, getPackageName);
    const char* pkgStr = env->GetStringUTFChars(pkgName, nullptr);

    // 拿到 PackageInfo
    jclass pmClass = env->GetObjectClass(pm);
    jmethodID getPackageInfo = env->GetMethodID(pmClass, "getPackageInfo",
                                                 "(Ljava/lang/String;I)Landroid/content/pm/PackageInfo;");
    jobject pkgInfo = env->CallObjectMethod(pm, getPackageInfo, pkgName, 64); // 64 = GET_SIGNATURES
    // ... 后续签名哈希计算和对比，全部在 Native 完成
    env->ReleaseStringUTFChars(pkgName, pkgStr);
    return JNI_TRUE;
}

在这里我故意不把签名哈希硬编码在 Java 层，而是放在 .so 的数据段或者用算法动态生成。你问为什么？因为硬编码在 .so 里虽然藏得深了一点，但攻击者用 readelf 或者十六进制编辑器就能找到。我建议的做法是：签名哈希通过某种变换存储在 .so 里，运行时再还原。比如把哈希拆成 4 段，每段异或一个随机种子，或者用简单的加法混淆。这不是密码学级别的保护，但能让攻击者多花 3 倍以上的时间。

💡 技巧：在 JNI 校验里加一个「反调试」小陷阱。比如在 ptrace(PTRACE_TRACEME, 0, 0, 0) 后，如果返回 -1 表示已经在被调试状态，直接返回 false。这个手法能拦截掉很多初阶逆向工具直接 Attach 的行为。

我以前给一个游戏做安全防护时，把 JNI 校验函数藏在了 .init_array 段里，让它在 so 加载时就自动执行。攻击者如果只是简单地 hook JNI 接口，根本不会触发校验——因为那时候 so 还没加载完，hook 还没生效。嗯，这是个很实用的“时间差”技巧。

3.3 运行时验证 —— 动态防御，让攻击者防不胜防

前面两种方式都是「静态校验」——只在 App 启动时检查一次。但攻击者完全可以在校验通过后，用 Frida 把返回结果冻住，然后继续搞事情。运行时验证，说白了就是把校验变成持续的行为，而不是一锤子买卖。

我整理了几种常用的运行时验证策略，你们看看：

策略类型	实现思路	优缺点
定时校验	每隔 N 秒（随机间隔）重新检查签名	增加攻击者持续 Hook 的难度；可能影响性能
随机触发	在用户点击、网络请求等正常事件中混入校验	难以定位校验点；需要改造业务代码
完整性校验	校验自身 APK 文件或 dex/so 的哈希	能发现文件被篡改；但要避免被读取到原始哈希
网络验证	将签名上报服务端，服务端校验后再下发指令	安全等级最高；但需要联网，且服务端要做反篡改

这里我特别想提一下「完整性校验」的坑。很多同学会直接用 MessageDigest 计算 APK 文件哈希——但你想过没有，这个哈希值存哪？如果存本地，攻击者改 APK 的同时也会改掉这个哈希。我曾经见过一个方案：把原始哈希拆成多份，分别藏在 .so 的不同段、assets 文件夹、甚至 AndroidManifest 的 meta-data 里。然后运行时取出来还原对比。这样攻击者至少得翻遍整个 APK 才能找到所有碎片。

  📌 实战建议：三种方式组合使用。我常用的组合是——代码检查做第一道防线（轻松拦截 80% 的菜鸟攻击），JNI 做核心校验（抗住中级逆向），运行时验证做最后一道保障（反高级 hook 和内存修改）。三层全过，基本能防住 95% 以上的破解尝试。

避坑指南

不要只依赖系统签名 API 的返回值——它太容易被 hook 了。我建议在 Native 层自己计算一次签名哈希，而不是直接信任 Java 层传来的签名对象。
别把签名校验放在 Application.onCreate()——很多攻击者会直接替换 Application 类，绕过整个初始化流程。更好的时机是放在第一个 Activity 的 onCreate 中，或者更晚。
运行时验证别搞太频繁——每秒校验一次会严重卡顿。我习惯设成 30 秒一次，加上随机偏移 ±10 秒，既能保证安全又不影响体验。
网络验证要防重放攻击——如果你用服务端验证签名，务必加上时间戳和一次性随机数（nonce），否则攻击者抓包重放请求就能骗过服务器。

嗯，这三种方式讲完了。总结一句话：签名校验不是一道锁，而是一整套防御体系。别指望单一的校验能挡住专业攻击，但组合拳打出来，足够劝退 99% 的破解者了。