转载申明
文章转载自互联网,如有侵权,请联系删除
本文仅作为学习交流,禁止用于非法用途
0x00 概述
针对某麦网部分演唱会门票仅能在 app 渠道抢票的问题,本文研究了 APK 的抢票接口并编写了抢票工具。本文介绍的顺序为环境搭建、抓包、trace 分析、接口参数获取、rpc 调用实现,以及最终的功能实现。通过阅读本文,你将学到反抓包技术破解、Frida hook、jadx apk 逆向技术,并能对淘系 APP 的运行逻辑有所了解。本文仅用于学习交流,严禁用于非法用途。
关键词: frida, damai.cn, Android 逆向
先放成功截图:
0x01 缘起
疫情结束的 2023 年 5 月,大家对出去玩都有点疯狂,歌手们也扎堆开演唱会。演唱会虽多,票却一点也不好抢,抢五月天的门票难度不亚于买五一的高铁票。所以想尝试找一些脚本来辅助抢票,之前经常用 selenium 和 request 做一些小爬虫来搞定自动化的工作,所以在 MakiNaruto/Automatic_ticket_purchase 的基础上改了改,实现抢票功能。但是某麦网实在太狡猾了,改完爬虫才发现几乎所有的热门演唱会只允许在 app 购买,所以就需要利用 APP 实现接口自动化。
本着能省事则省事的原则,笔者在文章 [Android] 基于 Airtest 实现某麦网 app 自动抢票程序 中用自动化测试技术实现了抢票程序,但是速度太慢,几乎不能用。果然捷径往往不好走,因此继续尝试分析某麦网 apk 的 api 接口。
0x02 环境
- windows 10
- cn.damai apk 版本 8.5.4 (2023-04-26)
- bluestacks 5.11.56.1003 p64
- adb 31.0.2
- Root Checker 6.5.3
- wireshark 4.0.5
- frida 16.0.19
- jadx-gui 1.4.7
0x03 环境搭建
bluestacks 环境搭建
目前 Android 模拟器竞品很多,选择 Bluestacks 5是因为它能和 windows 的 hyper-v 完美兼容,root 过程也相对简单。
首先需要 root Bluestacks 环境。
- 下载安装 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,共两处。
1 | bst.feature.rooting="1" |
- 启动 bluestack 模拟器,安装
Root Checker
APP,点击验证 root,即可发现 root 已成功。
上述 root 过程主要参考了 https://appuals.com/root-bluestacks/ ,部分地方做了改正,在此感谢原文作者。
打开 adb 调试
- bluestack 设置-高级中打开 Adb 调试,并记录下端口
- 打开主机命令行,运行
adb connect localhost:6652
,端口号修改为上一步的端口号,即可连接。再运行adb devices
,如有对应设备则连接成功。 - 进入 adb shell,执行 su 进入 root 权限,命令行标识由
$
变为#
,即表示 adb 进入 root 权限成功。
frida 环境搭建
frida 是大名鼎鼎的动态分析的 hook 神器,用它可以直接访问修改二进制的内存、函数和对象,非常方便。它对于 Android 的支持也是很完美。
frida 的运行采用 C/S 架构,客户端为电脑端的开发环境,服务器端为 Android,均需对应部署搭建。
客户端环境搭建(Windows)
firda 客户端基于 python3 开发,因此首先需要配置好 python3 的运行环境,然后执行 pip install frida-tools
即可完成安装。运行 frida --version
可验证 frida 版本。
1 | (py3) PS E:\TEMP\damai> frida --version |
服务器 环境搭建(Android)
环境搭建第二步是在 Android 模拟器中运行 frida-server。这样可以让 Frida 通过 ADB/USB 调试与我们的 Android 模拟器连接。
下载 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 模拟器
1 | adb push frida-server /data/local/tmp/ |
- 运行 frida-server
使用 adb root 以 root 模式重新启动 ADB,并通过 adb shell 重新进入 shell 的访问。进入 shell 后,进入我们放置 frida-server 的目录并为其授予执行权限:
1 | cd /data/local/tmp/ |
执行:./frida-server
,运行 frida-server,并保持本 shell 窗口开启。
成功截图:
有些情况下,应用程序会检测在是否在模拟器中运行,但对某麦网 app 的分析暂无影响。
- 测试是否连接成功
在 window 端运行 frida-ps 命令:
看到一堆熟悉的 Android 进程,我们就连接成功啦
- 转发 frida-server 端口 (可选)
frida-server 跑在 Android 端,frida 需要通过连接 frida-server。上一步使用 adb 的方式连接,frida 认为是 USB 模式,需要-U
命令。frida 也支持依赖端口的远程连接模式,在某些场景下更加灵活。可以通过端口转发的方式实现此功能。
1 | adb forward tcp:27042 tcp:27042 |
27042 是用于与 frida-server 通信的默认端口号,之后的每个端口对应每个注入的进程,检查 27042 端口可检测 Frida 是否存在。
本部分主要参考了 https://learnfrida.info/java/ , 在此感谢原文作者。
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 运行:
- 挂载存储
1 | termux-setup-storage |
- 安装 tcpdump
1 | pkg install root-repo |
- 运行抓包
1 | sudo tcpdump -i any -s 0 -w ~/storage/downloads/capture.pcap |
- tcpdump 成功截图:
之后就可以把 downloads 目录下的抓包文件拷贝到电脑上,用 wireshark 打开做进一步分析。
2. 解密 https 流量
Wireshark 解密 https 流量的方法和原理介绍有很多,可参考以下文章,本文不再赘述。
wireshark 解密技术的重点在于拿到客户端通信的密钥日志文件(ssl key log),像下面这种:
在 Android 中实现抓取 ssl key log 需要 hook 系统的 SSL 相关函数,可以用 frida 实现。
- 首先将下面的 hook 代码保存为
sslkeyfilelog.js
1 | // sslkeyfilelog.js |
- 然后用 frida 加载运行 hook
1 | frida -U -l .\sslkeyfilelog.js -f cn.damai |
- 最后,抓包结束后将得到的 key 保存到 sslkey.txt,格式是下面这样的,不要掺杂别的。
1 | CLIENT_RANDOM 557e6dc49faec93dddd41d8c55d3a0084c44031f14d66f68e3b7fb53d3f9586d 886de4677511305bfeaee5ffb072652cbfba626af1465d09dc1f29103fd947c997f6f28962189ee809944887413d8a20 |
在运行 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 的分析,某麦网购票的工作流程大概为:
- 获得详情:接口为
mtop.alibaba.damai.detail.getdetail
。基于某演出的 id(itemId)获得演出的详细信息,包括详情、场次、票档(SkuId)价位及状态信息, - 构建订单:接口为
mtop.trade.order.build.h5
。发送 演出 id+数量+票档 id(itemId_count_skuId
),得到提交订单所需的表单信息,包括观众、收货地址等。 - 提交订单:接口为
mtop.trade.order.create.h5
。对上一步构建订单得到的表单参数作出修改后,发送给服务器,得到最后的订单提交结果和支付信息。
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 解码后为:
1 | {"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 解码后为:
1 | {"feature":"{\"gzip\":\"true\"}","params":"H4sIAAAAAAA.................AAWk3NKAAA\n"} |
看起来像是把原始数据用 gzip 压缩后又使用了 base64 编码,尝试解码:
1 | import base64 |
解码成功,存到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*!*" 大麦
,执行选座提交订单的操作,发现确实有结果输出:
1 | (py3) PS E:\TEMP\damai> frida-trace -U -j "*InnerSignImpl*!*" 大麦 |
点击发送请求时,调用了 InnerSignImpl.getUnifiedSign 函数。但是输入参数和数据参数均为 HashMap 类型,结果中未显示具体内容。从结果输出中猜测 frida-trace 是通过对需要 hook 的函数在handlers下生成 js 文件,并调用 js 文件进行 hook 操作的,因此笔者修改了“handlers\mtopsdk.security.InnerSignImpl\getUnifiedSign.js”,使其能正确输出 HashMap 类型。
1 | // __handlers__\mtopsdk.security.InnerSignImpl\getUnifiedSign.js |
再次运行 frida-trace,输出的结果已经可以看到具体内容了:
1 | (py3) PS E:\TEMP\damai> frida-trace -U -j "*InnerSignImpl*!*" 大麦 |
可以看到返回结果中包含了 x-sgext
,x-umt
,x-mini-wua
,x-sign
等加密参数。至此,前面的一大堆分析也算有了小的收获。但对比流量分析结果中的发送参数,还是缺失了很多参数。下面我们继续跟踪,找出剩下的参数。
跟踪 mtopsdk
调研发现淘系的 apk 都包含 mtopsdk,猜想会不会有公开的官方文档描述 mtopsdk 的使用方法,因此我们就找到了 【阿里云 mtopsdk Android 接入文档】 。其中介绍了请求构建的流程为,笔者重点关注了请求构建和发送的部分:
1 | // 3. 请求构建 |
因此我们不妨大胆一些,直接跟踪所有对 mtopsdk 中函数的调用。
1 | (py3) PS E:\TEMP\damai> frida-trace -U -j "*mtopsdk*!*" 大麦 |
输出的结果大概有 2000 行,直接看太费劲,我们复制到文本编辑器里做进一步分析。
我们按照阿里的官方文档介绍的流程,对应可以找到在输出的 trace 中找到一些关键的日志。
1 | # MtopRequest初始化 |
笔者注意到了 InnerProtocolParamBuilderImpl.buildParams 函数的输出结果完全覆盖了需要的各类加密参数,其输入类型是 MtopContext。从 jadx 逆向的 apk 代码中可以找到 MtopContext 类,即包含 Mtop 生命周期的各个类的一个容器。
1 | public class MtopContext { |
所以现在的问题变为如何能够构建出来 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 类:
1 | // new_request.js |
再使用运行命令 frida -U -l .\reverse\new_request.js 大麦
,以在某麦 Apk 中执行 js hook 代码。运行之后即可输出笔者自己构建的 MtopRequest 实例。(frida 真的很奇妙!)
有了上面的结果,下面继续完善这个示例,添加 MtopBussiness 的构建过程和输出过程
1 | //引入Java中的类 |
再次执行frida -U -l .\reverse\new_request.js 大麦
,输出结果如下图,此时已能根据笔者任意构建的请求 data 输出其他加密参数:
对于 order.create 的原理类似,此处不再赘述。
补充说明
通过 frida 调用 Apk 中的 Java 类有时候会出现找不到类的情况,原因可能是 classloader 没有正确加载。可以在 js 代码前的最前面加上下面的代码,指定正确的 classloader,即可解决该问题
1 | Java.perform(function () { |
frida hook 的强大功能
通过 frida 操纵 Java 类的功能实在过于强大,安全人员可以执行以下操作:
- 打印函数输入输出。通过 hook 函数,以实现打印函数的输入输出结果。
操作代码可以在 jadx 右键菜单可以很方便的生成。
1 | let LocalInnerSignImpl = Java.use("mtopsdk.security.LocalInnerSignImpl"); |
- 修改已有的类和函数。
- 定义新类和新函数。
- 主动生成类的实例或调用函数。
- RPC 调用。通过 RPC 调用提供 python 编程接口。
0x07 通过 rpc 调用
前文提到 frida 的一个特性是可以通过 rpc 调用提供 python 编程接口。
一个简单的示例:
1 | import frida |
frida 使用 rpc 的方法也很简单,仅需使用 rpc.exports,将对应的函数暴露出来,就能被 python 调用。
完整的代码就是将上一章的代码封装为函数,并通过 rpc 对外提供接口,就可以了。为避免侵权,本文不贴出完整利用代码。
代码封装完成后测了一下,平均一次调用的时间为 0.024 秒,完全可以达到抢票的要求。
0x08 提示和技巧
参考大家经常问的问题以及评论区大佬的思路,总结一些提示和技巧.
编码格式细节
很多朋友出现服务端返回”非法签名的情况”,是由于细节的问题.
order.build 和 order.create 接口的具体编码规则很细节,比如一些空格,引号,是否 urlEncode 等等. python requests 包自己的封装格式可能和和大麦 apk 不兼容,因此最后出来的包实质是差别比较大.
解决措施:
- 用 wireshark 抓 apk 发包和自己代码发的包,分析区别
- 尝试一层一层解 apk 发的包,然后再重新打包,看是否能和之前保持一致
- request 的 post 内容不要用 dict,用文本.
- 编码多用字符串拼接.
- header 里的字段名大小写/顺序最好保持一致.
- create 发送的 data 是在 build 的返回值做了一些编辑
7.
禁用 spdy
感谢 @IWasSleeping
参考: https://github.com/m2kar/m2kar.github.io/issues/21#issuecomment-1634733885
对于 mtopsdk ssl 的抓包可以通过屏蔽掉 spdy 协议,关闭 spdy ssl 和全局的 spdy 来实现让 APP 通过 http 协议,来方便任何安卓版本实现简单抓包,通过 hook 的方式:
let SwitchConfig = Java.use("mtopsdk.mtop.global.SwitchConfig");
SwitchConfig["isGlobalSpdySslSwitchOpen"].implementation = function () {
console.log(`SwitchConfig.isGlobalSpdySslSwitchOpen is called`);
let result = this["isGlobalSpdySslSwitchOpen"]();
console.log(`SwitchConfig.isGlobalSpdySslSwitchOpen result=${result}`);
return false;
};
SwitchConfig["isGlobalSpdySwitchOpen"].implementation = function () {
console.log(`SwitchConfig.isGlobalSpdySwitchOpen is called`);
let result = this["isGlobalSpdySwitchOpen"]();
console.log(`SwitchConfig.isGlobalSpdySwitchOpen result=${result}`);
return false;
};
通过主动调用的方式:
var SwitchConfig = Java.use('mtopsdk.mtop.global.SwitchConfig')
var config = SwitchConfig.getInstance();
config.setGlobalSpdySslSwitchOpen(false);
config.setGlobalSpdySwitchOpen(false);
滑动验证码
感谢: @svcvit
参考: https://github.com/m2kar/m2kar.github.io/issues/21#issuecomment-1635989770
滑块过了,原理:FAIL_SYS_USER_VALIDATE 的时候,返回头里有个 location,用浏览器打开这个 url,滑动,获取 cookies,装入 request 里,就可以了。效果参考下方。
traceid
请问 header 中的 x-c-traceid 是怎么构建的,rpc 返回的对象中这个值是空的
建议参考:
感谢 @HenryWu01
也可以参考,但固定较多内容,可能增加被识别的概率:
1 | utdid = "ZHmSZ78mpAEDALjcMTWN1YHF" |
感谢 @nobewp
0x09 踩坑经历花絮
关于 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 链接及使用方式,可以跳过票档选择直接进入订单确认页面。后续可以尝试用于自动抢票。
如:
1 | - 毛不易 - 5月27日 上海站 |
0x10 总结
本文完整的记录了笔者对于 Apk 与服务器交互 API 的解析过程,包括环境搭建、抓包、trace 分析、hook、rpc 调用。本文对于淘系 Apk 的分析可以提供较多参考。本文算是笔者第一次深入且成功的用动态+静态分析结合的方式,借助神器 frida+jadx,成功破解 Apk,因此本文的记录也较为细致的记录了作者的思考过程,可以给新手提供参考。
本文也有一些不足之处,如无法脱离模拟器运行、仅能单用户、抢票成功率仍不高等。对于这些问题,如果未来作者有时间,会再回来填坑。
本文作者为 m2kar,原文发表在 https://github.com/m2kar/m2kar.github.io/issues/21
,转载请注明出处。
分享一个 tg 讨论组, https://t.me/+IbWm3n0o1KlkMTg1 ,感谢 @svcvit
最后,欢迎大家在 issue 评论区或 tg 讨论组多多提出问题相互交流。
- 欢迎评论以及发邮件和作者交流心得。
- 版权声明:本文为 m2kar 的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
- 作者: m2kar
- 打赏链接: 欢迎打赏 m2kar,您的打赏是我创作的重要源泉
- 邮箱:
m2kar.cn<at>gmail.com
- 主页: m2kar.cn
- Github: github.com/m2kar
- CSDN: M2kar 的专栏
欢迎在 ISSUE 参与本博客讨论: m2kar/m2kar.github.io#21