游戏安全

前几天朋友让我帮忙破解一个游戏，奈何我太菜，Failed Over。

不过，在这个过程里还是学到了很多东西。现在把笔记放上来，为了以后自己查阅方便，也为了更多人有方法可循。

在此感谢知乎和游戏安全回答下的各位老大哥。Respect !

网页游戏破解

1.远程文件引入

网页游戏的研发，常用框架来做。即request 的参数，作为请求文件名的一部分来使用

2.SQL注入

注入原理方式和普通web操作无差别。但是在使用request来的参数时，过滤处理即可。

但往往研发会忽略请求参数过滤。所以，防御方式做过虑处理，或者SQL预编译。

• 待查：AMF消息 ，后端pinta模拟操作，请求接口，参数构造，webgame架构 ,数据存储用Nosql，(java/c/c++的游戏数据直接在内存中操作，游戏关服才写到DB)

3.通讯协议与消息格式

网页游戏的通讯协议并非全是http,也有很多用socket，以及http+socket并用/http+amf消息格式的做法。

• http与https的取舍上，后者ssl启用后，大量ssl解密加密运算，势必增加服务器大量cpu压力。

• socket在游戏中，除了聊天应用，在组队、帮派战等需要多玩家指尖同步数据信息

• socket作为所有业务传输的协议时，协议格式一般都是开源。比如msgpack、protobuf、及自定义的协议。（自定义协议，务必检测整个消息包的每一个参数，类型范围，避免个别超大数值，边界数值出现，导致主程序内存越界，以至于服务宕机）

1. 金币复制&整型溢出

• 金币数按日成指数增长，2^32=2147483647 . 同时在java中,4字节的存放Int型变量的范围是 -2147483648至2147483647. 在java/c的有符号Int行存储时，数的最高位描述符号位属第32个位置。所以，实际范围为2^31个。

• C中使用无符号数值类型，即可完成数值类型溢出刷钱行为，但在java中，好像没有无符号的类型。

• 所以在游戏业务中，先做大小判断，再做正正相加，不能得负。负负相加，不能得正,来判断是否发生溢出问题。

1. 金币复制&并发请求

Rpg类型的网页游戏中，多数都有道具出售的功能。当玩家同时针对买入卖出时，瞬间大量并发请求，在服务器的处理逻辑一般有两个进程处理。共享数据分别给数据库中对应的账户余额表。

• 当数据库发生并发操作时，无论最后哪个进程写入余额，都是错误结果。

• 考虑找资料研究一下多种事务同时操作修改多个表的多条记录时容易发生的死锁问题。

6.金币复制&逻辑漏洞

• 研发的逻辑不严谨。如DNF漏洞新闻（《利用网游漏洞狂刷游戏币赚钱 玩家自爆三天赚十七万》）

1. 道具复制&背包整理

类比刚才金币的读入与写入问题。穿装备与整理包裹的请求并发。

• 查cgi线程的内存存放。

• java/c的程序，数据放入内存的游戏。锁等待问题（锁等待造成的线程占用阻塞后面请求的处理，堆积大量请求导致系统负载升高服务器繁忙无法响应）--------------+ ★ 他团队解决：用户并发请求锁

• 查nosql的K-V形式结构、redis的setnx接口

• 查 利用锁的过期时间和nosql的过期机制实现用户解锁。

8 . 类CC攻击&多用户共享资源锁的timebomb

• redis 没有成熟的事务处理机制，watch算不上关系型数据库中的事务处理。对此，更需要对表进行加锁解锁。

• java之类的语言项目很多是直接操作内存的，更是需要资源锁，来解决并发问题。（多个请求操作同一份数据的问题）

• 使用json消息格式的webgame要注意，php只是在接收请求时，做了大量数量的限制。在json解码之后的数据中，是没有处理的。

1. 日志

所有操作必须写入日志，当安全事件发生后，可以作为各种数据回滚，交易纠纷处理的可靠数据。

1. 协议与外挂

网页游戏意味着，网页用的是浏览器。而浏览器支持普通的http协议的基本网页数据通讯，支持以socket协议的flash插件或者java Applet 实现，以及unity 3D开发的游戏。

• flash的源码很容易逆向出来，之后 通讯协议的消息格式也是一览无余。

• 定时更换通讯密钥，防外挂

• 游戏内部机制限制

• 人肉判断，验证码

1. 道具移动业务

从A位置移动到B位置，若两者是同一类型，且可叠加，则叠加数量到其中一个上，并且销毁另一个。

Hacking 角度

• 游戏网页分为 flash 游戏和html游戏

• flash 游戏与服务端通信的消息格式有两类：

  1. flash特有的amf消息格式。

  此格式可逆，一般外挂就会逆出这个格式然后自动化

  1. http协议 ，导致的服务端安全问题和普通的网站基本没有什么区别

     因为此时服务器是nginx,lighttp,apache,tomcat之类，

     服务端语言是 php, java，python 之类的。

• 有些flash游戏，相关逻辑在客户端进行，缺乏服务端验证。反编译出源码很容易，比如用swfscan，很多时候的攻击直接在浏览器中间人抓包拦截就更容易。

• html游戏

  1. 和服务端通信就是http了。如果用html5，也许会用websocket。不过由于是http协议，所以服务端安全问题和普通网站无区别。

  2. 由于是html , 所以在客户端上还可能出现XSS,CSRF等问题。

     这类客户端安全问题可能导致用户账号被劫持等问题。

网页游戏角度

在防御入侵，钓鱼，外挂等安全方面，由于网页受Web环境的限制，不太可能使用变态的通讯加密手段。大部分网页游戏还是都是纯 HTTP API 的形式，没有加密和混淆，容易抓包然后写出脚本类。

• 大部分网页游戏没有使用ssl,在不受信任的网络中很容易被抓包，窃取敏感数据，或者钓鱼。

• 另外网页游戏由于技术门槛低，在服务器的维护工作上不如客户端网游的服务器那么正规，容易出现疏忽。而且网页游戏的服务器可能会用知名的软件如Nginx等，和编程语言及框架，相比于完全自行编写的客户端网游服务器，出现通用的漏洞的可能性比较大。

Another harvet

通讯协议

• HTTP通讯可以采用 xml 或者 json,在通讯的可读性上非常方便，但是缺点是在通讯中占据了多余的带宽。

• socket 通讯协议在可读性上比http差太多。但只要前后端在协议的封装上做好了，遇到问题也很容易解决。

• HTTP协议在底层也是基于TCP/IP，但在单台机器上，socket明显要比http快，这也降低了web单台服务器的瓶颈以及多线程问题。

游戏安全

• 游戏的基本数据多是保存在内存中的，玩家上线加载，存储分为三种

  （离线存储，定时周期存储，直接存储）

• 对于socket的协议来讲，SQL注入的问题可以忽略，因为是对内存数据的操作，所以不会对外来数据影响

推广类小游戏

• 开发周短，又考虑被禁封。所以通常直接使用html5的网页开发。计算逻辑通过前端实现。

  但 前端代码很难加密。