王盛邦, 韦宝典, 谢 逸
(1. 中山大学 公共教学实验中心, 广东 广州 510006;2. 中山大学 数据科学与计算机学院, 广东 广州 510006)
通过技术层面分析微信红包[1-4],并以此作为教学案例。通过抓取移动数据分析微信红包分发、接收的全过程,包括URL、红包服务器IP和延迟等细节内容;此外,通过记录和分析群内抢红包数据,找出红包金额分布规律、时序分布规律以及每个人多次抢到的红包金额的分布规律。剖折、探究自动抢红包的机理,提出了防范外挂抢红包软件的策略。
在对移动端数据进行分析的过程中,需要捕获手机端侧的数据包。在有线网络环境里,基本上不必做特别的设置,使用诸如Wireshark的工具,就可以捕获到大量的数据包。而对于手机上移动端数据,捕获方法显然有别于有线网络环境。目前比较常用的方法有以下几种:
(1) 使用Tcpdump[5]工具抓包,所抓取的数据包保存在手机上,之后需传回PC处理,此法需要root权限,缺点是环节较多;
(2) 在PC上建立WiFi热点,手机连上热点后使用熟知的Wireshark[6-7]就可以捕获流经的数据包,只要PC配备有无线网卡且具有无线承载功能,就可以采用此法;
(3) 使用Fiddler[8-9]工具抓包,Fiddler是一个富客户端桌面工具,可以对移动终端上客户端和服务器之间的通信数据进行捕获,一般需要将PC上的浏览器的代理设置为指向Fiddler所监听的端口,Fiddler启动后对该端口进行监听,当浏览器请求网页的时候,Fiddler便能获取所有请求的数据和Web服务器回复的数据。
采用第2或第3种方法,对于所有能够无线访问的手机都比较合适。而在PC端建立WiFi热点方面,只须使用Windows系统提供的网络外壳命令netsh。此命令同时起到监视自己的WiFi有没有被蹭网的作用。
捕获到手机数据包后,接下来就是对关于红包的数据包进行分析。图1、图2是捕获的微信红包数据。
图1 发红包数据
图2 拆红包数据
微信红包应用流程主要分为发送和接收2个主要流程。分析图1、图2可知:
(1) 发送流程主要交互域名为short.weixin.qq.com,以POST方式发起,包括支付过程。
(2) 接收流程主要交互域名为wx.gtimg.com,以GET方式下载红包图片,以POST方式向short.weixin.qq.com发起红包余额相关更新。
GET就是抢红包的关键,接收红包消息,该消息类型为图片形式,该消息触发的信令详细URI为http://wx.gtimg.com/hongbao/img/hongbao.png,访问方式为GET,资源类型为image/png。
POST就是拆红包的关键,点开红包页面,点击“拆”后便跳转至红包详情界面,后台进行红包余额更新等交互动作,该动作出发的信令详细URI为http://short.weixin.qq.com/cgi-bin/mmpay-bin/hongbao,访问方式为POST,资源类型为application/octet-stream。
经多次实验,微信在应用层使用HTTP协议传输数据,微信红包分发以POST方式发起,包括支付过程;而接收流程以GET的方式下载红包图片,以POST方式发起红包余额更新(抢到红包)。腾讯提供了多个负载均衡服务器,除IP地址为14.215.158.100外,还有58.251.100.101、180.163.25.140等。另外,微信使用了基于TSL 1.3的安全通信协议mmtls[10],该协议只对Server做认证。mmtls除安全性高外,还可保证数据在传输过程低延迟。
其他细节,诸如红包发送页面、支付页面、成功发送、接收红包、拆红包等,都可在抓取的数据包中详细分析,限于篇幅,本文不再展开。
抢红包时,常弹出“手慢了”的提示,如果排除人为因素,主要与延迟有关。微信客户端与服务器之间的链接是通过TCP协议建立的,而后面传送数据的过程主要就是用HTTP协议建立的。这2部分都可能产生延迟协议。此外,还有DNS 解析的时间等。图3是通过Fiddler工具捕获的数据。
图3 Fiddler捕获的数据
通过Fiddler工具的Statistics选项卡 可以查看到有关HTTP 请求的信息,包括Client 以及Server 的连接、请求和响应时间(3次握手产生的延迟)。例如本次实验中,DNS 解析的时间是5 ms,建立TCP/IP 连接的时间是139 ms。此外,受制于服务器的处理效率及客户端设备的效率等,服务器处理也是有一定的延时。还会存在因为丢包而产生的难以避免的延迟。实际上,延迟还要考虑网络环境,较优的路线可以降低延时和丢包率等。
(1) WiFi环境还是运营商流量环境。手机网络的状态是抢到红包成功与否的关键因素。随着4G网络的发展,在信号正常的环境下,4G网络的网速已经超越宽带的网速,而且4G网络的延时仅仅为20~30 ms,远胜于一般宽带100 ms左右的延迟。同时由于WiFi属于公用网络,同一WiFi下的其他用户网络数据的不确定性又为抢红包带来了很大的干扰,而且WiFi的信号在不同的位置会有不同程度的衰减。所以,抢红包的时候4G网络优先,WiFi次之。
(2) 手机性能。手机性能对抢红包有何影响?使用4年前出品的手机,与时下流行的热门手机在同一环境进行抢红包测试。假设有红包30份,经多次试验,在WiFi环境下,新手机不会落空,抢到时一般处于前10,而旧手机如能抢到,要排到27之后,甚至常抢不到;在使用运营商流量时,新手机已经抢到红包了,而旧手机才出现红包提示图标。这说明手机性能对延迟的影响程度很大。
(3) 手机品牌。抢红包的时候往往是一瞬间的事,需要手机能极快速地跳转到“抢红包”的页面,所以理论上来说,性能越强的手机在抢红包的时候越有优势。由于不同品牌手机性能会有所差异,即使是同时期的产品,在延迟上也会略有差异。
抢红包策略是一个引人入胜的问题。时常期望自己是手气最佳的,但有时在某种情况下又希望避免手气最佳。最懊恼的莫过于点开红包后看到“手慢了”的提示。
微信派发红包的形式共有2种,一种是普通的等额红包,一对一或者一对多发送,无论先抢还是后抢,红包金额是一样的;另一种被称作“拼手气群红包”,由发红包者设定好总金额以及红包份数,自动生成不同金额的红包供他人抢,抢到的红包中金额随机(随机数在0.01~200元之间),多的可能超过红包总额的80%,少的只有一两分钱。本文讨论的是后一种形式。这种形式在拆开红包后可看到“红包详情”中各种随机生成的金额不等的红包,通常“手气最佳”只有一个(有可能会出现金额一样的,但是手气最佳只有一个,先抢到的那个为最佳)。如果份数被设定得足够多,就有可能产生0.01元的红包。
值得一提的是有所谓“末尾红包抽屉原理”。该原理称,在微信红包中,n个人抢(n+1)分钱,必然是前面的人都抢到1分,最后一个人抢到2分。经测试,在手机上基本如此。
微信并未公布红包随机生成算法,本文只是通过实验数据给出一些抢红包策略。
实验获取红包的数据见图4,一共有12组,每组有21个成员参与抢红包,每次的总金额是5元,红框处属于手气最佳。
图4 抢红包样本数据
通过观察图4可知,红包金额最小的为0.01元,第一个被抢红包金额最大为 0.43,这小于均值的2倍(0.476)。且每个红包的金额都比剩余均值的2倍要小,即红包金额分布在0.01到2倍剩余金额均值之间。对以上数据画出散点图,如图5所示。
图5 红包金额分布图
横轴为第n个人抢的红包,纵轴为抢到的红包的金额。通过对比,可以发现越往后面覆盖的金额范围越大,最高金额的红包几乎是由后抢的人获得。即越往后面抢获得最高金额的机会越大。根据图4中数据画出红包金额的均值以及标准差折线图,如图6所示。
图6 红包金额的均值以及标准差
由图6可见,均值在每个红包均值范围上下浮动不大,而标准差则是越后越大。所以,越后抢红包的金额越不稳定,即有机会抢到大红包。通常第一个抢红包的人通常不会手气最佳。后抢的标准差更大,也就是能抢到超级大的红包,也可能抢到超级小的红包。其规律总结如下:
(1) 每个红包金额服从最小值(0.01)到 2 倍剩余均值之间的均匀分布,即不论先抢后抢,红包金额均值都一样。
(2) 越往后抢红包金额的方差越大,即越后抢越可能抢到超级大红包。
当我们点击“拆”红包图标时,实际上并不知道该红包有多少份、每份有多少金额,以及已经有多少人在前面抢了,因而所谓“策略”有点“蒙”的意思。但根据实验的结果,可以大体上把握一些微信抢红包的技巧:
(1) 不论是先抢还是后抢,最终抢到的平均金额都是差不多的。
(2) 如果不想冒险,只想稳稳当当地领取红包,可以尽快抢。
(3) 如果在抢红包的过程中,想要“手气最佳”,可以后抢,这样的机率更大。
所以当微信群玩“手气最佳发红包”的游戏时,可以根据这些规律,尽量地降低手气最佳的概率,发的红包数少就后抢,红包多就中间抢,红包数目很多就先抢,这样一般可以有效规避“手气最佳”,从而避免被动发红包。例如,在3~5人游戏时,手气最佳的概率是随抢的顺序而降低的,所以选择后抢。在6~15人游戏时,手气最佳的概率是先低后高的,要把握时机在中间的位置抢。当参与人数超过15人时,手气最佳的概率随着抢的顺序往往处于后面,这时的策略应该是尽量先抢。
抢红包时通常必须紧盯屏幕,对出现的红包图标立即点击,迟了就可能“手慢了”。这是手动抢红包者的共同感觉。为了不漏掉红包,有人开发了自动抢红包工具“抢红包神器”。所谓“抢红包神器”,就是通过编写自动抢红包的应用程序,将其外挂在手机上,实现程序自动抢红包。这种抢红包行为属于作弊,有违公平,但主观上没有危害网络安全的企图。目前已经有一些知名“抢红包神器”。下面通过“抢红包神器”的实现探究其防御方法。
自动抢红包软件的基本原理,是通过Android系统“辅助服务(accessibility service)”的一个接口,捕捉手机的通知栏变动事件、窗口切换事件、窗口内容变动事件,一旦在手机通知栏里实时检测到红包推送消息时便自动转到微信页面,搜索到红包节点,模拟人工点击操作。自动抢到红包后,再搜索“拆”红包节点,打开红包,取出红包金额。
Android Accessibility Service是Android系统提供的辅助功能,通过它可以获取页面的UI控件位置、内容等,并且模拟点击,通过编码实时监控UI变化,就可以实现针对某个控件自动点击。微信红包的UI结构,可通过DDMS工具Dump View Hierarchy For UI Automator分析。
一个完整的发现红包、抢红包、拆红包流程需要数秒时间,而各种事件是以毫秒级的速度在不断触发,因此程序的核心问题是维护好一个全局的抢红包状态转换,处理好各个事件处理任务的并发控制和相互协调,避免因状态走错而导致程序运行不稳定的情况。
自动抢红包动作由2种场景触发:发现一个微信红包消息通知、在当前微信聊天页面发现一个新红包。2种场景的处理流程大体一致,抢红包流程如图7所示。
图7 抢红包app流程
如果不是在微信的可见界面范围(在桌面或者在使用其他应用时),收到新的消息就会在通知栏提醒用户。而在微信的消息列表界面,就不会弹出通知栏,所以可以区分这2种情况,然后抓取相关关键字做进一步处理。
图7的几个主要环节如下:
(1) 在非微信消息列表界面,收到通知消息的事件,判断通知栏里的文本是否有[微信红包]的关键字,有则可以判断为用户收到红包的消息,然后就自动触发这个消息的意图事件;
(2) 在通知栏跳进微信界面后,是到com.tencent.mm.ui.LauncherUI这个 Activity 界面,在红包的消息上,包括了关键字领取红包或者View的id,就可以根据这个关键字找到相应的View,然后再触发 ACTION_CLICK(点击事件);
(3) 在点击红包后,会跳到拆红包的 Activity:com.tencent.mm.plugin.luckymoney.ui.LuckyMoneyReceiveUI,找关键字或id拆红包,然后触发自动化点击事件。
这样就可以完成整个自动化抢红包的流程了。所以,核心就是找关键字,然后模拟用户点击事件。
目前开发app一般是通过android studio[11-12]平台。首先,在Android studio中新建一个空project,添加Main Activity和对应的layout文件,并实现简单的界面和接口。然后new一个service继承自Accessibility Service。接着在注册文件中声明Accessibility Service权限。
为简化起见,本app只处理发现红包、拆红包等主要环节。图8是抢红包app运行时的截图。在图8中,最左图是刚刚打开app时需要设置打开服务,也就是开启监测操作和检索窗口内容的功能;中间是收到红包,自动跳转到微信界面并点击红包(速度非常快,很难截到图);最右图是模拟点击红包成功,在分发的3份红包中最先一个抢到。
图8 app运行截图
经测试,app能达到预期效果。需要说明的是,app可以快速抢红包,但并不意味着能抢到大的红包。相反,如果硬件配置很高,app响应速度快,快速抢到红包的概率越大,但是越早抢到红包,对应的红包金额可能会相对较小。
(1) 干扰发现红包信息。如3.1节,编写抢红包app时是通过[微信红包]来进行是否有红包的判断,所以在发红包之前,先行在微信发送文本[微信红包]这样的信息,可以导致部分外挂工具失效(即编写的抢红包app会暂时失效)。为了防御此种抢红包方式,可以将[微信红包]文本改为图标方式,将ID改为动态ID(每次显示都是随机生成)。这样通过文本内容找到控件的方法,或通过ID找寻控件的方法也就不可行了。
(2) 及时更新微信版本。识别窗体中节点的文字信息比较容易,但是识别图片就困难得多。最新的微信版本的一种改进就把拆红包界面原来的“拆红包”字样改成了“開”的图片,这样就增加了识别的难度,导致程序很难判断,因而应及时更新微信版本。很多抢红包app都因为微信版本更新而不再适用,微信运营也针对这种情况进行打击防范。
(3) 监测抢红包挂件。自动抢红包主要核心点就是快速抢。因而防止这些插件的出发点也就是通过这个时间来判断是否使用了插件。正常情况下抢一个红包需要经历多次屏幕点击,对于平均网速和人的反应速度,完成一次抢红包动作最快需要4~5 s左右。而app大概只要2~3 s左右,其速度明显超出正常人的反应能力。因而可以编写一个检测程序,对红包详情界面的数据进行分析,通过提取红包ID值以及时间戳,计算每份被抢的时间值,再算出对应的抢红包的时间差。一般2 s内抢到的,应认为是抢红包外挂所为。如果一个微信账号多次以极快的速度抢到红包,该用户就有很大的几率是使用了抢红包的app,就可以对其进行举报、警告等处理,严重者可对其进行封号或者封掉红包功能。
实际上,在多次调试抢红包app程序时,就收到微信团队如图9的警告信息。
图9 微信团队警告信息
可见,微信后台有监控,管理者可以监测到手机端的抢红包软件,一旦发现疑似作弊就可以给予警告。
最后需要指出的是,虽然抢红包app没有危害网络安全的主观意图,但开启“辅助服务”后手机存在较大安全隐患。理论上启动后,可以监听用户的任何操作,包括输入的银行卡密码等。因此对于开启辅助服务,一定要慎重。
以本文案例为例,以现实生活常见的“微信抢红包”为案例切入点,项目背景具有趣味性、工程性、知识应用的综合性和实现方法的多样性的特点,比较容易激发学生的学习热情,实验参与度高,讨论热烈。教学中,多数学生采用Wireshark方法捕获移动端数据,也有结合Fiddler进行分析。为取得样本数据他们自发组群发红包,然后综合运用数学分析方法得出抢红包规律。编写拆红包和抢红包app是本案例一大难点,但学生运用在移动应用开发课程上学到的安卓开发知识,掌握了手机辅助功能的开发应用,最终完成了实验,提升了综合解决问题的能力。
目前教学中所使用的案例内容相对陈旧,滞后于技术发展,难以实现学以致用,影响学习效果。随着技术的快速发展,许多技术已经应用到日常生活中,发掘这些技术并应用到教学中,很有必要且空间巨大。本文是一个运用统计分析技术和手机插件编写技术的综合案例。案例涉及知识综合性高,案例分析与设计相结合,总体有一定难度,体验度高、接地气,在教学中取得显著效果。