看雪编辑按：在移动互联网时代，互联网业务飞速发展，在这样的大背景下滋生了一条以刷单、倒卖、刷榜、引流、推广为主的灰色产业链。山寨APP遍地开花，给原APP的开发者带来了很大的冲击，这些人往往被称为“打包党”。他们以低成本换取了高额的利润，给互联网企业以及用户都带来了巨大的损失。虽然加固技术、风险控制、设备指纹、验证码等技术也都在飞速发展，但实际效果并不能让人满意。在本次峰会上，陈愉鑫揭露了多个真实案例的技术细节、开发流程、运营流程，描述了一条以刷单、倒卖、刷榜、引流、推广为主的灰色产业链。并提出一些防护建议，协议安全需要从体系上进行加强。

以下内容为陈愉鑫演讲实录，由看雪学院（微信公众号：ikanxue）整理。

陈愉鑫

陈愉鑫，看雪ID无名侠，自由Android安全研究员、看雪会员。热爱APP通信协议分析，曾经分析过各商城、直播软件协议流程并还原加密。对灰色产业链流程有研究。

大家好，我叫无名侠。今天很高兴能够在这里和大家相聚，这一次看雪的峰会办的特别好，我是2012年成为看雪的会员，这几年我在看雪也学了很多的知识，非常感谢看雪能够给我们提供这样的一个平台，我今天演讲的题目是移动APP灰色产业案例分析与防范。

羊毛党的 “工业革命”

大家玩过薅羊毛吗？我首先讲的是薅羊毛的工业革命。之所以叫它为什么工业革命，是因为我想讲薅羊毛怎么样从手工到脚本自动化完成。今天我会以小米商城、抢购软件做一个简单的例子，针对这些东西我会提出防范的建议。

羊毛党的工业革命。手动薅然后转换成自动化脚本，这一群人可以做什么？首先就是情报的搜集，要提前知道有那些活动，比如说今天发什么券他们都会提前知道，或者某一个什么APP有奖可以抽。羊毛党提前知道活动之后再找合伙人准备小号，准备小号就会批量注册，批量注册就涉及到注册协议的分析，现在这些APP里面都做了加密算法，这些加密算法有没有用，未知。也有很多加固，这些加固是否有效果，我们也未知。

注册小号之后就会准备VPS，vps越多请求量就越大。比如抽奖，用很多机器抽，肯定会比单人快。找技术人员，比如说分宜写法，解决算法脱掉破解，这些薅羊毛相当于做一个管理，管理下面的技术人员。活动上线之后，这个协议以及算法都生效了可以开始分析了，活动上线之后就要在第一时间内把这个东西做出来，所以上线之后就会找技术脱壳，找技术分析协议，直到出一个完整的软件出来。

安卓APP容易被反编译以及调试，大部分的算法都是用Java写的，反编译非常容易，还有一些非常核心的算法会放在SO里面，但是效果也不是很好。做这一块的技术人很多，会的人也很多，做起来特别方便。

在小米商城上有活动，比如说小米商城有一个板块叫做真心想要，这个板块里面就定期有非常低价商品出售的活动，这些活动一旦出来了，有一些人就会写脚本，买很多的服务器，同时开抢，抢到之后以稍微高的一点的价格转手出去。很多人从这个里面捞了很多钱。

首先我们来分析一下小米抢购软件的解决方案，要怎么样做一个抢购软件？我们要抢购东西首先要有一个API接口来源，小米应该有三个端，Web端，app以及盒子端。App又有Android 和IOS两个端，IOS分析成本比较高，安卓比较容易。

小米盒子的商城里面时候也有一些便宜的东西，盒子看着挺难分析的，实际上可以很容易把里面的算法、协议提取出来。小米盒子抓包可能有一些困难，因为小米盒子没有代理配置功能，但是小米也自己犯了一个坑，发包函数里面会把发的数据通过log输出，我们通过查看logcat日志，可以知道他发送了什么。

做抢购就需要大量的小号，这些小号需要注册脚本，就涉及到一个验证码的识别，这个解码平台很多验证码就可以识别。今天上午看到一个笑话，验证码需要你手机上的尾码乘以数字是多少，这种解码平台就无能为力了，感觉特别好，这是一个特别好的思路。

小米的登陆算法也挺复杂的，会涉及到很多的步骤包括设备信息绑定等等。登陆之后，我们还会涉及到一个批量设置收货地址，批量下单。这些东西的原理还是非常简单，模拟一下小米数据包，像爬虫一样。抓包不能完全防止，因为抓包禁止不了，服务端也不可能完全对这个客户端鉴权，所以只能提高协议难度。

最简单的方法是最每一个数据包里添加一个sign 字段，仅仅通过抓包我们是无法得知该sign字段的计算方法的。我们知道一点的是，这个字段必须输入正确才可以成功登陆一个账号，一般这种解决思路就是通过逆向APP寻找注册密钥，还原这个过程，把真正密码以及提交后的加密密码对应生成关系，生成之后又可以让服务器认可，服务器认可之后就可以登陆，这是一个基本的思路。

现在许多应用开发商为了图方便，于是就直接调用Java的Crypto算法库。直接调用这样的算法库会存在一个潜在的安全隐患，密钥是固定的，算法也是固定的。既然是Java的算法库，那么就可以通过Hook的方法输出密钥、加密数据等重要信息。即使一个APP已经加固甚至做过许多混淆也没有太大的用处。在这种情况下，逆向就显得太慢了！

千里之堤，毁于蚁穴

千里之提毁于蚁穴，有小部分APP选择使用加固产品，但是只使用了DEX加固功能，他们又将协议加密算法的代码放在SO里面，这样加固就没有起到太大的作用。

我们如何利用经过OLLVM编译的SO呢？ SO文件是已经编译的可执行文件，那么既然都叫可执行文件了，是否有手段可以让这些SO执行起来呢？有部分APP中的加密SO有x86版本，这就非常好办，直接load到内存，设置环境执行即可。

如果只有ARM版本的SO又该如何处理呢？我选择使用Unicorn 库模拟执行。Unicorn是一款基于Qemu模拟器内核的库，提供了许多方便的API接口。利用该库，我可以通过编程，完完全全虚拟出一颗ARM的处理器以及内存。

模拟执行成本就低了，而且使用Unicorn模拟执行还是线程安全的，非常适合羊毛党的业务需求。

模拟执行对抗方法也很简单，在核心的算法内增加上下文依赖，增加系统API调用，尽量避免纯运算函数。

如何增加安全强度？

其它的安全建议还有许多，例如修改标准算法也是不错的选择。

最简单的方法是修改Base64的映射表、替换字符等等。

再复杂一点就是修改Hash函数的初始化常量、增删算法部分逻辑等等，比较典型的是jd的tea算法。

自己实现VM也是一种不错的方案，自己实现VM有一个好处，可以根据自身APP的业务需求来设计。Bytecode可以灵活更新，甚至可以根据设备信息生成唯一加密算法。

最后，我建议核心点的协议采用一些二进制的序列化协议，这样能增加分析的难度。

谢谢。

附件为本演讲PPT

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！