Android逆向之旅—分析某手机厂商的应用市场的请求协议(应用刷单产业介绍)

一、前言

今天我们来分析一下某手机厂商的自带应用市场的请求协议信息，因为这个是一个非常大的需求，我们都知道当年小米手机宣称我们赔钱也要给用户做最好的手机，其实我们都知道现在做手机很难赚钱，除了苹果那样的高利润手机了。那么这些手机厂商不可能真的天天赔钱供养用户呀，那他们是怎么赚钱的，其实网上有一个说法就是赔硬件的钱赚软件的钱，没错因为手机厂商中自带很多软件，靠的就是软件赚钱，特别是应用市场，因为第三方应用如果想让自己的应用上榜高下载量，那么就得找手机厂商买很好的广告位，特别现在我们看到很多手机厂商都有很好的推广位置，比如搜索栏提示，Banner和Top区域等：

这里看到是这手机的应用市场的首页，看到搜索栏的终结者，Top区都是头条系的产品，所以看出来头条的运营和推广真的很厉害，想不火都难。然后二级搜索页面会看到热门搜索内容这些都是可以售卖的位置，而且价格不菲，那么应用多了，想不赚钱都难。这个我们会想到微博的买热搜一说，淘宝就有卖的。

但是问题来了，手机厂商的位置费用太贵了，有的应用不愿意出这笔费用，所以就滋生了一个产业叫做刷榜，这个前几年非常好弄，也很赚钱。但是最近就呵呵了，所以我也敢写这篇文章了，因为刷榜行业不是这么容易做了，主要是厂商的算法和唯一性检查了。不过本文还是技术热爱分析逆向技术，因为出不起这个价格，但是也想上榜怎么办呢？其实搜索排行榜主要还是靠很多用户搜索同一个内容然后后台统计排名的，那么机会就来了，现在如果我们可以批量的机器操作搜索指定关键字，那么这个关键字就会出现在最热的地方，就等于上榜了。那么怎么机器操作了，这个就需要分析协议，因为搜索说白了就是一个携带关键字去请求而已，那么我们有了这个协议，构造参数；批量请求即可。这个就是传说中的协议刷单。这种方式的好处就在于批量操作简单，缺点是需要花点时间分析协议信息。

这里再说一点就是我们可以看到虽然我们可以批量刷了，而且刷很多一定能上Top One嘛？其实不然，因为厂商不可能这么傻，毕竟他是靠这个东西赚钱，所以他们会在后台改算法，把前三名的位置预留给自己，也就说你怎么刷可能永远都上不了前三，只有找厂商花钱买，这就是后门。不过能上榜就不错了，上不上Top不重要，如果你觉得重要那就请去找厂商给钱即可。因为这个产业出来，刷单的价格和直接找厂商的价格比低很多。所以有很多应用就会找这样的产业人合作。前几年这些操作很赚钱的。那么本文就来介绍协议刷单的原理，在文末还会介绍其他刷单方式。

二、逆向分析

不多说了，我们直接分析协议把，这里直接搜索一个应用，用Charles抓包查看信息：

这里看到请求接口是http，但是请求参数和返回结果貌似直接看不到数据，可能是压缩或者加密了，这个就需要分析代码了，所以我们需要把手机中的应用市场app导出来，应用存放目录：/system/priv-app/ 下面；然后我们就用Jadx打开应用搜索这个请求接口信息即可：

然后点进去查看内容：

