Android应用安全解决方案

前言

    防止第三方反编译篡改应用，防止数据隐私泄露，防止二次打包欺骗用户。

1、一些必要的基础知识

我们在加密的时候会用到一些加密或者编码方法。常见的有，非对称加密算法 RSA 等；对称加密算法 DES、3DES 和 AES 等；不可逆的加密 MD5、SHA256 等。

另外，我们会把重要的加密逻辑放到 Native 层来实现，所以一些 JNI 编程的方法也是需要的。不过，如果仅仅是用来作加密的话，对 C/C++ 的要求是没那么高的。对在 Android 中使用 JNI，可以参考我之前的文章《在 Android 中使用 JNI 的总结》。

2、签名校验

2.1 基础签名校验

在应用和 so 中作签名校验可以说是最基本的安全策略。在应用中作签名校验可以防止应用被二次打包。因为如果别人修改你的代码，肯定要重新打包，此时签名必然会改变。对 so 作签名校验是很有必要的，除了防止应用被打包，也可以防止你的 so 被别人盗用。

可以使用如下的代码在 java 中进行签名校验，

private static String getAppSignatureHash(final String packageName, final String algorithm) {
    if (StringUtils.isSpace(packageName)) return "";
    Signature[] signature = getAppSignature(packageName);
    if (signature == null || signature.length <= 0) return "";
    return StringUtils.bytes2HexString(EncryptUtils.hashTemplate(signature[0].toByteArray(), algorithm))
            .replaceAll("(?<=[0-9A-F]{2})[0-9A-F]{2}", ":$0");
}

对于在 Native 层作签名校验，将上述方法翻译成对应的 JNI 调用即可，这里就不赘述了。

上面是签名校验的逻辑，看似美好，实际上稍微碰到有点破解的经验的就顶不住了。我之前遇到的一种破解上述签名校验的方法是，在自定义 Application 的 onCreate() 方法中读取 APK 的签名并存储到全局变量中，然后 Hook 获取应用签名的方法，并把上述读取到的真实的签名信息返回，以此绕过签名校验逻辑。

2.2 Application 类型校验

针对上述这种破解方式，我想到的第一个方法是对当前应用的 Application 类型作校验。因为他们加载 Hook 的逻辑是在自定义的 Application 中完成的，如果他们的 Application 和我们自己的 Application 类路径不一致，那么可以认定应用为破解版。

不过，这种方式作用也有限。我当时采用这种策略是考虑到有的破解者可能就是用一个脚本破解所有应用，所以改动一下可以防止这类破解者。但是，后来我也遇到一些“狠人”。因为我的软件用了 360 加固，所以如果加固壳工程的 Application 也认为是合法的。于是，我就看到了有的破解者在我的加固包之上又做了一层加固…

2.3 另一种签名校验方法

上述签名校验容易被 Hook 绕过，我们还可以采用另一种签名校验方法。

记得之前在《使用 APT 开发组件化框架的若干细节问题》 这篇文章中提到过，ARouter 在加载 APT 生成的路由信息的时候，一种方式是获取软件的 APK，然后从 APK 的 dex 中获取指定包名下的类文件。那么，我们是不是也可以借鉴这种方式来直接对 APK 进行签名校验呢？

首先，你可以采用下面的方法获取软件的 APK，

ApplicationInfo applicationInfo = context.getPackageManager().getApplicationInfo(context.getPackageName(), 0);
File sourceApk = new File(applicationInfo.sourceDir);

获取 APK 签名信息的方法比较多，这里我提供的是 Android 源码中的打包文件的签名代码，代码位置是：

https://android.googlesource.com/p