从游戏安全的角度我们来看看FPS游戏，这种类型的游戏变态外挂总是层出不穷，如飞天、蹲地、无后座力、加速等等。
那么为什么总是“无法杜绝”这一类变态功能呢？FPS游戏注重游戏体验，游戏公司为了保证玩家的流畅性和打击感，将许多重要数据放在本地客户端进行处理，这就给了外挂开发者有机可乘。
但是随着5G时代的到来，会得到很大的缓解，不过也要考虑到服务器压力。
另外自瞄等算法类功能是永远无法完全避免的，因为他可以单纯的是把人类的算法自动化，精准化而已，虽然看上去功能很BT，但实际上他并不是串改游戏代码或则利用什么BUG。
如果在关键处修改一些逻辑代码，即可实现多样性的变态功能，夸张的说，只有你想不到，没有做不到，如下图变态功能：
例如全屏爆头：
[attachment=10281391]
一个完整的变态功能，往往是由多个功能组合而成，如果想要检测它，不妨分析一下实现原理：
功能一：子弹加速，先前有文章详细讲解，有兴趣的朋友可以翻看之前笔者的发文。
功能二：无需换弹，先前有文章详细讲解，有兴趣的朋友可以翻看之前笔者的发文。
功能三：不难看出，该玩家明明打在空处，却有怪物不断死亡被爆头，应该修改了怪物受伤点相关的代码，或者通过明文发包发送了“打中怪物头部”的封包。
说到木仓木仓爆头，很多人第一反应想到的是自动瞄准。确实，自动瞄准已经司空见惯，几乎所有的fps类型游戏都不可避免受其毒害，也是我们最熟悉的一种恶性外挂。
然而观上面动态图的效果，并非自动瞄准，可以看出明明打在了空处，却有怪物不断死亡，明显修改了客户端逻辑代码。那么今天就跟随笔者一起深入分析“爆头”实现的可能性。
正文：
熟悉fps游戏的朋友，应该都知道“击中部位”，比如击中腿部伤害略低，击中胸部伤害略高，而击中头部几乎就是满血秒杀。从逆向的角度出发，不难想象，游戏人物/怪物模型 在内存中存在着这样一些地址
例：
头部受伤点地址
胸部受伤点地址
手部受伤点地址
腿部受伤点地址
等等。
而这些属性很大的可能是人物/怪物的某个下标，不妨在遍历出对象以后，在对象下进行仔细的观察，说不定有意外的惊喜。
可能有的朋友会问，知道这些有什么用？ fps特性在此不再重复，不明原理的童鞋可以简单粗暴的把fps想象成一个“单机游戏”，既然是“单机游戏”，是不是数据都在玩家电脑上？ 假如将胸部受伤点，强制锁定为头部，是不是击中玩家胸部以后，实际打中的是头部呢？如果将所有的受伤点都遍历出来，全部锁定为头部，是不是可以实现“木仓木仓爆头”？
明白了木仓木仓爆头原理，那么这个全屏打怪又是什么原理？真的是所谓的“子弹追踪”这么厉害吗？其实原理非常简单。人物/怪物模型每个受伤点都有一个“区域”，而这个“区域”有着“大小”属性，而击中模型这块“区域”决定着你打中的是哪里。
例：
头部受伤点地址
下标之一 范围：20
胸部受伤点地址
下标之一 范围：50
手部受伤点地址
下标之一 范围：10
腿部受伤点地址
下标之一 范围：30
知道了“区域大小”这个属性的存在以后，是不是很容易就明白了？将“头部区域”改为特别大的数值，列入原先20，将其改为200，2000甚至更高，是不是不管指哪里，都可打中目标，配合前边分析的木仓木仓爆头原理，即使修改的是其他“区域大小”，也可实现所谓的“全屏追踪爆头”。
那么应该寻找这个受伤点和“区域大小”呢？在cf中，打中人物模型之后，无论是何部位，准星都会变成红色，以此为突破口。
分析工作完毕，接下来就是实践，笔者一项信奉实践是唯一的真理。fps内存数据变化较快，还是老套路，先保存内存，看过先前文章的童鞋此处自动忽略：
OpenProcess () //取得游戏句柄
ZwSuspendProcess（） //通过句柄将其挂起，保存内存状态。
ZwResumeProcess（） //通过句柄恢复挂起，还原内存状态。
CloseHandle （） //释放句柄
首先，击中人物/怪物的一瞬间，也就是准星变成红色的时候，将游戏挂起，保存内存状态，搜索未知的初始值。如下两图：
[attachment=10281392]
在此状态下将其挂起。
[attachment=10281394]
搜索未知的初始值
[attachment=10281395]
恢复内存状态，再次击中（别和上次同一个部位，如上次击中胸部，此时可以选择击中腿部）将其挂起。保存内存状态，搜索变动的数值，由于需要搜索多次，建议拿手木仓或者威力较小的木仓，或者直接在血量较多的模式下搜索，否则容易将对象打死。
[attachment=10281396]
再次挂起，保存内存状态。
[attachment=10281397]
[attachment=10281400]来回重复搜索后，发现某个地址，在击中不同的部位下，数值都不同，且平时为0（空）。直接改这个地址是否可行？其实仔细想想，以这种方式搜索出来的地址，只是击中瞬间读到的“受伤点”而已，修改他并没有什么效果，真正的受伤点地址，是不会因为被打中而发生变化（猜测：可能会因为人物移动 跳跃下蹲等发生变化），那我们这么幸苦的搜索，有何意义？ 得到了这个“受伤点相关”的值以后，是不是给他进行范围搜索？先遍历出当前人物/怪物的对象，在对象地址一定范围内进行搜索，结果一幕了然，搜索出的地址就一个，不妨大胆猜测，是不是就是上面分析的“区域大小”呢？
如实验的怪物对象名称是“古代老鼠”，地址处于对象下标（值得注意，怪物和人物不处于同一遍历下） 0x354 处，原有值为 15（float），将其修改为200（float），发现在游戏中并没有实际效果，说明该地址也不是真正的“受伤点”，而用CE查看访问代码的时候，却发现在不停的访问，证明与其他地方有关联。
那么尝试去去OD中下硬件写入断点，来到了一个类似于“数组”的地方，如下图，eax来源于[esp+0x3954],esp来源于一个基地址（防止他人恶意用途，基址不进行截图）。
[attachment=10281400]
且在该地址+4，+8等处，都是相似的（float）值，如下图：
[attachment=10281405]
那么再次尝试将其修改锁定为200（float），这次终于了有实际效果。
（注意：截图中是以人物模型为例，怪物模型方法同上）
[attachment=10281406]
只要准星在该类型怪物附近（不用瞄准），都可打中怪物，且木仓木仓爆头，说明该处为怪物的“头部受伤区域”，而在+4的位置修改为200，也可打中怪物，不过失去了原有的爆头效果，猜测可能为胸部或腿部“受伤区域”。
而一个图内，不可能只有一种怪物，也会有BOSS和其他一些小怪，想要实现木仓木仓爆头，必须每种怪物都修改“受伤区域大小”，仔细观察该地址附近，寻找是否有（float）值（从正向角度出发，一般坐标类型的，以浮点可以表达的更加精准），都进行一个尝试性的修改，如地址附近 [基址]+0x35690 的位置，发现的类似的浮点，修改后发现为“滚球”的怪物头部受伤点区域，而要将每一种怪物都找出来，就需要一定的时间和耐心了。
多观察附近地址，说不定有意外惊喜。单浮点十六进制多以0x4开头
[attachment=10281407]
小结：该游戏将模型“受伤点区域大小”这一属性，存放到了相同的遍历下，通过ID在某处进行了一个关联，而不是在对象之下。
游戏安全防护和反外挂建议：
1.对容易被串改的代码进行CRC验证以及CRC的CRC。
2.除了本地加一定的检测（CRC之类的）之外，服务器可以判断爆头率和子弹射速，虽说fps实时检测会影响玩家体验，但却可以进行数据回扫，如玩家打完一局之后，进行该对局数据回扫，判断其战绩（检测爆头），以及流量监控（加速类功能会大量给服务器发包）。
3.检测鼠标轨迹和鼠标速度，没有哪个变态家伙是可以每次都瞬间直线滑动鼠标进行精准爆头的。
4.通过玩家的举报进行精准确认。
本文到此结束。下次同笔者一起分析FPS最大的毒瘤——透视自瞄原理。