看到这里有一个全局的Map结构用于存储链接，我们右键看看这个Map变量在哪用到，可惜没有地方，这时候我们就要用到一个搜索技巧了，因为是全局的Map结构，那么用到的地方肯定是这样的样式：c.get(Integer*；那么我在全局这么搜索：

看到了吧，这样就搜索了到了，所以这些小技巧大家都要记住，慢慢就成为一个有经验的人了。然后我们看到一个带有日志信息的那一段比较可疑，直接点击进入：

这里看到了应该是一个网络请求，而且会设置很多头部信息等，当然返回结果也会做处理了，代码就不截图了。重要的是这里我们看到了很多日志信息，之前我就说过，遇到这种情况为了更快的定位代码位置，我们可以hook日志方法，把应用中的日志都打印出来即可：

运行模块，打印日志即可：

看到日志信息了，真的很全，对于我们分析太有用了，看到请求的参数了，所以这里看到我们在开发应用的时候如果在代码中保留日志信息是多不安全，及时用开关来控制也是不行的，所以我们可以在编出release包的时候把日志代码全部删除，这个其实很简单，在项目的混淆文件proguard-project.txt中添加一行代码即可：

-assumosideeffects class android.util.Log{
public static *** d(…);
}

这个就是删除android.util.Log.d方法调用的那一行代码。这样apk中就没有任何日志信息了，同样的最好不要封装一层日志类，因为我们可以hook这个类通过打印参数来看信息，就像上面一样，看他就是封装了一层日志类：

所以我们在开发应用的时候，就是用系统日志类，然后代码在混淆的时候删除即可，或者封装了一层之后，也要把这个类添加混淆让apk包中看不到这个日志类代码即可。继续分析上面的打印日志：

我们看到有一个请求参数格式，这里用xml方法包装了参数信息，我们通过里面的<keyword>关键字搜索：

搜索结果不是很多，我们依次排除，最后定位到这里的我们想要的参数封装信息了，但是我们搜索发现这个方法竟然没有调用，然后我们在返回去看看那个打印日志是这行代码：

按照上面打印的日志顺序应该是这行代码打印的结果，我们查看这个方法：

神奇的发现这个方法竟然是空的，我第一感觉是这个重要的方法难道是指令代码被抽取了？因为这个技术我在之前说过，不了解的同学可以看这里：Android中指令抽取方式加固应用；但是就是因为我想的太复杂了，导致走了很多弯路，我又跑去分析他的so以及dump内存信息，结果发现都没有；等了几天，对没错这里我每天都在想到底为什么？突然有一天我又来到了熟悉的小树林突发奇想得到了答案就是一个方法为空还有可能是他是父类肯定有个子类重写了这个方法，所以就查看这个子类就是上面我们全局搜索的那个<keyword>类：

这样就对上了，为什么这个a方法没有调用，而上面的那个方法确实空代码，其实真正调用的是这个子类。这个坑就当经验教训了，以后又学习到了，就是如果发现一个方法是空或者没有调用到那么肯定存在继承关系重写方法了。然后我们继续往下看这些参数是怎么获取的：

这里有一个开发尝试就是如果要上传参数字节流信息，肯定是getOutputStream方法写入参数字节流信息即可，如果是获取返回的信息字节流就是getInputStream；然后看看字节流定义：

然后看到这个b方法依然是空的：

当然这里我们知道为什么了，还是子类重写了，去子类看看即可：

然后这里就是构造参数的地方，最重要的地方就是这里了：

这里看到核心的地方了就是他的加密协议了，其实内部是把google的protobuf库封装了一层而已。

三、如何产出结果

到这里我们就弄清楚了协议请求参数加密信息了。那么其实到这里我们就可以做了，因为我们有Xposed，所以我们只需要在这里进行修改即可：

拦截这里的设置keyword搜索关键字方法替换成我们想要刷的应用名字，然后在批量调用外部的请求方法即可。这里我就不演示了，编写模块代码很简单，但是这有个问题就是我们需要对设备进行root操作，可能对于批量操作有点限制。所以这里我们继续往下看把这个协议弄出来，写个应用单独刷，这里就需要有耐心的把应用的那些封装类拷贝出来了，这里没难度但是一定要有耐心：

这里我就弄出来了，然后构造参数访问即可：

这里启动五个线程刷10次爱奇艺关键字，当然可以自行定义线程数和搜索次数，运行看看刷的效果：

因为搜索爱奇艺关键字也会返回很多相关内容，所以会有很多返回类似应用信息。

四、刷单产业情况

那么到这里我们就分析完了某手机应用市场的请求协议信息，其实回头看没什么难度的，就是他自己定义了一套数据加密而已，但是这个加密放在Java层，虽然代码很多，但是我们可以拷贝出来即可，只要你有足够的耐心，那么接下来继续说一下刷榜的问题，虽然我们有了协议分析，可以随意传入关键字了，但是有一个问题就是参数中的重要信息IMEI，关于IMEI的东西很多人会认为这是标识手机的唯一性的，那么我们如果把IMEI写死或者只有一个那么服务端肯定能识别出来了，那有的同学说了直接伪造，这个是早几年干的事情了，现在肯定不行了，因为现在的手机厂商在每部手机出厂之前会把IMEI入库的，如果你伪造的IMEI不在数据库中，那么也是会被发现的，那么这个就没办法了吗？答案是否定的，因为我们知道早起很多应用喜欢收集用户收集的IMEI信息，比如某一个用户量巨大的应用他肯定有几个亿的设备信息，当然我们相信这些公司有责任有义务的保护这些数据不被外泄，但是谁知道不泄露了，还有早几年这种数据交易也很多，比如现在最恶心的就是电话号码，你买了一样东西，第二天就有各种相关的销售电话给你了，你能相信你的电话信息没有被出卖吗？反正我不信。所以现在想弄到大批量的IMEI信息还是有办法的，虽然我没办法。

有了一批IMEI信息之后，那么就可以刷量了，真的这么简单吗？有的同学快疯了，怎么还是不行呢？我都有了手机正确的IMEI信息还不行吗？因为现在应用市场后台做了很多校验算法，而这些算法不是简单的就是借助一个IMEI数据进行操作的，我曾经咨询了一个应用市场的算法同学，他们的检查算法的参数平均有50多个。包括上层，底层，物理层等参数信息。所以现在知道为什么我写这篇文章了，因为写了就是让大家知道这个产业以及逆向技巧，但是可以告诉你如果用这篇文章去操作，百分百告诉你不会成功的。要是成功的话我能写文章吗？我不是找干嘛？我是个本本分分的人！

刚刚在之前提到了除了协议刷单还有其他方式刷单，这里就简单说一下其他方式，其实原理很简单，不做任何破解操作，就是正常的操作，我们可以利用辅助功能模拟点击进行操作，购买一批设备然后写个辅助功能脚本安装跑即可。这个是不是超级简单呢？的确简单，但是简单就有简单的坏处这种方式的操作成本很大，因为需要适配每个机型，除非你采购的是同一批的机型系统一样的设备，不然不一样的设备就得写一套脚本。维护成本和采购费用成本很大的。当然还有其他方式刷单，这里不方便继续说了，感兴趣的同学可以加入编码美丽小密圈继续讨论，以及本文设计的代码都去小密圈中获取：

本文涉及到的代码项目可以去编码美丽小密圈自取，欢迎加入小密圈一起学习探讨技术