前言

准备来说这个是游戏安全了，安全和测试虽然有部分重合，但因为关注方向和技术栈差异还是蛮大的。
今天参加了看雪 20 周年后，祝看雪越办越好，有点感触，在郑重得吃完一盆东西后，写下这个关于游戏安全的帖子。
当然游戏在安全方向上方方面面，只接触了其他一部分，这里浅谈下这些年的一些小储备，但只讲种类，现在翻新的很快，也不确定是否还实用了。
下面很多都建立在对游戏功能业务十分了解。

客户端反编译

游戏反编译意义有很多，比如是对提取资源，代码以及重新打包。一般公司没有安全防护的找第三方公司，或者公司本身会有安全防护的都会基础的防护手段加壳和资源混淆，用非官方的手段进行编译，并且壳的种类很多，版本也在更新。
如果不加壳，被破解难度会大幅度降低，现在部分壳对游戏影响很小，还有外挂白名单的监测功能。
这里主要防护了代码和资源被破解以及二次打包风险，要获得更多信息得和了解游戏打包的方式，从下文来看，会发现这条作用又多大。

反调式模式

主要是防止进行逆向分析，目前用附加到对应游戏进程上，根据了解去花追踪的辅助工具和 IDA 十分强大，只要有足够的耐心没有什么是不可以调式的。
如果说有的话，可以在断点成功时让游戏直接挂起后退出，so 是否可以选择只被特定进程加载不确定。
为啥要反调式，因为有这个的存在可以完成游戏脱机破解和嗅探出游戏内部的一些关联。

游戏脱机破解

先得确保游戏不被脱壳，得知道协议类型，游戏数据包包头结构和消息体组成，一般进行抓包分析，现在把抓包一段段猜和拼出来的。

逻辑问题

使用游戏设计或者不是实时和数据库和服务器进行同步的功能。
前者比如一些活动设计不合理，被小号撸了羊毛转给大号上，靠封小号不是一回事啊，一开始就得想清楚。
后者比如不要被结合协议一起给做了或者脱离网络完成漏洞的重要环节。

协议安全

也是封包测试的一种，这个也是测试会做的，可以抓包去改，也可以写框架来测试，主要提高协议稳定性和检查服务端校验疏忽，首先也是得防止脱壳。
这里做起来有二个层面和一个和其他用户交互项，判断畸形边界和根据游戏数据类型设计特殊溢出的数字检查回包一个层面。
第二个层面是多次发送后，确定服务端是否有不影响宕机的错误日志，如果错误日志足够多也是可以影响服务器稳定性。
修改数据结构有几种组合（这里面说起来简单，做起来收集数据要沉淀）
fuzz 畸形数据 + 历史问题数据 ；有符号无符号数字的边界和浮点数精度问题；下个协议字段不变，参数和上个协议交换数据（需要动态才行）
最后交互是最难的一种（这个模式手动搞过，但想了下开发到框架内部也不是不行）
交互性完成的协议封包，1 对 n，进行发送不合法广播和发送合法但不该出现的消息，对其他 n 个用户的影响。

内存修改

现在字面值类型在内存中分段已经没啥用了，主要是验证客户端表现和客户端表现问题后是否会影响服务器。
因为有些时候的确修改内存会让金钱数量显示上变成很多或者背包道具叠加异常，服务器不会完全信任客户端。
之前 moba 游戏就有游戏出现修改某个附加装备后，会导致 1 级可以打死 3 级野怪的情况。

硬件变速

加速和变慢速，只要对其他人不公平的都是有影响的，这部分通常是策划层面进行防护，开加速跑路，只能靠检查用户距离最近几次坐标变换速度大于正常全 buff 速度的一定倍数就踢号。

未来需要关注的

1.第一个好像这个和游戏业务确没啥关系，但不得不做啊，随着等保标准的出现有 7 大类，50+ 的检查，对于 app 包做一系列扫描检查工具基本是箭在弦上不得不发。
可以延伸开发出 7-10 个左右的小工具，在定序用持续集成串联起来，下个文章会介绍这些小工具的简要需求和几个点的思路。

2.压测混合会让服务器正常条件下出现错误信息（前提是大部分情况下会 return null 拒绝的）

3.利用正常网络回包的时候修改发包频率的工具，接口或者工具项

4.拿一款修改工具好好二次开发，跟着别人的版本走。

5.关注舆情，检查自家游戏是否被盯上了。