一、前言

之前已经写了一个爆破签名校验的工具kstools，很多同学也在使用，但是也反馈了不少问题，之前一篇文章也介绍了，关于爆破之后第三方登录问题修复，这篇我们在综合说明一下一些后遗症问题，关于kstools工具说明以及工具的原理，可以看这篇文章说明：Android中自动爆破签名工具kstools说明。

二、样本分析

下面开始进入正题吧，关于有些同学反馈，使用该kstools爆破某app之后，出现无限制重启问题，关于这个问题，我没见过，很好奇就是尝试了这个样本案例：

看到了，的确是这样的，无限制重启。我们使用Jadx打开使用kstools处理过的样本看看hook是否成功：

这里可以看到，我们hook是成功的，所以应该不是hook的问题导致的，所以这里就需要借助开发经验了：记住如果在破解过程中发现应用重启或者闪退的时候，要第一时间想起来是否程序内部做了异常捕获，然后自己做了一些操作导致这样的结果。

本文案例就是这个原因导致的，所以我们得先把应用自己捕获全局异常功能给关闭，这样会出现系统崩溃异常信息，这样定位问题就简单了，对于Android中全局捕获异常有一个特征就是这行代码：

Thread.setDefaultUncaughtExceptionHandler(this);

所以我们在Jadx中全局所有字符串即可：

这里看到了，他的确有这些代码，然后我们直接在反编译之后的smali代码中找到这些地方，注释这行代码即可，然后在回编译安装运行，果然崩溃了，看崩溃日志信息：

是这个app内部用到了ormlite框架来操作数据库的，具体信息就是Class类型不能转化成String类型，我们通过这个堆栈信息跟踪最后找到了出错的地方：

这是个注解，看到这里doClass是Class类型，但是默认值却是String类型，所以报错了，但是这个为什么会这样呢？我们用原始样本看看：

这个才是正确的，所以我们猜想这个可能和kstools工具操作有关，因为kstools工具的操作步骤是：

解压apk=>获取dex=>转化成jar(插入hook代码)=>转化成dex=>塞入apk=>签名apk

而这个过程中，特别是在dex转化成jar，然后在转化成dex，应该是这个过程导致这个问题。所以这里为了解决这个问题，我们还得按照这个工具的原始手动操作一下，不了解的同学可以看这篇文章：Android中爆破签名校验新姿势，这样操作时候，会发现这个注解不会有问题了，而且签名也爆破成功了，运行正常了。

三、问题说明总结

到这里，本文内容就介绍完了，其实就是想说明一个问题也是破解过程中的一个经验值：在应用二次签名跑的时候发现闪退或者重启，也没有什么错误信息的时候，要想到可能是应用本身做了捕获全局异常的功能导致，所以只需要把这块功能注释即可看到详细的错误信息，然后在定位解决问题即可。

当然通过这个样本我们也发现了kstools这个工具的弊端，这个也有同学说了就是操作过于复杂，其实没必要将dex转化成jar然后在转成dex的，耗时而且最大的问题在于可能在转化过程中出错，操作多的同学会发现有时候在dex转化成jar或者是jar转化成dex会出现一些错误信息。导致后面无法进行了。这个是工具的最大弊端。所以继续优化这个工具，已经更新到github上了，直接将dex转化成smali，然后进行操作即可，这样的好处是原始的在Android基础上进行操作了，不会带来一些爆破后遗症了，比如本文案例用这种方式肯定就不会有问题了。

四、疑问解答

在很多同学使用这个工具或者用这种思想去爆破，提出这个问题就是如果将签名验证放到程序最开始入口，然后放到native层，这样就会爆破失败了，这里我再说明一下，就是这个爆破的思想是hook程序的pms服务，然后拦截获取签名信息的方法，而加入hook的代码已经是最开始的入口了，一般是attachBaseContext方法了，那么及时你在native层最开始入口，比如是JNI_ONLoad函数中也是无效的。有的同学又说了？那可以把加载so放到程序的入口Application的静态代码块中，这样时机是最早的了，其实想一想这样的确是最早，但是能在这里校验签名吗？要知道校验签名可能得用应用的context变量获取信息，你在静态代码块中是无法拿到这个变量的，及时你在native层也是一样，所以在静态代码块中提前load本地代码是不行的。比如这个样本案例，校验就在JNI_OnLoad函数中：

这里就是先获取全局的context变量，然后再去进行签名校验功能，这里有一个AppRuntime日志tag，我们可以打印我们爆破成功的日志：

看到这信息，说明已经骗过签名校验功能了，而这样做是不是非常的方便了，没必要再去分析代码找到签名校验的地方了，所以这个工具还是很有用的，准确的说是这个爆破思想非常有用。

最后还想在说明两点：

第一、有的同学说，这个工具对于加壳的app没用，就意义不大了，首先说明并非所有的应用都会加固，特别是大型应用，因为加固有分享，他们未必采用加固，其次是，现在有很多应用不仅加固了，还做了签名校验，所以如果你脱壳成功还可以借助这个工具进行操作了。

第二、通过最近同学给我反馈的使用意见和问题，这里就总结一下使用流程：

1、首先你的样本案例如果是加固的，那么请你先脱壳，脱壳之后在使用kstools工具，具体用法有说明。

2、如果对于一些非加固的应用在使用的过程中可能会出现爆破失败，比如kstools工具使用报错，签名校验爆破失效，程序闪退重启等问题，那么可能和kstools工具有关，所以这时候可能要手动的去添加hook代码了，这个我在前面的文章中也提到了操作流程了。最后如果还是不行，那么可以把样本发给我，我帮忙查看。

关于手动添加hook代码步骤这里在说一下大致流程：

首先去github/fourbrother/HookPmsSignature下载最新的hook代码，自己编译得到一个apk之后，反编译得到对应的smali代码，然后将其拷贝到需要破解的apk反编译源码目录下，然后在爆破app入口类添加hook代码调用，可以参见HookPmsSignature中的MyApplication/MyActivity类中的调用方式。注意hookPMS方法中的签名和包名需要改成你想要破解app的对应信息，关于应用入口可以在XML清单文件中查看，如果有Application类，直接在代码类中的方法attachBaseContext或者onCreate方法添加，如果没有就找到入口的Activity类，在其onCreate方法中添加即可。