modal弹框触发但无显示_【漏洞挖掘】弹框骚扰类风险

致力于分享游戏安全技术，提供专业的游戏安全资讯

弹框干扰风险定义: 游戏过程中，客户端经常会以文字类形式对玩家进行说明和指引，而对于一些更为重要的信息，便会用游戏中的弹框进行强调。由玩家主动触发对其他玩家造成重复弹框进而干扰到正常游戏的都可以称之为弹框干扰类风险。   弹框干扰风险危害： 很多玩家在想，游戏自身就提供了弹框，如果出现了弹框点掉不就好了？能有什么风险呢？我们来看看以下场景： 当你在游戏过程中，正在操作着角色时，突然间出现了一个弹框 而此时你的任何按键，鼠标点击，均因为这个弹框而失效，你的一次次操作全部失效，角色头顶上显示一个个miss的提示，你只能去点掉这个弹框，而对于这种即时操作类竞技游戏，最终因为正常游戏操作受到极大干扰而输掉比赛。 当你在某游戏排位赛的时候，正在聚精会神的盯着屏幕观察战局时，突然屏幕中间出现了下面的弹框 此时别说你的操作了，你连敌人都看不到，怎么可能赢得排位赛？ 更有甚者，在你没有进行竞技类游戏操作的时候，也会受到恶意弹框，让你根本无法正常游戏，以达到他勒索的目的(下图为某游戏玩家因受到弹框勒索而进行投诉) 由此可见，看似寻常的弹框类风险，稍加利用便可以对游戏和玩家带来极大的影响：

1. 极大的影响游戏平衡：在竞技类游戏中，通过弹框干扰其他玩家正常游戏，最终让其输掉比赛或自己获得收益 2. 极大的破坏游戏口碑：玩家受到弹框干扰，无法正常游戏，极大影响游戏体验，破坏游戏心情，引发游戏玩家的不满和吐槽，最终破坏游戏口碑 3. 弹框风险可进一步衍化成游戏内的敲诈勒索风险：利用弹框无限干扰其他玩家以达到自己的需求(勒索其他玩家向其支付游戏币或游戏道具等)

  弹框干扰风险存在原因： 结合游戏弹框案列， 无限弹框之所以能成为漏洞，首先需要具备2个属性，一个是可以干扰到玩家游戏，如果弹框对玩家没有干扰效果，那玩家也不一定会去在意，第二个是可以无限进行触发，如果弹框触发了一次之后便再也不会出现或者隔一段较长时间才能触发，那对玩家的影响也不会特别大。结合这两个属性，可将弹框的成因进一步归纳如下： 弹框干扰类风险漏洞挖掘方法： 根据上述原因分析可知，一般游戏内被动产生的弹框提示(比如游戏指引，玩法说明等)不受玩家控制，产生漏洞的可能性不高，而漏洞主要产生在由玩家触发的弹框中，如何分析提取弹框类协议中玩家标志字段是弹框干扰类风险挖掘方法的核心。 我们将一般弹框类协议格式大体如下：

Clsid(协议ID)	Hash/ACK(hash/序列)	Others(其他)	Player1_uin请求者ID	Player2_uin接受者ID	Flags接受/拒绝标志
ProtocolHead(协议头)			ProtocolData(协议数据包)

 

MsgBox_Len(弹框内容长度)	MsgBox_Text (弹框文本内容)	MsgBox_Type弹框类型	Others其他字段
ProtocolData(协议数据包)

漏洞挖掘的关键是，确认其中的玩家uin(协议中对玩家的标记)，并替换成你想要攻击的玩家，进行协议重发，观察服务器的反馈情况，具体参加下面例子： 某游戏在游戏比赛中存在着邀请玩家和拒绝玩家两条协议,案例情景为B向玩家A发送邀请，玩家A拒绝了邀请，拒绝协议经服务器至B。 大体协议交互为下图 利用工具，可将A玩家拒绝B的协议3和4截获， 协议3(A玩家拒绝B的上行数据包)的数据包截获为： [BF 02 C0 F1 0c 00 BF 02 C0 A5 50 B1 A5 A0 B8 98 8D 02 00 00 00] 通过协议切割，可解析成 [BF 02 C0] 协议号 [F1 0C 00 BF 02 C0 ] [A5 50 B1 A5] :被拒绝玩家UIN(指玩家B) [A0 B8 98 8D] :主动拒绝玩家UIN(指玩家A) [02 00 00 00]:拒绝码，01或者02对方玩家被弹框，发送多条协议会叠加弹框 协议4(A玩家拒绝B的下行数据包)截获为： [C0 02 C1 F1 0C 00 C0 02 C1 A0 B8 98 8D A5 50 B1 A5 02 00 00 00] 被协议工具解析成： [C0 02 C1]:协议号 [F1 0C 00 C0 02 C1 ] [A0 B8 98 8D]:主动拒绝玩家(指玩家A) [A5 50 B1 A5]:被拒绝玩家(指玩家B) [02 00 00 00 ]:拒绝码，01或者02对方玩家被弹框，发送多条协议会叠加弹框 分析上述协议，如果我们将上述协议3多次重发，那么在游戏中，玩家B就会收到多个拒绝类型的弹框，而我们可分析得到其他玩家C或者D的uin， 替换到协议3中被拒绝玩家UIN字段里，那么就可以攻击指定的玩家了。 类似的，上述协议交互中，协议1协议2同样也会存在着被邀请玩家的UIN，我们可以替换成要攻击的玩家，并多次进行协议重发，就可以实现邀请类型的协议弹框了。 上述利用方法，可针对一般游戏进行测试，但是往往会遇到一些游戏做了协议重放校验，导致了我们利用工具重发失败。一般这种情况下，需要分析协议中是否含有类似与验证token，一般这个token属于一次性的，服务器校验通过则会使协议生效，而进行重放的话，每次的token都相同，服务器自然会主动丢弃。面对这种情况，则需要通过立项从协议发送点进一步向游戏逻辑层定位，定位到游戏逻辑层的对应代码，进行远程调用这个函数，并填写参数为对应的玩家id，进行多次调用，因为此时游戏执行还未到组包函数，故调用对应函数会按照游戏自身逻辑组包，可绕过大多数协议重放的检测。 综上，可简单的将弹框干扰类风险的漏洞挖掘方法总结如下：