游戏安全实验室游戏漏洞外挂分析

游戏安全实验室 › 首页 ›游戏漏洞 › 查看内容

【漏洞挖掘教程】文本校验类风险

发布于：2017-4-17 15:24 | 126411次阅读作者: 管理员 | 原作者: TP | 来自: 原创

文本风险定义：

在游戏中除了动画，声音参与和玩家的交互之外，游戏中的文本也属于和玩家交互中一项重要的元素。由玩家操作触发任何不同于游戏自身逻辑设定，进而破坏游戏平衡的文本内容都可以称之为文本类风险漏洞。（这个定义自己瞎写的…）

文本风险危害（漏洞举例）：

很多玩家可能有疑问，一些文本内容能产生多大的风险呢？笔者肯定是在小题大做…
我们先来看几个例子：

在游戏中你有没有遇到过一些玩家无限用变色文字打着广告或者刷着信息呢？

或者游戏中出现大量反动垃圾信息？

当你去尝试制止他的时候，是否会受到对方的辱骂？更或者，直接无限消息刷屏让你无法正常接受其他消息

当你发现自己无能为力的时候，你想去举报他，却发现对方是空昵称！！！

当对方不是空昵称时，你以为自己可以举报，但是对方的昵称你能够用输入法打出来么？

你说你可以复制粘贴，但是你真的确定复制出来的昵称就是对方的昵称么？（如下图角色昵称表面上看是x?，但是却无法找到玩家）

好不容易当你遇到一个作弊而且拥有正常昵称的玩家，终于可以举报了，却发现下图这种情况

你到底举报的是谁？？？

由上述可见，文本类风险稍微加以利用，造成的危害远远比想象中的大很多很多。将上述风险进一步归纳如下：

文本类风险存在原因：

大多数文本类风险存在均是因为游戏疏忽了文本的风险，而没做校验，或者校验只放在本地客户端，有些游戏虽然做了服务器校验，但是校验强度不够。

文本类风险漏洞挖掘方法：

知道了文本漏洞存在的原因，那针对未做校验的游戏，可以通过用户直接操作文本挖掘漏洞，当游戏测做了检验时，则挖掘的关键便是如何去巧妙的构造协议去绕过游戏的重重校验了。

在开始挖掘前，先来简单的了解下文本类协议的基本结构（可能前后顺序和具体字段会有出入）

Clsid

(协议ID)

Hash/ACK

(hash/序列)

Others

(其他)

Text_len

(此条协议长度)

Text

(文本的内容)

Text_ attribute

(协议属性字段)

ProtocolHead(协议头)

ProtocolData(协议数据包)

结合上述总结的文本类风险，对照协议结构图，文本内容风险漏洞主要更改协议结构中Text字段，而文本属性风险风险主要更改Text_len和Text_attribute字段。下述分别举例各类风险挖掘过程：

选取某游戏在创建角色昵称时协议，简单说明唯一性风险和空风险常规挖掘思路。游戏在登入界面创建角色时发送的协议如下

[05 D8 0B 05 F6 DB 05 31 32 33 00 00]

该协议被工具切割为以下结构：

Ø 协议结构（游戏创建角色昵称协议）

[05 D8 0B 05]-协议ID

[F6 DB]-协议ACK

[05]-协议长度

[31 32 33]- TEXT内容（角色名）

[00 00 ]-文本结束标志

l 唯一性风险

上述协议实际上为创建角色名为123的角色昵称，为构造雷同角色，可以按照上述协议结构直接发包，如果服务器校验通过，则证明判断逻辑在本地，创建雷同角色成功，如果服务器校验不通过，则我们想办法进行绕过：

服务器校验不通过，则证明后台对角色名有重复检测，看来直接构造完全相同的字符是不行的，那么我们可以构造出看起来相同的字符，比如[31 32 33 00 00 00]这样的文本内容，或者将其TEXT内容改为[31 32 33 0A 0D]，因为ascii-0A 0D为特殊转义字符，解析成换行符，对玩家而言其实是不可见的，可以利用转义字符去欺骗服务器，服务器认定为[31 32 33]和[31 32 33 0A 0D]为不同文本，但用户看起来效果是一样的，所以雷同角色名再次被创建。

l 空风险：

仍然是上述游戏，为创建空昵称，我们直接将[31 32 33]字段改写为[00 00 00]，观察服务器回馈，如果通过，则空角色创建成功，如果不行，我们继续利用上述的思想，利用转义字符进行欺骗，构造[0A 0D]的TEXT段，则有一次可创建空昵称。

选取某游戏发言协议，简单介绍脏词/敏感词/特殊词，文本大小/颜色/长度的挖掘思路。游戏中玩家向另一名玩家发言时，我们截获到协议的数据为

[3C 2C 37 0A 30 39 12 0D 0C 00 00 00 E2 88 95 F8 EA E8 6D 00 01 00 00 00 E0 00 00 00 76 65 6E 69 64 69 63 00 00 00 17 00 0C 00 00 00 24 69 66 30 32 24 31 38 24 31 38 24 00 1C 00 00 00 01 00 00 00……]，该协议被工具切割成如下：

Ø 协议结构（某游戏的聊天发言的协议）：

[3C 2C 37 0A 30 39 12 0D]-玩家ID

[0C 00 00 00]-频道ID

[E2 88 95 F8 EA E8 6D 00]-接受者玩家ID

[01 00 00 00]-接受者频道ID

[E0 00 00 00 76 65 6E 69 64 69 63 00 00]-接受者昵称

[00 17 00 0C 00 00 00 24 69 66 30 32 24 31 38 24 31 38 24 00]-聊天信息TEXT，其中17代表TEXT段长度，后续解析成字符串$if02$18$18$Z，这是这款游戏的文本格式，最后用[00]代表协议结束

[1C 00 00 00]-聊天类型

[01 00 00 00 ]-聊天标志

…

l 脏词/敏感词

对于上述协议结构，如果想要创建脏词，则直接修改协议中的TEXT段进行重发，如将协议中$if02$18$18$Z中if02字符换成你想要的字符即可。当字符超出了前面预设的长度时，则需要修改前面对应的长度字段17，如果发送的敏感字符被服务器抛弃，则可以尝试前面用字符构造去欺骗服务器。

l 特殊词

特殊词可以简单理解成几年前的火星文，从ascii层面来看，是一些无法被解析成文本字符的文字，其构造方式很简单，直接将上述协议中text中字符修改为我们常见的ascii和汉子编码外的字符即可，这样再由游戏解析变会变成无法辨认的特殊词

l 文本大小

继续选取上述协议字段，发现了TEXT中[00 17 00 0C 00 00 00 24 69 66 30 32 24 31 38 24 31 38 24 00]ascii被解析成$if02$18$18$Z，其中if02代表内容，而后续18，18经过分析可最终确定为文本的长宽，直接修改18，18为FF, FF，则可以实现超大文本。