一、前言
最近有一个同学，发给我一个设备流量访问检测工具，但是奇怪的是，他从GP上下载下来之后安装就没有数据了，而在GP上直接安装就可以。二次打包也会有问题。所以这里就可以判断这个app应该是有签名校验了，当然还有其他的校验逻辑，我们打开这个app界面如下，没有任何数据：
二、应用分析
下面就来简单分析这个app，不多说直接使用Jadx工具打开：
我们在使用的过程中会发现需要授权VPN权限，所以就断定这个app利用了系统的VPNService功能开发的，直接在xml中找到入口，然后进入查看配置代码：
继续跟踪查看内部逻辑：
在Worker类中，看到有一些核心的Native方法，开发过VPNService都知道，拦截数据等操作一般都会放到native去做，主要原因是性能会高点。不多说直接使用IDA打开libwebd.so文件，直接搜索NativeInit函数，为什么搜索这个函数呢？因为一看这个是初始化操作，而没有数据的话那些校验判断只会在这里，所以直接看这个函数实现：
继续往下看，他到底做了哪些验证，这里主要包括了三处验证，具体如下：
第一处验证：验证安装渠道是否为GP，这里利用了系统的getInstallerPackageName方法来做判断，这个方法在很早的Android版本就有了，但是这个方法有很大使用问题，后面会介绍。因为GP安装器包名是：com.android.vending,这里直接判断如果安装器不是GP就不进行拦包操作了。
第二处验证：应用签名校验，这个已经是最普遍的校验方法了，这里不多解释了，直接使用kstools工具进行爆破即可破解签名校验。
第三处验证：这个主要验证xml中的android:debuggable=”true”这个属性值，我们之前如果想调试这个app的话，一般都会手动反编译改这个属性为true的。但是我们现在不需要调试，也没必要进行修改。这个验证对于我们来说没什么影响。
看到上面的三处验证，其实对于我们现在掌握的技术来说，都不难，特别是签名校验，完全可以使用kstools工具来搞定，一键化操作，不了解kstools工具的同学可以看这篇文章：Android中自动爆破签名校验工具kstools;这里同学自己使用工具操作一下即可过了这个验证。而第三处验证可以说没什么影响，不用管它。主要来看第一处验证。有的同学说破解也简单，直接修改CBZ指令即可。但是这个就缺失了一些技巧，我们要的不是结果，而是学习的过程。接下来看看我是怎么破解这个校验的。又要多介绍一些知识点了。
三、破解方案
破解这个安装渠道大致有两个方案，一个是利用kstools工具源码修改一下，拦截getInstallerPackageName方法，然后修改返回值即可，如下：
直接返回这个包名的的安装器就是GP的，这样在打包就可以给多人使用了。这个不多介绍了，感兴趣的同学去下载源码自己操作实践一下即可：https://github.com/fourbrother/kstools
还有一种超级简单的方式，直接使用命令 pm install -i[指定安装器包名] apk文件，这个命令应该又很少人知道，但是这个简单的一个命令就可以在这里很方便的破解，可以指定一个app的安装器。
我们安装之后，可以在系统的 /data/system/packages.xml 中查看应用对应的安装器名称：
而这里又说道一个知识，就是系统的这个packages.xml文件，他就是设备安装成功的应用的一些详细信息，包括使用到的权限，签名信息，安装渠道，各种标志等。之前有人问怎么获取设备中的应用安装渠道来源，其实可以从这个文件中获取到。从这里看到这个应用现在的确是从GP上安装的了，也说明了上面的那个pm命令的确有效。
这时候我们再看看应用的拦截是否有效果了：
看到了，这里开始拦截设备的数据包了，从这里看这款app的确很有用，对于我们开发来说，也算是一个很好的工具了，破解之后可以珍藏使用了。
对于第一种方式破解是最好的，因为那样可以给多个人使用，而对于第二种命令指定安装器的安装方式，一般小白用户肯定不知道。对于第一种方式破解只需要修改kstools源码即可。
四、总结
好了到这里我们就破解成功了，可以愉快的使用这个app了，但是从上面来看了解到了新的防护策略就是判断应用是否来自于指定应用市场。有的同学可能立马想到了，为了防止二次打包，可以在应用中判断是否来自于主流的应用市场渠道，如果不是就不走正确的逻辑了，这个也算是一个防护策略了，不过可惜的是这个想法是不可行的，如果可行就有很多app早这么干了。原因是因为这个系统方法：getInstallerPackageName，大家可以自己测试这个方法，会发现：如果一个app是系统应用，那么这个返回值可能是设备自带的应用市场。如果一个app是第三方应用，从GP上安装，这个值一定是com.android.vending；而如果是其他渠道，比如国内的应用包，手机助手，豌豆荚等。就有可能是null值，而是用pm这样的命令，或者系统自带的安装器安装的第三方应用也有可能是null值，也就是说：这个系统api返回的应用安装器名称极不稳定，完全就是不靠谱的方法，至少在国内没法使用的。所以几乎可以忽略这个方法的。但是为何这个app敢这么干呢?其实我也很好奇。不过有一点可以说明就是这个app开发商就认定了此app只在GP上发布，其他渠道都不发布，这样只认定GP上下载的app才算是合法的。比如一个国外用户，用了华为手机使用非GP渠道下载了这个app，那么可惜这个人也是不能使用的。我也很好奇这个app的开发商为何要这么做？反正国内的app应该都不会这么做的。因为这个方法的返回值极不稳定。
但是不能说这个方法不靠谱，我们在后面的逆向就要忽略这个防护，后面我们在破解app依然遵从不变法则：全局搜索signature字符串来判断是否有签名校验，全局搜索getInstallerPackageName方法是否有安全渠道验证。不管是在IDA还是Jadx中搜索，都是如此。