0x00 概述
针对大麦网部分演唱会门票仅能在app渠道抢票的问题，本文研究了APK的抢票接口并编写了抢票工具。本文介绍的顺序为环境搭建、抓包、trace分析、接口参数获取、rpc调用实现，以及最终的功能实现。通过阅读本文，你将学到反抓包技术破解、Frida hook、jadx apk逆向技术，并能对淘系APP的运行逻辑有所了解。本文仅用于学习交流，严禁用于非法用途。
关键词： frida, 大麦网, Android逆向
先放成功截图：
0x01 缘起
疫情结束的2023年5月，大家对出去玩都有点疯狂，歌手们也扎堆开演唱会。演唱会虽多，票却一点也不好抢，抢五月天的门票难度不亚于买五一的高铁票。所以想尝试找一些脚本来辅助抢票，之前经常用selenium和request做一些小爬虫来搞定自动化的工作，所以在 MakiNaruto/Automatic_ticket_purchase 的基础上改了改，实现抢票功能。但是大麦网实在太狡猾了，改完爬虫才发现几乎所有的热门演唱会只允许在app购买，所以就需要利用APP实现接口自动化。
本着能省事则省事的原则，笔者在文章 [Android] 基于Airtest实现大麦网app自动抢票程序 中用自动化测试技术实现了抢票程序，但是速度太慢，几乎不能用。果然捷径往往不好走，因此继续尝试分析大麦网apk的api接口。
0x02 环境
0x03 环境搭建
bluestacks 环境搭建
目前Android模拟器竞品很多，选择Bluestacks 5是因为它能和windows的hyper-v完美兼容，root过程也相对简单。
首先需要root Bluestacks环境。
[ol]
下载安装Bluestacks。
运行Bluestacks Multi-instance Manager，发现默认安装的版本为Android Pie 64bit版本，即Android 9.0。此时退出bluestack所有程序。
关闭bluestack后编辑bluestacks配置文件， %programdata%\BlueStacks_nxt\bluestacks.conf
> 由于作者安装时C盘空间不足，真实的bluestacks.conf在D:\BlueStacks_nxt\bluestacks.conf，大家也根据实际情况调整
在配置文件中查找root关键词，对应值修改为1，共两处。
bst.feature.rooting="1"
bst.instance.Pie64.enable_root_access="1"
启动bluestack模拟器，安装 Root Checker APP，点击验证root，即可发现root已成功。
[/ol]
上述 root 过程主要参考了 https://appuals.com/root-bluestacks/ ，部分地方做了改正，在此感谢原文作者。
打开 adb调试
[ol]
bluestack设置-高级中打开Adb调试，并记录下端口
打开主机命令行，运行 adb connect localhost:6652，端口号修改为上一步的端口号，即可连接。再运行adb devices，如有对应设备则连接成功。
进入adb shell，执行su进入root权限，命令行标识由$变为#，即表示adb 进入root权限成功。
[/ol]
frida环境搭建
frida是大名鼎鼎的动态分析的hook神器，用它可以直接访问修改二进制的内存、函数和对象，非常方便。它对于Android的支持也是很完美。
frida的运行采用C/S架构，客户端为电脑端的开发环境，服务器端为Android，均需对应部署搭建。
客户端环境搭建(Windows)
firda客户端基于python3开发，因此首先需要配置好python3的运行环境，然后执行 pip install frida-tools即可完成安装。运行 frida --version可验证frida版本。
(py3) PS E:\TEMP\damai> frida --version
16.0.19
服务器 环境搭建(Android)
环境搭建第二步是在Android模拟器中运行frida-server。这样可以让Frida通过ADB/USB调试与我们的Android模拟器连接。
[ol]
下载frida-server
最新的frida-server可以从 https://github.com/frida/frida/releases 下载。请注意下载与设备匹配的架构。如果您的模拟器是x86_64，请下载相应版本的frida-server。本文使用的版本为 frida-server-16.0.18-android-x86_64.xz
传入Android模拟器。
将下载后的.xz文件解压，将frida-server传入Android模拟器
adb push frida-server /data/local/tmp/
运行 frida-server
使用adb root以root模式重新启动ADB，并通过adb shell重新进入shell的访问。进入shell后，进入我们放置frida-server的目录并为其授予执行权限：
cd /data/local/tmp/
chmod +x frida-server
执行：./frida-server，运行frida-server，并保持本shell窗口开启。
成功截图：
有些情况下，应用程序会检测在是否在模拟器中运行，但对于大麦网app的分析暂无影响。
测试是否连接成功
在window端运行frida-ps命令：
看到一堆熟悉的Android进程，我们就连接成功啦
转发frida-server端口 (可选)
frida-server跑在Android端，frida需要通过连接frida-server。上一步使用adb的方式连接，frida认为是USB模式，需要-U命令。frida也支持依赖端口的远程连接模式，在某些场景下更加灵活。可以通过端口转发的方式实现此功能。
adb forward tcp:27042 tcp:27042
adb forward tcp:27043 tcp:27043
27042是用于与frida-server通信的默认端口号,之后的每个端口对应每个注入的进程，检查27042端口可检测 Frida 是否存在。
本部分主要参考了 https://learnfrida.info/java/ ， 在此感谢原文作者。
[/ol]
0x04 抓包
抓包及https解密方法
本章节将介绍用tcpdump+frida+wireshark实现Android的全流量抓包，能实现https解密。
惯用的Android抓包手段是用fiddler/burpsuite/mitmproxy搭建代{过}{滤}理服务器，设置Android代{过}{滤}理服务器并用中间人劫持的方式获取http协议流量的内容。如需对https流量解密，还需要在安卓上安装https根证书。Android9.0以后的版本对用户自定义根证书有了一些限制，抓包不再那么简单，但这难不倒技术大神们，大家可以可以参考以下几篇文章：
上述的抓包方式只能抓到http协议层以上的流量，这次我们来点不一样的，用tcpdump+frida+wireshark实现Android的全流量抓包，能实现https解密。
1. 搞定tcpdump
本文基于termux安装使用tcpdump。
首先安装termux apk。
打开termux运行：
挂载存储
termux-setup-storage
## 会弹出授权框，点允许
ls ~/storage/
## 如果出现dcim, downloads等目录，即表示成功
pkg install root-repo
pkg install sudo tcpdump
运行抓包
sudo tcpdump -i any -s 0 -w ~/storage/downloads/capture.pcap
之后就可以把downloads目录下的抓包文件拷贝到电脑上，用wireshark打开做进一步分析。
2. 解密https流量
Wireshark解密https流量的方法和原理介绍有很多，可参考以下文章，本文不再赘述。
wireshark解密技术的重点在于拿到客户端通信的密钥日志文件(ssl key log)，像下面这种：
在Android中实现抓取ssl key log需要hook系统的SSL相关函数，可以用frida实现。
// sslkeyfilelog.js
function startTLSKeyLogger(SSL_CTX_new, SSL_CTX_set_keylog_callback) {
console.log("start----")
function keyLogger(ssl, line) {
console.log(new NativePointer(line).readCString());
}
const keyLogCallback = new NativeCallback(keyLogger, 'void', ['pointer', 'pointer']);
Interceptor.attach(SSL_CTX_new, {
onLeave: function(retval) {
const ssl = new NativePointer(retval);
const SSL_CTX_set_keylog_callbackFn = new NativeFunction(SSL_CTX_set_keylog_callback, 'void', ['pointer', 'pointer']);
SSL_CTX_set_keylog_callbackFn(ssl, keyLogCallback);
}
});
}
startTLSKeyLogger(
Module.findExportByName('libssl.so', 'SSL_CTX_new'),
Module.findExportByName('libssl.so', 'SSL_CTX_set_keylog_callback')
)
然后用frida加载运行hook
frida -U -l .\sslkeyfilelog.js -f cn.damai
最后，抓包结束后将得到的key保存到sslkey.txt，格式是下面这样的，不要掺杂别的。
CLIENT_RANDOM 557e6dc49faec93dddd41d8c55d3a0084c44031f14d66f68e3b7fb53d3f9586d 886de4677511305bfeaee5ffb072652cbfba626af1465d09dc1f29103fd947c997f6f28962189ee809944887413d8a20
CLIENT_RANDOM e66fb5d6735f0b803426fa88c3692e8b9a1f4dca37956187b22de11f1797e875 65a07797c144ecc86026a44bbc85b5c57873218ce5684dc22d4d4ee9b754eb1961a0789e2086601f5b0441c35d76c448
在运行Frida Hook获取sslkey的同时，运行tcpdump抓包。抓包中依次测试获取详情页、选择价位、提交订单等操作，并对应记录下执行操作的时间，方便后续分析。
抓包完成后，用wireshark打开tcpdump抓包获得的pcap文件，在wireshark首选项-protocols-TLS中，设置 (Pre)-Master-Secret log filename为上述sslkey.txt。
即可实现https流量的解密。
本部分主要参考了 https://www.52pojie.cn/thread-1405917-1-1.html ，向原作者表示感谢
流量分析
在上述步骤中拿到了解密后的流量，我们就能对大麦网的流量做进一步分析了。
大麦网的API流
在此铺垫一下，通过前期对大麦网PC端和移动端H5的分析，大麦网购票的工作流程大概为：
[ol]
[/ol]
apk流量分析
首先用过滤器http && tcp.dstport==443，得到向服务器发送的https包，如下图：
可以看到大量向服务器请求的数据包，但其中有很多干扰的图片请求，因为修改过滤器把图片过滤一下。过滤器：http && tcp.dstport==443 and !(http.request.uri contains ".webp" or http.request.uri contains ".jpg" or http.request.uri contains ".png")
结果清爽了很多。
订单构建(order.build)
根据之前记录的操作的时间，以及对网页版的分析结果，笔者注意到了下图的这条流量：
然后我们右键选择这条流量包，点击追踪http流，可以看到对应的响应包。
响应包里有些中文使用了UTF-8编码，可以点击右下角的Show data as，选择UTF-8，便可以正常显示。此时可以点击另存为，保存为txt文件，方便后续分析。
订单构建的请求包中核心的数据部分为图中青色圈出来的部分，使用URL解码后为：
{"buyNow":"true","buyParam":"716435462268_2_5005943905715","exParams":"{\"atomSplit\":\"1\",\"channel\":\"damai_app\",\"coVersion\":\"2.0\",\"coupon\":\"true\",\"seatInfo\":\"\",\"umpChannel\":\"10001\",\"websiteLanguage\":\"zh_CN_#Hans\"}"}
buyParam为最核心的部分，拼接方式为演出id+数量+票档id。其他部分只需照抄。
请求包中还包含大量的各种加密参数、ID，而破解实现自动购票脚本的关键就在于如何通过代码的方式拿到这些加密参数。
订单构建的响应包为订单提交表单的各项参数，用于生成“确认订单”的表单。
订单提交(order.create)
按照同样的方式可以找到订单提交包，订单提交包的API路径为/gw/mtop.trade.order.create，
其中青色圈出来的部分为data发送的核心数据，对数据用URL解码后为：
{"feature":"{\"gzip\":\"true\"}","params":"H4sIAAAAAAA.................AAWk3NKAAA\n"}
看起来像是把原始数据用gzip压缩后又使用了base64编码，尝试解码：
import base64
import gzip
import json
# 解码后变为python dict
decode_data=base64.b64decode(params_str.replace("\\n",""))
decompressed_data=gzip.decompress(decode_data).decode("utf-8")
params=json.loads(decompressed_data)
with open("reverse\order.create-params.json","w") as f:
json.dump(params,f,indent=2)
解码成功，存到order.create-params.json,
解码后发现order.create发送的data参数和order.build请求返回的结果很相似，增加了一些用户对表单操作的记录。
order.create请求的header中的各种加密参数和order.build一致。
order.create请求的返回结果中包含了订单创建是否成功的结果以及支付链接。
0x05 trace分析
通过前面对流量的分析，我们已经知道客户端向服务器发送的核心数据和加密参数，核心数据的拼接相对简单，但加密参数怎么获得还比较困难。因此，下面要开始分析加密参数的生成方法。本章节主要采用frida trace动态分析和jadx静态分析相结合的方式，旨在找到加密参数生成的核心函数和输入输出数据的格式。
根据文章 ( app安卓逆向x-sign，x-sgext，x_mini_wua，x_umt加密参数解析 )，其中数据包的加密参数和本文的大麦网很类似，而且提到了 mtopsdk.security.InnerSignImpl 生成的加密函数，本文也参考了这篇文章的思路进行分析。
跟踪 InnerSignImpl
运行frida-trace -U -j "*InnerSignImpl*!*" 大麦，执行选座提交订单的操作，发现确实有结果输出：
(py3) PS E:\TEMP\damai> frida-trace -U -j "*InnerSignImpl*!*" 大麦
Instrumenting...
InnerSignImpl$1.$init: Loaded handler at "E:\\TEMP\\damai\\__handlers__\\mtopsdk.security.InnerSignImpl_1\\_init.js"
....此处省略...
InnerSignImpl.init: Loaded handler at "E:\\TEMP\\damai\\__handlers__\\mtopsdk.security.InnerSignImpl\\init.js"
Started tracing 27 functions. Press Ctrl+C to stop.
/* TID 0x144f */
6725 ms InnerSignImpl.getUnifiedSign("", "", "23781390", null, true)
6726 ms | InnerSignImpl.convertInnerBaseStrMap("", "23781390", true)
6726 ms |
点击发送请求时，调用了InnerSignImpl.getUnifiedSign函数。但是输入参数和数据参数均为HashMap类型，结果中未显示具体内容。从结果输出中猜测frida-trace是通过对需要hook的函数在handlers下生成js文件，并调用js文件进行hook操作的，因此笔者修改了“handlers\mtopsdk.security.InnerSignImpl\getUnifiedSign.js”，使其能正确输出HashMap类型。
// __handlers__\mtopsdk.security.InnerSignImpl\getUnifiedSign.js
{onEnter(log, args, state) {
// 增加了HashMap2Str函数，将HashMap类型转换为字符串
function HashMap2Str(params_hm) {
var HashMap=Java.use('java.util.HashMap');
var args_map=Java.cast(params_hm,HashMap);
return args_map.toString();
};
// 当调用函数时，输出函数参数
log(`InnerSignImpl.getUnifiedSign(${HashMap2Str(args[0])},${HashMap2Str(args[1])},${args[2]},${args[3]})`);
}, onLeave(log, retval, state) {
function HashMap2Str(params_hm) {
var HashMap=Java.use('java.util.HashMap');
var args_map=Java.cast(params_hm,HashMap);
return args_map.toString(); };
if (retval !== undefined) {
// 当函数运行结束时，输出函数结果
log(`
再次运行frida-trace，输出的结果已经可以看到具体内容了：
(py3) PS E:\TEMP\damai> frida-trace -U -j "*InnerSignImpl*!*" 大麦
......
Started tracing 27 functions. Press Ctrl+C to stop.
/* TID 0x15ab */
2653 ms InnerSignImpl.getUnifiedSign({data={"itemId":"719193771661","performId":"211232892","skuParamListJson":"[{\"count\":1,\"price\":36000,\"priceId\":\"251592963\"}]","dmChannel":"*@damai_android_*","channel_from":"damai_market","appType":"1","osType":"2","calculateTag":"0_0_0_0","source":"10101","version":"6000168"}, deviceId=null, sid=13abe677c5076a4fa3382afc38a96a04, uid=2215803849550, x-features=27, appKey=23781390, api=mtop.damai.item.calcticketprice, utdid=ZF3KUN8khtQDAIlImefp4RYz, ttid=10005890@damai_android_8.5.4, t=1684828096, v=2.0},{pageId=, pageName=},23781390,null)
2654 ms | InnerSignImpl.convertInnerBaseStrMap("", "23781390", true)
2655 ms |
可以看到返回结果中包含了 x-sgext,x-umt,x-mini-wua,x-sign 等加密参数。至此，前面的一大堆分析也算有了小的收获。但对比流量分析结果中的发送参数，还是缺失了很多参数。下面我们继续跟踪，找出剩下的参数。
跟踪 mtopsdk
调研发现淘系的apk都包含mtopsdk，猜想会不会有公开的官方文档描述mtopsdk的使用方法，因此我们就找到了 【阿里云mtopsdk Android接入文档】 。其中介绍了请求构建的流程为，笔者重点关注了请求构建和发送的部分：
// 3. 请求构建
// 3.1生成MtopRequest实例
MtopRequest request = new MtopRequest();
// 3.2 生成MtopBuilder实例
MtopBuilder builder = instance.build(MtopRequest request, String ttid);
// 4. 请求发送
// 4.2 异步调用
ApiID apiId = builder.addListener(new MyListener).asyncRequest();
因此我们不妨大胆一些，直接跟踪所有对mtopsdk中函数的调用。
(py3) PS E:\TEMP\damai> frida-trace -U -j "*mtopsdk*!*" 大麦
输出的结果大概有2000行，直接看太费劲，我们复制到文本编辑器里做进一步分析。
我们按照阿里的官方文档介绍的流程，对应可以找到在输出的trace中找到一些关键的日志。
# MtopRequest初始化
3249 ms MtopRequest.$init()
3249 ms MtopRequest.setApiName("mtop.trade.order.build")
3249 ms MtopRequest.setVersion("4.0")
3249 ms MtopRequest.setNeedSession(true)
3249 ms MtopRequest.setNeedEcode(true)
3249 ms MtopRequest.setData("{\"buyNow\":\"true\",\"buyParam\":\"7191937661_1_51826442779\",\"exParams\":\"{\\\"atomSplit\\\":\\\"1\\\",\\\"channel\\\":\\\"damai_app\\\",\\\"coVersion\\\":\\\"2.0\\\",\\\"coupon\\\":\\\"true\\\",\\\"seatInfo\\\":\\\"\\\",\\\"umpChannel\\\":\\\"10001\\\",\\\"websiteLanguage\\\":\\\"zh_CN_#Hans\\\"}\"}")
# MtopBuilder初始化
3251 ms MtopBuilder.$init("", "", null)
# MtopBuilder发送异步请求
3268 ms MtopBuilder.asyncRequest()
# 参数构建
3301 ms | | | InnerProtocolParamBuilderImpl.buildParams("")
3391 ms | | |
笔者注意到了InnerProtocolParamBuilderImpl.buildParams函数的输出结果完全覆盖了需要的各类加密参数，其输入类型是MtopContext。从jadx逆向的apk代码中可以找到MtopContext类，即包含Mtop生命周期的各个类的一个容器。
public class MtopContext {
public ApiID apiId;
public String baseUrl;
public MtopBuilder mtopBuilder;
public Mtop mtopInstance;
public MtopListener mtopListener;
public MtopRequest mtopRequest;
public MtopResponse mtopResponse;
public Request networkRequest;
public Response networkResponse;
public MtopNetworkProp property = new MtopNetworkProp();
public Map protocolParams;
public Map queryParams;
public ResponseSource responseSource;
public String seqNo;
@NonNull
public MtopStatistics stats;
}
所以现在的问题变为如何能够构建出来MtopContext，然后调用buildParams函数生成各类加密参数。
分析业务模块与mtopsdk的交互过程
在写本文复盘分析过程的时候，笔者发现仅依赖mtopsdk的调用过程其实已经可以得到MtopContext的全部生成逻辑了。但所谓当局者迷，笔者在当时分析的时候还是一头雾水。因此在此也介绍一下笔者的思考逻辑。
当时看着mtopsdk的调用过程，感觉很复杂。但是猜想从用户点击操作->业务代码->mtopsdk的数据流，以及模块间高内聚低耦合的原则，所以猜想模块间的调用不会很复杂，所以笔者就想分析业务代码与mtopsdk的调用逻辑。所以就想跟踪主要业务代码的trace。所以笔者继续跟踪trace，运行frida-trace -U -j "*cn.damai*!*" 大麦，以分析cn.damai包的调用过程，在其中发现了 NcovSkuFragment.buyNow() 函数，看起来是和购买紧密相关的函数。又找到DMBaseMtopRequest类。
但是在这里有点卡住了，因为只找到了构建MtopRequest，并未在cn.damai的trace日志中并未发现其他对mtop的调用。
然后笔者又尝试搜索和api(order.build)相关的代码，找到了：
然而并没有多大用处。
然后，作者又读了大量的源代码，终于定位到了 com.taobao.tao.remotebusiness.MtopBussiness这个关键类。
笔者本以为com.taobao开头的代码不是那么重要，所以最开始把这个类完全忽略了。但通过对源码的阅读，发现这个类是motpsdk中MtopBuilder类的子类，主要负责管理业务代码和Mtopsdk的交互。
因此我们继续通过trace跟踪MtopBussiness类。运行frida-trace -U -j "*!*buyNow*" -j "com.taobao.tao.remotebusiness.MtopBusiness!*" -j "*MtopContext!*" -j "*mtopsdk.mtop.intf.MtopBuilder!*" 大麦
现在业务代码和mtopsdk的交互就很清晰了，红色的部分是业务代码的函数，绿色的部分是mtopsdk的函数。
0x06 hook得到接口参数
通过以上对trace的分析，已经知道了具体执行的操作，因此我们可以使用frida编写js代码，直接调用APK中的类，实现功能调用。
先展示一个简单的示例，用于构建一个自定义的MtopRequest 类:
// new_request.js
Java.perform(function () {
const MtopRequest = Java.use("mtopsdk.mtop.domain.MtopRequest");
let myMtopRequest = MtopRequest.$new();
myMtopRequest.setApiName("mtop.trade.order.build");
//item_id + count + ski_id 716435462268_1_5005943905715
myMtopRequest.setData("{\"buyNow\":\"true\",\"buyParam\":\"716435462268_1_5005943905715\",\"exParams\":\"{\\\"atomSplit\\\":\\\"1\\\",\\\"channel\\\":\\\"damai_app\\\",\\\"coVersion\\\":\\\"2.0\\\",\\\"coupon\\\":\\\"true\\\",\\\"seatInfo\\\":\\\"\\\",\\\"umpChannel\\\":\\\"10001\\\",\\\"websiteLanguage\\\":\\\"zh_CN_#Hans\\\"}\"}")
myMtopRequest.setNeedEcode(true);
myMtopRequest.setNeedSession(true);
myMtopRequest.setVersion("4.0");
console.log(`${myMtopRequest}`)
});
再使用运行命令 frida -U -l .\reverse\new_request.js 大麦，以在大麦Apk中执行js hook代码。运行之后即可输出笔者自己构建的MtopRequest实例。（frida真的很奇妙！）
有了上面的结果，下面继续完善这个示例，添加MtopBussiness的构建过程和输出过程
//引入Java中的类
const MtopBusiness = Java.use("com.taobao.tao.remotebusiness.MtopBusiness");
const MtopBuilder = Java.use("mtopsdk.mtop.intf.MtopBuilder");
// let RemoteBusiness = Java.use("com.taobao.tao.remotebusiness.RemoteBusiness");
const MethodEnum = Java.use("mtopsdk.mtop.domain.MethodEnum");
const MtopListenerProxyFactory = Java.use("com.taobao.tao.remotebusiness.listener.MtopListenerProxyFactory");
const System = Java.use('java.lang.System');
const ApiID = Java.use("mtopsdk.mtop.common.ApiID");
const MtopStatistics = Java.use("mtopsdk.mtop.util.MtopStatistics");
const InnerProtocolParamBuilderImpl = Java.use('mtopsdk.mtop.protocol.builder.impl.InnerProtocolParamBuilderImpl');
// create MtopBusiness
let myMtopBusiness = MtopBusiness.build(myMtopRequest);
myMtopBusiness.useWua();
myMtopBusiness.reqMethod(MethodEnum.POST.value);
myMtopBusiness.setCustomDomain("mtop.damai.cn");
myMtopBusiness.setBizId(24);
myMtopBusiness.setErrorNotifyAfterCache(true);
myMtopBusiness.reqStartTime = System.currentTimeMillis();
myMtopBusiness.isCancelled = false;
myMtopBusiness.isCached = false;
myMtopBusiness.clazz = null;
myMtopBusiness.requestType = 0;
myMtopBusiness.requestContext = null;
myMtopBusiness.mtopCommitStatData(false);
myMtopBusiness.sendStartTime = System.currentTimeMillis();
let createListenerProxy = myMtopBusiness.$super.createListenerProxy(myMtopBusiness.$super.listener.value);
let createMtopContext = myMtopBusiness.createMtopContext(createListenerProxy);
let myMtopStatistics = MtopStatistics.$new(null, null); //创建一个空的统计类
createMtopContext.stats.value = myMtopStatistics;
myMtopBusiness.$super.mtopContext.value = createMtopContext;
createMtopContext.apiId.value = ApiID.$new(null, createMtopContext);
let myMtopContext = createMtopContext;
myMtopContext.mtopRequest.value = myMtopRequest;
let myInnerProtocolParamBuilderImpl = InnerProtocolParamBuilderImpl.$new();
let res = myInnerProtocolParamBuilderImpl.buildParams(myMtopContext);
console.log(`myInnerProtocolParamBuilderImpl.buildParams => ${HashMap2Str(res)}`)
再次执行frida -U -l .\reverse\new_request.js 大麦，输出结果如下图，此时已能根据笔者任意构建的请求data输出其他加密参数：
对于order.create的原理类似，此处不再赘述。
补充说明
通过frida调用Apk中的Java类有时候会出现找不到类的情况，原因可能是classloader没有正确加载。可以在js代码前的最前面加上下面的代码，指定正确的classloader，即可解决该问题
Java.perform(function () {
//get real classloader
//from http://www.lixiaopeng.top/article/63.html
var application = Java.use("android.app.Application");
var classloader;
application.attach.overload('android.content.Context')
.implementation = function (context) {
var result = this.attach(context); // run attach as it is
classloader = context.getClassLoader(); // get real classloader
Java.classFactory.loader = classloader;
return result;
}
});
frida hook 的强大功能
通过frida操纵Java类的功能实在过于强大，安全人员可以执行以下操作：
[ol]
打印函数输入输出。通过hook函数，以实现打印函数的输入输出结果。
操作代码可以在jadx右键菜单可以很方便的生成。
let LocalInnerSignImpl = Java.use("mtopsdk.security.LocalInnerSignImpl");
LocalInnerSignImpl["$init"].implementation = function (str, str2) {
console.log(`LocalInnerSignImpl.$init is called: str=${str}, str2=${str2}`);
this["$init"](str, str2);
};
[/ol]
0x07 通过rpc调用
前文提到frida的一个特性是可以通过rpc调用提供python编程接口。
一个简单的示例：
import frida
def on_message(message, data):
if message["type"] == "send":
print("
else:
print(message)
# hook代码
jscode = """
rpc.exports = {
testrpc: function (a, b) { return a + b; },
}; """
def start_hook():
# 开始hook
process = frida.get_usb_device().attach("大麦")
script = process.create_script(jscode)
script.on("message", on_message)
script.load()
return script
script = start_hook()
# 调用hook代码
print(script.exports.testrpc(1, 2))
# >>> 输出
# 3
frida使用rpc的方法也很简单，仅需使用rpc.exports，将对应的函数暴露出来，就能被python调用。
完整的代码就是将上一章的代码封装为函数，并通过rpc对外提供接口，就可以了。为避免侵权，本文不贴出完整利用代码。
代码封装完成后测了一下，平均一次调用的时间为0.024秒，完全可以达到抢票的要求。
0x08 踩坑经历花絮
关于wiresharkhelper
txthinking放出了一个抓包辅助工具wiresharkhelper，看视频介绍很诱人很方便，但是实测是要收费的。本人穷，所以就没用他的方法。然而也是因为这个才开始尝试用frida工具得到https的密钥，发现了frida这个神器。
关于Cookie
细心的朋友可能发现发送的请求头里是包含cookie的，但是本文没有介绍。其实笔者本来是再继续找cookie的，但是发现把InnerProtocolParamBuilderImpl.buildParams函数的参数填进去之后，就已经能正常获取服务器的返回值了，所以就没继续搞cookie
关于MtopStatistics
MtopStatistics是mtopsdk里比较重要的一个类，用来跟踪用户的操作记录状态，可能有助于判断用户是否是机器人。但笔者尝试自己构建MtopStatistics失败，所以直接生成了一个空的MtopStatistics类，好在也没对服务器的正常返回造成影响。
如何获取票价信息
这里笔者是直接用的大麦网Web端PC版，网页中有一段json，包含静态的描述信息和动态的场次、余票信息。
如何脱离模拟器运行
目前是需要模拟器一直运行着的，而且仅能用一个人的账户。这对于个人使用是完全够用的。如何能脱离模拟器，而且增加并发用户数量还需要继续研究。目前时间不允许，暂时不再继续此问题的研究。
还是抢不到票
虽然流程全都搞定，而且对于非热门场次抢票完全没有问题。但对于热门场次，官方可能还是增加了或明或暗的检测机制。比如有些是淘票票限定渠道，在对特权用户开放抢票一段时间后才会对其他人，但开放状态仅从网页端无法判断，导致脚本会提前开抢，被系统提前拦截。或者有的场次明明第一时间开抢，却还是一直提示请求失败。这个还需要进一步踩坑理解大麦网的机制。
BP链接
这篇公众号文章( https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzA4MDEzMTg0OQ==&action=getalbum&album_id=2885498232984993792#wechat_redirect ) 介绍了大麦网的bp链接及使用方式，可以跳过票档选择直接进入订单确认页面。后续可以尝试用于自动抢票。
如：
- 毛不易 - 5月27日 上海站
1、五层480 x 1张
https://m.damai.cn/app/dmfe/h5-ultron-buy/index.html?buyParam=718707599799_1_5008768308765&buyNow=true&exParams=%257B%2522channel%2522%253A%2522damai_app%2522%252C%2522damai%2522%253A%25221%2522%252C%2522umpChannel%2522%253A%2522100031004%2522%252C%2522subChannel%2522%253A%2522damai%2540damaih5_h5%2522%252C%2522atomSplit%2522%253A1%257D&spm=a2o71.project.sku.dbuy&sqm=dianying.h5.unknown.value
2、五层480 x 2张
https://m.damai.cn/app/dmfe/h5-ultron-buy/index.html?buyParam=718707599799_2_5008768308765&buyNow=true&exParams=%257B%2522channel%2522%253A%2522damai_app%2522%252C%2522damai%2522%253A%25221%2522%252C%2522umpChannel%2522%253A%2522100031004%2522%252C%2522subChannel%2522%253A%2522damai%2540damaih5_h5%2522%252C%2522atomSplit%2522%253A1%257D&spm=a2o71.project.sku.dbuy&sqm=dianying.h5.unknown.value
0x09 总结
本文完整的记录了笔者对于Apk与服务器交互API的解析过程，包括环境搭建、抓包、trace分析、hook、rpc调用。本文对于淘系Apk的分析可以提供较多参考。本文算是笔者第一次深入且成功的用动态+静态分析结合的方式，借助神器frida+jadx，成功破解Apk，因此本文的记录也较为细致的记录了作者的思考过程，可以给新手提供参考。
本文也有一些不足之处，如无法脱离模拟器运行、仅能单用户、抢票成功率仍不高等。对于这些问题，如果未来作者有时间，会再回来填坑。
本文作者为m2kar，原文发表在https://github.com/m2kar/m2kar.github.io/issues/21，转载请注明出处。
最后，欢迎大家多多提出问题相互交流。
