[原创]游戏漏洞挖掘之外挂类风险

天一教育培训寐

随着游戏在外网运营时间的增长，游戏自身的漏洞会逐渐爆发，演变成各种各样的外挂，传播在作弊玩家中。
游戏自身漏洞被发现和利用是外挂出现的根本原因。不同游戏的类型不同，其外挂功能也不同。
为了方便本篇的描述，笔者简单的将游戏分为竞技类游戏和休闲类游戏：

之所以将众多游戏种类划分为这两类，是因为这类游戏产生的外挂种类往往有较大的区别。强竞技类游戏的外挂，主要目的是为了使玩家在竞技过程中获得增益，如FPS类游戏的透视自瞄，动作类游戏的远程攻击，自身无敌，全屏秒杀等，这些外挂往往具有变态类功能，破坏了竞技的公平性，而休闲类游戏的外挂，主要是为了增加趣味性、恶意干扰等功能，如任意捏脸，限定表情，变色文本，，比如以敲诈勒索类为主的恶意干扰，以刷屏霸屏为主的广告推销等等……强竞技类游戏强竞技类游戏出现的外挂数量庞大，种类最多，其外挂的恶劣程度也远超过其他类型的游戏。本章主要针对强竞技类游戏，并围绕着其中的2个关键的系统——攻击和移动，进行漏洞挖掘方法的介绍，希望能够起到抛砖引玉的作用。攻击系统攻击系统属于战斗系统中最为复杂也最为关键的系统，它参与到玩家攻击前后的血量，状态，伤害，评分等各个计算，任何一个环节出现错误，都会导致最终的结果出现偏差，直接影响到最终的竞技结果。攻击系统也正是因为自身逻辑的复杂，导致潜在的风险很多，往往成为外挂作者最为关心的地方下面以某款RPG类游戏举例，详细的介绍下攻击系统流程（不保证其他游戏攻击流程与下图完全一致）：
图片中介绍了该游戏完整的攻击链，其中黑色方框处，便是可能出现的风险点。下面进一步详细解释各个环节：
1. 召唤：不少战斗系统中涉及到技能可以召唤出己方宠物等，辅助自己战斗。不少外挂，可利用伪造上行协议，或者直接call游戏内函数，召唤出本不属于自身的宠物，来辅助自己战斗。
2. 秒杀：在战斗系统开始前，游戏自身会初始化当前战斗系统中的怪物个数或是怪物血量，较多外挂通过分析客户端逻辑或协议，修改客户端自身代码或者伪造协议，使直接初始化怪物个数为0，或者初始化怪物HP为0，导致无需进行战斗，则怪物自动死亡，进而实现了怪物的秒杀效果。
3. 全屏效果/攻击：战斗系统中碰撞的概念很重要，武器攻击是否碰撞到怪物，技能攻击是否碰撞到怪物，怪物是否碰撞到玩家等等。不少角色的攻击过程，实际上是修改了碰撞结果让技能，子弹等游戏对象与全屏怪物进行碰撞，于是乎就产生了全屏效果的概念。如一颗手雷导致的全屏攻击，单一技能导致的全屏攻击等。。
4. 自身无敌：同样自身无敌的产生，也是借助了碰撞逻辑，不少外挂将怪物与玩家自身的碰撞，直接改为无效，那么，所有对玩家自身的攻击，游戏都误以为没有攻击成功，进而导致了自身无敌。5. 100%击中/远程攻击：这里罗列的100%击中和远程攻击，与第4处描述的略有不同。游戏的正常流程为：当一个攻击碰撞触发成功后，游戏自身会将碰撞的结果（攻击坐标与命中坐标，或攻击坐标与攻击朝向），甚至攻击计算后的结果，上报给服务器，而这里的攻击修改不再通过碰撞逻辑，而是直接修改了游戏对碰撞处理后的结果，比如本来没有攻击命中的，被我修改了攻击坐标，让游戏误认为命中等6. 倍攻：游戏自身在确定攻击发生后，便开始计算攻击所产生的伤害。伤害一般的计算相当复杂，因为涉及到强竞技类游戏，角色的伤害并不固定，他与人物等级，人物属性，加点修为，技能学习程度，武器装备加成，药物特权加成，组队状态加成，游戏buf加成，其他玩家加成，最终计算成了角色最后的实际攻击力。而这里任何一环的状态出现异常，均会导致角色自身倍攻的出现，通过逆向分析玩家攻击力的计算逻辑，篡改或伪造其中一环或多个环节，就很有可能导致倍攻的出现。7. 血量修改：游戏计算结束玩家的攻击力后，会结合攻击对象自身的状态，计算出抗性，最终得到了收到攻击后怪物的血量。通过修改攻击者抗性，或者直接修改最后计算出来的血量，即可到达又一种秒杀和无敌的外挂功能8. 获得技能效果：攻击结束后，部分攻击因为带有特殊持续效果，导致了角色部分buf效果，如飘血，缓速等，外挂了解清楚攻击流程后，可以由上述流程进一步归纳攻击系统中存在的风险点：

