加固就了安全了？几个措施让你的 Android 应用更加安全
1、背景
最近新开发了一款工具类型的软件，然而某天下午忽然群里来了一个不速之客说我的软件被破解了。虽然，该软件无需付费并且没有广告（很良心 :) ），也进行了安全加固，但是还是很轻易得被别人破解了。现象是，启动页换成了别人的页面，需要用户点击页面上的按钮分享几次破解者的信息才能进入应用。并且，每次打开应用都是如此。
看到这我的心情还是非常复杂的。一开始觉得自己做个应用都赚不到钱，还要被这些人利用。本是同根生，相煎何太急呀。然而，转念一想，这里有些东西还是可以学习一下，于是我去他们的链接下载了软件，本着学习的精神进行了一波分析并制定了几个方案来加强应用安全。
2、分析
2.1 检查破解应用签名
决定要进行分析之后，我首先想到的就是去检查下应用的签名，这里使用 keytool 即可，指令如下:
1 | keytool -printcert -jarfile 你的apk地址 |
获取的结果如下，
很显然，应用的签名已经发生了变化，应用被别人二次打包了。实际上，我的应用是在 360 上面进行了软件加固（免费版），但是还是如此轻松地被别人完成了二次打包。
2.2 签名校验
如果仅仅是签名发生了变化，那么解决方式倒也简单。在应用内部增加一个签名校验就可以了。不过签名校验也有需要注意的地方。其一，签名校验可以放在 Java 层来完成，也可以放在 native 层通过 C++ 来完成。其二，在应用内部进行整个数字签名的校验还是部分校验。这是因为如果写入完整的数字签名很容易被别人发现，即便写入到 so 中，写入完整字符串比部分更容易被别人找到。
在 Java 中，你可以按照下面这种方式获取应用的数字签名。我已经把相关的方法写成了工具类，你可以在 Github 上面获取 AppUtils：
1 | public static String getAppSignatureMD5(final String packageName) { |
如果是使用 C++ 进行签名校验可以使用下面的方法，
1 | jbyteArray getSignatureByteArray(JNIEnv *env, jobject context, jstring algorithm) { |
这里使用的是 CMake 进行编译，使用 Android Studio 进行开发。上面的逻辑很简单，就是把之前的 java 层获取签名的方法照搬到了 native 方法里。而且，借助于 Android Studio 进行开发，可以帮助我们减轻很多工作量，比如方法的映射关系就不需要你一个一个得进行对比，可以通过提示直接完成转换。当然，上面只是使用 java 的类完成了获取签名的字节数组的逻辑，进一步转换成为 hash 字符串还要进行其他操作。这里就不把代码贴出来了。
因为除了进行这些签名校验我还加了其他的安全措施，所以这部分代码不便开源。不过，我已经把一些基础功能的代码和环境配置打包成了压缩文件，你可以到我公众号里回复【安卓签名校验】获取完整的代码。
拿到了签名之后当然是进行签名校验了，基本的字符串比较即可。当然，你可以进行部分匹配，这样增加了破解的难度。
2.3 签名校验就安全了？
增加了上述的签名校验只不过是第一步，也是比较常规的安全操作。但是这样操作未必就能防止其他用户破解。进一步进行反编译，我又发现一些新的东西。破解包的目录结构挺有意思的，
相比于没有破解的包，在 lib 下面多了两个文件，这里的 libarm.so 的内容尚不清楚，这里的 libhook.apk 是一个 apk 文件，并且签名跟我的原始的包的签名一致，但是 apk 内容并不是我的完整包。所以，我猜测这里的 Apk 文件有其他用途，并且仅仅使用签名校验并不安全。因为别人可以读取你的应用的签名，然后通过某种方式进行伪造，让获取签名的方法返回的结果不是安装包真实的签名而是你的真实包的签名。这里的 apk 很有可能就是用来获取签名的。
于是，我进一步对应用进行资源反编译，这里使用 apktool 来完成，这里如下：
1 | apktool d 破解应用.apk |
于是我发现启动应用是被篡改掉了的，这里的启动应用已经被修改为 arm.SignerPro，并且这里的启动类已经被修改为 SplashActivity：
然后，我们将 Apk 解压之后对 dex 文件进行反编译。这里使用的是 d2j-dex2jar 来完成。命令如下，
1 | d2j-dex2jar classes.dex |
然后，我们根据反编译的结果，查看启动 Application，
这里的 Application 继承了 InvocationHandler. InvocationHandler 相比大家都不陌生，Retrofit 就是通过在 InvocationHandler 实现的代理来解析请求参数，并根据注解和入参来完成 OkHttp 请求的。我们找到该接口的实现方法 invoke(). 从上图中很明显得可以看出，我们的 getPackageInfo() 方法有很大可能被别人 hook 了。这个方法就是上面说的用来获取应用签名的方法，这里会对 getPackageInfo() 方法进行处理，并返回 signs 作为签名的获取结果而不是应用真实的签名结果。
当然，上面都是猜着，因为他们也只破解了第一个版本的包，第二个版本的包我加了新的安全措施，并且悄悄地增加了几个隐藏的页面用来在应用内获取签名和其他的信息来验证我的想法。
不管怎么说，仅仅加上签名校验很可能是不安全的！
2.4 其他安全措施
其实即便他们 hook 了获取签名的 getPackageInfo() 方法我们仍然有许多措施来应对。他们这里的 hook 有几个地方可以入手，
首先，我们并没看到 signs 的赋值操作，我猜测是通过 native 方法来完成的赋值，他们如果每次都尝试返回 signs 的话并没有屡次对 signs 进行重新赋值。而从 PackageManager 中多次读取到的 Signature 对象应该是不同的。所以，如果我们多次读取签名的时候返回的同一对象，是不是可以认为该方法被别人 hook 了呢？
另外，这里 hook 了
getPackageInfo()方法。只是我们无法判断他们 hook 的范围，我们可以尝试自定义一个getPackageInfo()方法，然后自定义返回的对象类型，如果返回的不是我们指定的类型，就可以得出结论，我们的getPackageInfo()方法被别人 hook 了。比如，1
2
3
4
5
6
7
8
9
10
11
12
13
14public class Fake {
public void getPackageInfo() { }
public FakePackageInfo getPackageInfo( String packageName, int flags) throws PackageManager.NameNotFoundException {
return new FakePackageInfo();
}
public FakePackageInfo getPackageInfo( VersionedPackage versionedPackage, int flags) throws PackageManager.NameNotFoundException {
return new FakePackageInfo();
}
public static class FakePackageInfo { }
}当然，如果他们只 hook 了 PackageManager 的方法，这个就不适用了。
除了签名校验，我们还可以检查其他项。比如检查 Application 是否是我们的启动 Application，可以使用如下代码获取应用的 Application 并进行比较，
1
2
3
4
5
6
7
8
9
10
11public static String getApplicationName(final String pkgName) {
if (StringUtils.isSpace(pkgName)) return null;
try {
PackageManager pm = UtilsApp.getApp().getPackageManager();
ApplicationInfo ai = pm.getApplicationInfo(pkgName, 0);
return ai == null ? null : ai.className;
} catch (PackageManager.NameNotFoundException e) {
e.printStackTrace();
return null;
}
}此外，我们还可以对应用的启动 Activity 进行校验。因为他们对我们的应用的启动 Activity 进行了修改，于是我们启动 Activity 进行了修改，所以这也可以作为一个应对措施：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20public static String getAppLauncher(final String pkgName) {
if (StringUtils.isSpace(pkgName)) return null;
try {
PackageManager pm = UtilsApp.getApp().getPackageManager();
PackageInfo pi = pm.getPackageInfo(pkgName, 0);
if (pi == null) return null;
Intent resolveIntent = new Intent(Intent.ACTION_MAIN, null);
resolveIntent.addCategory(Intent.CATEGORY_LAUNCHER);
resolveIntent.setPackage(pi.packageName);
List<ResolveInfo> resolveInfoList = pm.queryIntentActivities(resolveIntent, 0);
ResolveInfo resolveInfo = resolveInfoList.iterator().next();
if (resolveInfo != null) {
return resolveInfo.activityInfo.name;
}
return null;
} catch (PackageManager.NameNotFoundException e) {
e.printStackTrace();
return null;
}
}上面提到的也只是一部分方法，当然还有其他的可以操作的方法。我们也可以在对类似的破解事件进行多分析来总结，尝试从多个维度做好安全防护。
3、总结
上面是我在应对破解方面的一些简单的总结，除了进行常规的加固之外，还进行了其他的维度的校验。当然，我其实对逆向和破解的了解并不是那么深入，这里权当抛砖引玉了。
上文中提到的反编译工具，如果需要的话可以到我的工号里回复【安卓反编译工具】领取。这里提到的移动工具箱呢是我最近开发的一款工具软件，除了一些常用的工具之外，内部还包含了 18 种基于 OpenCV 的图像处理，部分代码我也丢到了 Github 上面。此外，还包含了两个 Github 爬虫工具用来帮助开发者更好地使用 Github，以及常见的字符串加密、文件加密和时间戳工具等，希望能够对你有帮助。
上述就是这次分享的内容，感谢阅读♥
