强制交互类风险定义游戏中处处存在着交互，玩家与游戏的交互，玩家与玩家的交互，交互的好坏也直接影响到玩家的游戏体验。在游戏中有悖于玩家个人意愿，而强制性进行玩家间交互操作的都可以称之为强制交互风险。
强制交互类风险危害强制交互类风险的表现形式很多，我们先来看看几个例子：某游戏玩家组队进副本，队伍公开募集各职业高玩，当队伍可满足通关要求时，队长终止招募（图中为了演示效果，只有队长1人），可当你刚准备进入副本时，队伍中莫名出现了1个队友

此时当你将他踢出之后，他又能再次进入你的队伍，无奈之下你只有带着这位不速之客一起刷副本了。又比如你在某游戏场景中正在闲逛，突然之间，游戏弹出一个交易框

你将交易框叉掉后再次弹出，此时对方未经过你的同意再次向你发起了交易，你一直被骚扰直到支付了对方所需的游戏币才结束。结合上述2个简单的案例，可以对强制交互类风险做一个归纳，如下图：

按照游戏形式划分，强制交互在不同游戏中的表现形式会多种多样，但按照交互表现来划分，则可以划分为提示类交互和直接类交互。强制交互一般带来的风险如下：
1.玩家借用强制交互完成游戏中相关玩法（如直接结婚或借助他人完成任务等），破坏游戏平衡
2.玩家强制实现自己的目的（如订婚，组队等），可以极大满足玩家虚荣心，玩家可借此进行炫耀
3.玩家利用强制交互对他人造成干扰，破坏游戏玩法，极大影响游戏体验，影响游戏口碑。
4.玩家可利用此进一步敲诈勒索其他玩家的虚拟财产。


强制交互类风险存在原因结合上述案列可以发现，正常情况下交互在游戏中是合理的，但有些交互能够被玩家利用后让其他玩家只能被动接受交互过程或交互结果，而造成这种风险的主要原因是服务器未对交互的合法性进行判断强制交互类风险漏洞挖掘方法结合风险成因和表现形式，强制交互类的风险与之前的弹框干扰类风险有些相似，他们都具有交互的性质，而且结果都会对玩家造成干扰，不同的是，强制交互更偏向与玩家间的交互结果。两种风险的挖掘方法也很类似，核心都在于如何提取协议中标志着玩家UIN的字段，而交互类风险，除此之外还需要进一步分析协议，明确代表着交互结果类的字段。可将交互的通用协议简单归纳为如下结构：Clsid(协议ID)

Hash/ACK(hash/序列)

Others(其他)

Player1_uin请求者ID

Player2_uin接受者ID

Flags接受/拒绝标志

ProtocolHead(协议头)

ProtocolData(协议数据包)

结合结构，风险验证的关键就是确定player2_uin和Flags这两处字段，然后即可将player2_uin修改为被攻击玩家，Flags修改为接受，进行协议重发即可。我们以某游戏场景为例：

利用协议工具可截获协议3为：[01 BE 02 00 32 00 00 00 00 00 00 00 28 98 67 13 1E 98 1F 13 01 00 00 00 00 98 67 13 1E 06 00 00 00 01 00 00 00]
此条协议表示A同意与B结婚，hex数据被工具自动切割为：[01 BE 02 00]协议号[32 00 00 00]服务器ID[00 00 00 00]频道ID[28 98 67 13]
player1_uin：发起交互的玩家ID[1E 98 1F 13]player2_uin，接受交互的玩家ID[01 00]Flags，交互标志位，01代表接受[00 00 00 98 67 13 1E 06 00 00 00 01 00 00 00]其他字段含义，本篇内不予关心利用协议工具，修改player2_uin为想要交互的玩家ID，然后发送给服务器，服务器解析成功后便会下发结婚成功的消息，此时漏洞已经利用完成。
与此同时，这个漏洞也能演变成干扰类风险，将上述协议FLAGS改为00，表示B不接受A的邀请，此时B玩家会收到“该玩家拒绝了您的申请”弹框，进行重发，即可构成干扰。对于重发类协议，如果协议字段中存在流水token（游戏自身防重发机制）的话，则很可能重发失败，则需要结合游戏自身逻辑分析，通过call函数或者分析流水ID生成规律，自动填充对应字段来进行解决。综上，强制交互类风险的一般挖掘方法可归纳为如下：





*转载请注明来自游戏安全实验室（GSLAB.QQ.COM）

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课