目录:

AL云爬虫风险管理（Anti-Bot Service，简称Anti-Bot）针对原生App端提供安全SDK解决方案。为App提供可信通信、防机器脚本滥刷等安全防护，有效识别高风险手机、猫池、牧场等特征。
App端安全SDK方案集成了AL集团多年来对抗黑灰产、羊毛党的经验和技术积累。只要App集成Anti-Bot安全SDK后，App将获得与天猫、淘宝、支付宝等App端相同的可信通信技术能力，并可共享AL集团多年对抗黑灰产、羊毛党所积累的恶意设备指纹库，从根本上解决App端的安全问题。

Anti-Bot提供的App端安全SDK方案解决以下原生App端的安全问题：
恶意注册、撞库、暴力破解
针对App的大流量CC攻击
短信/验证码接口被刷
薅羊毛、抢红包
恶意秒杀限时限购商品
恶意查票、刷票（例如，机票、酒店等场景）
价值资讯爬取（例如，价格、征信、融资、小说等内容）
机器批量投票
灌水、恶意评论

当成功接入防护后，可以在爬虫风险管理控制台进行SDK防护配置，通过具体的防护规则过滤恶意爬虫流量。如图1所示：

       图1

Anti-Bot SDK包含以下文件，图2所示：

       图2
SDK对外提供了两个接口：

主要分为两个接口，initialize和avmpSign接口对数据进行计算签名，再将签名与数据发送到服务器。服务器通过解析wToken进行风险识别、拦截恶意请求，然后将合法请求转发回源站。签名流程如图3所示：

       图3

主要通过动态计算函数调用地址方式反IDA F5使之失效，中间插入无效指令，基本模板如下：

每一个字符串常量都通过加密，使用时才解密，解密代码如下：

根据传入不同类型的参数走不同的解密算法，switch跳转到对应的加解密算法，这些算法是在VMP外的通用算法，只要跳出虚拟机做加解密都会执行到这个地方，我已经对每一个算法重命名，代码如下：

解密内存中图片得解密yw_1222_0335_mwua.jpg图片的密钥
invokeFuncBridgeLVMBridge->Aes_Dec_data->AlgorithmHelperDecompressData,AES解密解压,解密后内容如下：

打开图片文件fopen AirAsiaMobile.appp/yw_1222_0335_mwua.jpg
解析图片，定位到密文开始数据，部分数据如下：

上面解密出来的数据做为解密密钥前0x10字节，解密图片数据。

invokeFuncBridgeLVMBridge->Aes_Dec_data解密4次后得到数据,部分数据如下：

上面解密数据的AES解密算法

解压解密后数据，部分数据如下：

解压函数

解析解压后的数据定位到bycode，根据标记bc_sgcipher定位后面的为bycode，部分数据如下：

客户端向服务器端发送数据时，需要调用avmpSign接口对整个body数据进行签名处理，所得到的签名串就是wToken。进入VM前对输入参数进行处理，对输入参数进行异或加密，代码如下：

要签名的请求体数据

当参数准备好后将进入VM，代码如下：

该VM的Handle有70个左右，下面Handle表，有部分Handle己经根据功能命名了，如下：

VMP中再次异或加密input数据，基本流程如下：
Handle_44_getValue //取数据

Handle_52_EOR //异或加密

Handle_13_16_21_29_45_53_61_index //index++

Handle_9_CmpIndex //判断是否结束

循环0x2EB次后加密完成，部分数据如下：

其中Handle_2_2_CallFunc会调用外面函数获取手环境信息、设备信息与解密方法，代码如下：

外面函数检测越狱，主要检测是否有如下文件：

外面函数检测是否有自动化与改机类工具，主要检测是否有如下文件：

外面函数获取设备信息，获取电池、屏幕、IDFA、IDFV等:

获取完成后的设备信息如下：

异或加密设备信息:

加密后设备信息数据

对异或加密后的数据进行压缩，压缩函数同上，压缩后数据如下：

计算AES加密密钥
取值AirAsiaMobile.appp/yw_1222_0335_mwua.jpg中解密出来的值“f179ef3c-c43c-441b-b1a5-5f8bb6c9ef48”并计算md5。
AlgorithmHelperMd5Hex->AlgorithmHelperHexString->AlgorithmHelperHexStringExt
得到md5:b5f852c906a38b590f69190b935abdf6取md5字符串前16字节做为密钥“b5f852c906a38b59”。
AES加密后数据如下：

对AES加密后的数据进行Base64加密，算法为AlgorithmHelperBase64Encode，加密后数据如下：

将输入参数与加密后设备数据组合:

计算输入组合后数据的sha1值：

返回到VM中对SHA1值进行加密，APP调崩溃了，又重新来了一次，这次的SHA1值如下：

第一次加密分4个字节一组，总共5组，详细说下其中一组加密流程：

Handle_44_getValue //获取密文然后异或

Handle_0_LSL //逻辑左移0x18

Handle_24_AND_EOR //逻辑“异或” 00000000FFFFFFFF

重复上面Handle

Handle_8_EOR //逻辑异或

加密完成后得到的数据如下：

对加密后的值再次进行加密，循环0x100次，大致流程如下：

下面是加密中使用到的几个关键的Handle:

最终计算得到一串字符与设备信息加密后数据进行组合得到签名值，整个过程就算完成了，然后将签名值发送给服务器端检验：

由于时间原因，分析这个产品也是断断续续的进行，可能会存在很多没有分析清楚的地方，最后还是简单做一个总结，谈谈自己的一些简单看法，由于时间和水平有限，肯定会存在诸多不足，有不对的地方还请指正，下面谈谈我的看法：
优点：整体安全性比较高，在反IDA F5、逻辑混淆方面做得比较好，每个函数都贯穿始终，产品整体架构设计层次分明，从VMP初始化到VMP实际执行逻辑分层，有利于开发和维护。
从解密bycode到解释执行bycode都通过多层加密，我猜测是考虑到了性能原因，把大部分加解密操作放到了外部执行，把最后的sha1值放到VMP中进行加密处理，安全与性能取一个平衡点，不伤害用户体验的同时达到一定的安全性，毕竟像淘宝、支付宝这样的产品也有使用。
缺点：缺少一定的灵活性，比如bycode隐藏在图片中，当整个执行逻辑被成功分析清楚后难做即时补就措施，黑产特征在随时变化，本地的特征只要改下名字就可以过掉了。

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)