一、前言

之前已经介绍了一款自动爆破应用签名工具kstools，不了解的同学还可以去看这篇文章：Android中自动爆破应用签名工具kstools;有了这个工具，就不用在担心签名校验了，不过在发布工具之后，很多热心的同学都很好奇就进行了尝试，有成功的，也有失败的，而在失败中最多的问题就在于应用本身签名爆破已经没问题了，但是在第三方登录的时候就失效了，对于这个问题，不光是这个工具会带来问题，主要是二次打包应用都会有这个问题，那么今天就来分析一下如何解决二次打包带来的登录失效问题。

二、社交登录SDK功能说明

首先我们要知道一件事，就是现在大部分的应用都采用了第三方登录SDK，也就是网上的ShareSDK功能包，这个功能包，其实很简单，就是把多家登录平台合成一起，就是聚合登录SDK功能：

因为我们要解决这个登录问题，所以得先去简单的看一下这个聚合登录SDK源码实现，这个不难，直接下载jar包工程，使用也非常简单：

下载下来之后，目录下有一个QuickIntegrater.jar工具，可以直接运行，然后填写具体的包名和项目名称，之后就会生成对应的集成素材，这里主要包括两部分，一部分是原始多家社交平台的jar包：

一部分就是配置信息文件ShareSDK.xml文件：

这个配置文件是关键核心，就是包含了多家平台的社交信息，而这些信息必须应用自己去各家平台上申请获取信息，这里举个QQ社交平台申请资料：

这里提交应用之后，会有一个appid和appkey这两个值，然后再把这两个值配置到自己的ShareSDK.xml中即可。所以这个聚合SDK其实没做啥事情。

三、问题跟踪

了解了上面聚合SDK功能之后，下面不多说了，直接看爆破app的源码，因为这个聚合SDK的包名是cn.sharesdk.x：

这里我们看一下WX登录失效问题，直接看社交登录源码，(有的同学好奇，我怎么一下就找到这个关键代码了，这个是有方法的，如果WX这种登录失效，在客户端只能依靠应用的签名信息来做判断依据，所以只要在这个包下面搜字符串”signature”，就找到了)：

这里看到了：会判断手机中安装的WX签名是否正确，如果失败了，就会登录失效，因为WX的签名信息不可能变动的，所以这里就直接写死判断了。那么这里就发现了第一个问题了：因为我们之前用kstools工具爆破的时候是hook应用的PMS服务，拦截获取签名信息方法，然后返回爆破app正确的签名，那么现在这里因为是获取WX的签名，但是也被我们拦截了，返回的是应用的签名，这明显就有问题了，所以我们解决这个问题需要修改一下爆破工具，修改很简单，在拦截签名信息加一个包名判断，只拦截本应用的签名信息：

这个工具我修改了，已经更新到github上了，有问题的同学可以下载最新的在进行操作就可以了。

四、授权失败问题分析

那么到这里就介绍了，之前kstools工具的一个漏洞，无差别的拦截了，导致WX也被干了，需要做一层过滤，只需要拦截爆破app本身的签名即可。不过可惜的是，解决了这个问题，在登录还是有问题，比如下面是授权Q登录问题：

这个问题修复其实才是我们本文的重点，也是网上很多同学二次打包之后遇到的问题，那么下面就来详细分析这个问题导致的原因，如何进行修复。

在修复这个问题之前，我们先猜想一下，Q是如何判断应用被二次签名拒绝授权了，还是那句话，在客户端，只能依赖于签名校验信息做判断依据，那么就不科学了，因为app我们已经爆破成功了，理论上应该授权是成功的，可以骗过Q的，但是结果不是这样的。所以猜想：应用授权的时候给Q带过去哪些信息，从现象来看，应该不是应用签名了，不过应用的包名是肯定有的，还有appid，为什么了？因为之前说了如果想用Q社交登录功能，必须得去他后台提交应用获取对应的appid和appkey，而这时候上传app，TX后台已经记录了应用的签名信息，也就是在后台有包名+appid+签名信息对应关系了。所以app在授权登录带过去的肯定有appid信息和包名，然后Q在携带这些信息去服务端进行验证。所以获取应用签名信息肯定是Q端做的。

有了上面的猜想，下面可以进行验证了，首先找到入口，直接使用adb shell dumpsys activity top找到授权页面：

然后借助Jadx工具打开Q应用，这里再次强调一次：TX家的app都很庞大，比如WX,Q等都是多dex文件的，所以直接打开apk会卡死的，一般activity类都是在主dex中的，所以可以解压apk得到classes.dex直接打开就好了：

看到代码之后，心终于宽敞了，就和我们的猜想一模一样，Q端得到传递过来的授权app包名，然后获取其签名信息，然后就开始进行网络请求授权：

这里用的是post方式，我们把data中的数据放到json格式工具中：