攻击系统中涉及到的风险很多，但又因为自身的复杂性，想要通过分析对应逻辑去一一验证风险，显得力不从心。有些读者会想到直接用CE去搜索验证，但CE又能保证验证结论么？举个例子来讲，通过CE搜索到人物的血量为300，直接在CE中修改，发现界面自己的血量变成了999999，可是这个血量你能保证了真实的血量么，你仍然可能被怪物一招KO，此时你又能说明人物的血量计算逻辑是安全的么？ 现如今游戏，人物关键属性，往往在内存中加密后存放，所以你修改到的只是加密血量解密后显示的数值，参与运算的仍然是仅为300的HP，自然而然会被怪物一招KO。通过CE搜索，无法保证数值是界面显示的还是参与运算的，而通过分析逻辑，又会耗费大量的人力时间，所以如何在最短的时间内确定游戏攻击系统是否存在安全风险，是外挂类风险漏洞挖掘最为关注的问题。
我们知道，任何存放在本地客户端的逻辑均不可信，所以验证是否存在外挂类的风险，是需要判断关键的验证逻辑是否存放在本地。而判断的方法可以通过分析协议来具体实现。针对攻击系统的上行，主要分析协议中是否含有攻击信息，如果有，则以修改/重发为主针对攻击系统的下行，主要分析协议中是否含有状态同步信息，如果有，则以修改/屏蔽为主如果没有协议的交互，或协议字段中有关键字段的缺失，那很明显的攻击逻辑全部或部分存在本地，则一定会有对应风险。举例来讲，某FPS游戏在攻击怪物时，当玩家开枪时，触发协议如下：[4A 1F ] 未知[17 51 FF FF ] 攻击者当前坐标x[9D DA FF FF ] 攻击者当前坐标y[C0 E9 FF FF ]  攻击者当前坐标z[DA 00 00 00 ] 攻击者射击朝向x轴偏移[3E 08 00 00 ]  攻击者射击朝向y轴偏移[00 00 00 00 ]  攻击者涉及朝向z轴偏移[03 00 00 00 00 00 00 00 ] 敌方qq号[0E ] 命中部位[00 00 ] 造成的伤害值[3C 52 FF FF ] 被攻击者玩家坐标x[7D DA FF FF ] 被攻击者玩家坐标y[7A 0A 00 00 ] 被攻击者玩家坐标z[00 ] 未知[02 00 00 00 ] 攻击者武器ID这是一个设计存在较为严重缺陷的FPS游戏，从获取的协议解析来看，存在了大量的安全问题。首先协议中包含了攻击者的坐标和攻击朝向，只要这6个字段填充正确，就会出现FPS中的远程攻击同时，攻击协议中，涉及到了枪支的命中部位，只要将命中部位改写为被攻击者的头部，便可实现一枪爆头（如下图，开枪后敌方玩家在基地被一枪爆头击杀）

同时协议中存在造成伤害值的字段，但是笔者修改这个字段后，并未出现倍攻的情况出现，可见服务器还是存在伤害校验的最后，协议中出现了武器ID，如果你使用的手枪，改为狙击枪的ID，就会出现伤害增加的漏洞，这一点服务器并未做校验。由此可见，单单一条攻击协议，就存在很多的安全漏洞。一般验证的思路是通过对敏感字段进行修改，结合客户端的表现确认修改的字段是否有效。当然有些FPS游戏的攻击协议设计的很安全，如基于UE3引擎的一款FPS游戏，在人物开枪的时候，协议交互序列如下：FilterServerStartFireFilterServerRestartFireLoopFilterServerInstantFireSingleImpactFilterServerEndFire分析协议，可以发现，客户端只上报人物开枪的ID，协议中仅仅包含人物的射击方向，这种协议类似与客户端触发的攻击协议，只播放本地动画效果，剩下的计算逻辑，全部在服务器进行。这样的攻击系统，设计较为安全，风险性较低。坐标系统大部分涉及到玩家角色的游戏，都会涉及到人物坐标，角色的坐标可以说是大多数游戏必不可少的一个属性，同样，坐标类问题，也是大部分游戏都存在而且都比较难以解决的一个问题。可以将坐标类问题，划分为以下几种类型：
风险验证思路也和攻击系统类似，通过分析和修改协议字段，确定人物移动的逻辑是否存放在本地，如果是，则一定存在安全风险。与攻击系统不同的是，坐标的上报可能是由客户端自行触发，大量上行去同步玩家当前位置，而移动的有效性，也可能不再是一条协议可以决定，而是多条协议共同作用。于是验证方法上，也和外挂类风险有一定区别，归纳如下：

下面以一款FPS游戏为例分析坐标系统的安全性风险。这款FPS在人物移动时，触发上行协议如下：[45 1F ]协议id[13 51 FF FF ] 人物当前坐标x[19 D7 FF FF ] 人物当前坐标y[5C E9 FF FF ] 人物当前坐标z[3E 08 00 00 ] 含义未知[03 00 00 00 ] 含义未知[FA FF FF FF ] 含义未知[00 00 00 00 ] 玩家的移动速度验证人物是否存在瞬移的情况时，直接修改x, y, z轴坐标，重发上行协议后观察人物是否进行移动，也可以针对协议进行动态修改，如每一次人物移动时，都让x = x+1000，看人物是否在x轴方向上移动出现异常。验证人物是否存在卡图的情况，一种方法是分析游戏的碰撞逻辑，去掉墙壁/边缘检测，另外一种方法是直接锁定人物的坐标，让人物处于墙壁中，地面下。笔者将z轴方向进行改，动，即实现了人物的飞天和遁地。

综上，外挂类风险验证的关键是通过伪造非法协议，去判断游戏的校验逻辑是否存放在本地客户端，如果一旦确认了逻辑在本地，则一定会出现外挂类风险。



*转载请注明来自游戏安全实验室（GSLAB.QQ.COM）
来源：http://www.12558.net
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！