看到了，这里会上传包名，appid，已经签名信息，那么这里肯定会授权失败了，因为在Q代码中通过包名获取签名信息肯定是二次打包之后的，因为我们拦截签名信息只是在应用内，不是系统全局的哦。

五、问题修复

到这里我们了解了Q授权登录的大致流程了：需要授权app会携带自己在Q后端申请的appid，包名去Q端进行授权，然后Q端拿到包名之后，就获取手机中安装应用的签名信息，然后去服务端进行授权验证。因为我们二次打包签名应用了，所以授权肯定是失败的，所以Q提示非官方应用。了解流程之后，解决也是有很多种方法了，主要涉及两点：

第一点：如果本地不做任何操作，可以把二次打包之后的应用从新提交到Q后台获取新的appid和appkey，然后替换他的ShareSDK.xml中的配置信息即可，但是这种成功率几乎为0，以为Q后台有强大的查重机制，会被检查到的，提示app重复。

第二点：第一点其实说的是理论知识，实际中几乎行不通的，那么就需要在本地进行操作了，这里有两个方法处理：

1》借助Xposed进行系统拦截获取签名信息方法，通过判断获取签名信息的包名来做一次过滤。这样可以骗过Q，也可以骗过应用本身了。

2》因为Xposed需要的额外条件太多，不方便使用，所以这里还可以修改Q中的那段授权代码中获取签名信息，直接替换成需要授权app正确的签名信息。

这里为了给大家介绍更多的逆向知识，就采用第二种了，因为第一种现在谁都会了，第二种需要改Q代码，回编译Q有些问题正好给大家说明一下，下面就来操作一下。首先第一步，我们到构造出Q获取签名信息的算法，这个简单，直接把那部分代码拷贝出来就好了：

把这段代码已经HexUtil.a方法也考出来如下：

然后手机中安装正版的授权app，在运行这段代码，获取到正版授权app的签名信息：

这样，就拿到了，正确签名。然后在去修改Q代码，在修改Q代码有个问题，就是因为TX家的App都做了回编译混淆操作，所以这里不能借助apktools进行反编译修改器smali代码了，而需要用另外一种方式，直接解压出他的dex文件，然后操作即可。这里不多介绍流程，后面会单独出一个系列文章介绍如何进行回编译操作。把这个正确的签名信息在赋值给签名变量，修改之后如下：

然后在把这个dex替换回去，重新签名，安装Q之后，可惜的时候运行报错：

提示appid无效，不过这个问题已经对于我们来说不是问题了，因为我们有了kstools工具了，使用最新的kstools工具直接爆破即可。

这下就可以愉快的，进行Q登录授权了：

看到了，这里可以正常的Q授权登录了，到这里我们就介绍完了如何解决二次打包登录授权问题了，下面就来总结一下问题原因和具体操作。

本文主要讲解了Q端登录授权问题解决方案，但是其他平台原理都是类似，比如WX平台，可以找到授权页面，然后跟踪代码即可，感兴趣的同学可以自己研究解决了！

六、问题和解决方案总结

1、因为之前的kstools进行拦截app内部获取签名的方法，没有做应用包名区分，所以把登录的时候判断社交APP的签名也给拦截了，导致登录授权失败，这个问题直接修复了kstools工具，已经更新到github上，可下载最新的就好了。

2、正常二次打包签名登录授权统一报错信息，Q端提示非正版app，这个是因为在授权app去Q端进行授权的时候会携带自身的appid和包名，然后Q端会在本地通过包名获取其签名信息，然后去服务端进行验证，所以这里解决方法很多，可以借助Xposed直接hook系统的获取签名方法，还有就是修改Q端代码替换正确的app签名信息，当然第二种方式不需要借助Xposed，限制条件虽然少了，但是操作局限性很大，需要重新安装Q，而且只能对授权一个app有效，如果其他app需要授权，还得继续修改Q端代码。

3、关于TX家族的app对回编译都做了很多混淆策略，所以我们得用其他方式二次打包，具体方案会在后续给出一个系列介绍文章，详细介绍如何操作，敬请期待。

说明：关于kstools工具出来之后，很多公司做了新的防护策略，其实这里有一个新的防护策略很简单，就是读取META-INF目录下的RSA文件中的签名信息，这样可以直接校验，而不是通过系统的那个方法获取签名信息，这样二次打包之后，这个RSA文件签名肯定会发生变化的，所以这个就是一个可以抗衡kstools工具的好方案哦。所以说安全和逆向永不停息，安全不息，逆向不止！

kstools工具下载地址：https://github.com/fourbrother/kstools

严重声明：本文主要利用一个样本案例介绍了，如何修复二次打包之后授权登录失败问题修复方案，如果有人利用本文案例或者技术进行非法商业操作，带来的一切法律责任将由操作者本人负责，与文章作者无关，最后还是由衷的希望各位同学能够秉着学习逆向知识的态度阅读文本，非常感谢！