后台运行手机页游-网页游戏安全攻防、SWF加密与隐藏密钥

原文链接：

页游的核心是客户端（swf）与服务端的游戏通信。 游戏通信产生的数据包，内容是否可识别、可篡改、可重放，处理逻辑是否存在漏洞，都决定了游戏是否存在重大漏洞。

关于网页游戏的安全问题，我刚接触公司的时候，写过两篇比较简单的文章。 虽然网页游戏安全总体上没有太大变化，但是没有新的攻击手段，也没有新的防御手段。 我个人的工作重心已经从页游安全转移到了手游安全，但是出于偏执的完美主义，我还是希望能写一篇完整的页游安全文章，希望能给页游行业一点帮助。

1.协议安全（swf安全）：自动封包（重点）

页游的核心是客户端（swf）与服务端的游戏通信。 游戏通信产生的数据包，内容是否可识别、可篡改、可重放，处理逻辑是否存在漏洞，都决定了游戏是否存在重大漏洞。

我们知道，网页游戏前后端通信一般有两种方式，一种是http连接，一种是连接，前者适用于小型网页游戏，比如QQ农场内嵌QQ平台，后者适合大型网页游戏。

不同的通信方式产生不同的数据包格式。 比如HTTP AMF可以用来抓包查看，类似的可以用来WPE抓包查看。

以通信为例，协议采用自定义格式，一般由两部分组成，和body。 头部一般是固定长度的，主体是可变长度的。 数据包头一般包含一些基本信息，如数据包长度、版本号、命令号、用户ID、序列号等； 包体为操作命令对应的接收参数。 不同的参数个数和不同的参数类型会导致不同的包体长度。

只要了解协议算法，即数据包是如何产生的，就可以自由构造数据包，与服务器通信。 这个后果很严重。 免调用就是不需要老老实实在客户端操作，一个数据包就可以代替你的一系列操作，比如发送一个数据包完成一个任务，常用于快速升级。 淘宝上的页游代练大多采用这种方式； 自由调用是指可以绕过客户端的逻辑判断，向服务端传递任意参数。 说到这里，你可能会想，只要服务端能够正常处理来自客户端的参数，没有逻辑错误或者配置错误，就万事大吉了。 这种想法很普遍。 比如上海宝开的一位开发者说，我们的游戏逻辑判断都是在服务器端，我们没有外挂。 我推测此人应该不太会上网。

理想很丰满，现实很骨感。 怎么保证后台不把逻辑写错，规划运维不把配置弄错，尤其是加班加点后。 你可能会说这取决于测试。 在中国页游行业，分配给游戏的测试人员很少，相应的测试时间远远不够，测试技术也有待提高。 一般来说在页游行业，能做完整协议测试的公司并不多。 但玩家，尤其是从事外挂制作和代练服务的大金工作室，会“帮你”做一次彻底的协议测试。 他们会先在客户端（缓存里，内存里）反编译SWF文件，得到协议生成算法，做成打包工具，遍历每一个协议号，输入每一个参数，让你的错误无处遁形.

我见过一个很聪明的插件制作者，在插件中加入了一个脚本共享平台，号召大家一起探索，将有问题的包以脚本的形式上传，供大家下载。 这种头脑风暴真的很精彩。 分享会奖励“找BUG”的精神，还会公布账号供大家欣赏，所以很多人都愿意分享。 并且作者还负责脚本审核机制，支持快速查询。 这是一种什么样的用户体验？ 这就是网页游戏外挂界的应用商店

看到这里，你可能会想，我是不是可以保护SWF文件，不让它被逆转呢？ 哪里有需求，哪里就有满足需求的地方。 市面上有很多付费产品为SWF提供加密服务，比如SWF、SWF等。 因为收费，我从来没有用过这些产品。 具体原理我不知道，但据我所知，SWF是最常用的。 加密方式是破坏SWF标准文件头，在SWF二进制文件的文件头中写入无意义的数据，使反编译软件无法正常解析SWF文件。下图是使用反编译器打开加密后的文件SWF文件，会提示无法解析

我们可以通过这种加密方式对比一下swf文件头的内容：

(1)未加密的swf文件

对于一个普通的SWF文件，文件头以一个三字节的标识符开始，标识符为0x46、0x57、0x53（“FWS”）或0x43、0x57、0x53（“CWS”）其中之一。 “FWS”标识表示该文件为未压缩的SWF文件，“CWS”标识表示文件前8字节后（即文件长度字段后）的所有数据均采用开源标准压缩ZLIB 方法。

(2) 加密后的SWF文件

显然，文件头变成了一个无意义的符号。

实现功能示例（参考）

有加密就有解密。 需要恢复加密的 SWF 文件。 虽然加密后的SWF文件无法反编译，但是可以通过反编译解密后的文件，找到解密代码来恢复加密后的SWF文件的文件头。 （参考）

显然，这种SWF加密方式是行不通的。 于是大家想到了如何用一种不能反编译的实现方式来隐藏加密算法，比如利用C/C++代码可以编译成AS字节码但不能反编译的特性来隐藏加密算法。 其实我怀疑有工具会还原成C，比如ASV(view 2012)号称是目前最强大的SWF解密工具，网上也有这个工具的团购消息。

SWF的加解密我不懂，但是我知道有一个普遍的规律，任何加密在内存中都是处于解密状态。 无法解密时，从内存中搜索导出。 我们可以先用SWF从浏览器内存中导出解密解压后的SWF文件，然后用流传很广的硕思SWF反编译源码。 这种做法对于游戏协议安全来说是非常非常非常悲惨的。 如下图，通过对SWF文件进行逆向解密，可以得到包的组成结构和包中各个字段的生成算法！

例如下图是游戏协议结构

比如下图就是游戏协议对应的命令号

比如下图就是游戏配置表

一切都注定要彻底解决协议安全问题，只能靠AS混淆。 目前有一些付费软件提供AS混淆，eg。 但奇怪的是，并没有多少页游公司实现AS混淆。

写到这里，你可能会想象，游戏协议的算法不会被逆向工程知道，那不就游戏结束了吗？ 还是那句话，现实是残酷的，即使不知道协议算法，也可以修改游戏包。 通过耐心、反复的操作，我们可以比较数据包的差异，找到修改点。 一般使用WPE工具修改包体。 WPE工具的关键是过滤器，它找到匹配指定特征的数据包，并用修改后的值替换特定位置。 如下所示，

除了数据包篡改之外，避免甚至猜测数据包结构的最简单方法是通过数据包重播来作弊。 比如打怪的包。 只要反复重放数据包，就能轻松赚取经验值。

一个好的协议设计必须考虑防止数据包篡改和数据包重放。 最简单的方法是在数据包的某个字段中添加一个序列号。 序号包括包体的完整性校验值和区分包是否被重放或篡改的时间因子值。

协议设计的好，协议安全吗？ 协议的实现方法在客户端SWF中。 这一事实将安全问题带回了 SWF 被逆转的问题。 只要成功逆转，一切努力都将白费。 防守虽难，但也不能轻言放弃。 如果一种方法不起作用，可以使用多种方法。 一般来说，对于协议安全，可以采取以下措施（不仅仅是技术上的）：

1. 良好的协议设计，抗重放和篡改

2.SWF加密，注意加密算法的安全性，最好混淆AS

3、耐心做协议测试。 提交测试开发前，做协议测试； 测试完成功能测试和性能测试后，还要做好协议测试； 规划和运行时应仔细检查配置表；

4.设计一个监控系统，监控游戏中的收入和消费。 大量刷取物品肯定会体现在价值变化上；

5、关注游戏论坛，游戏Q群是否有新的漏洞披露，插件是否更新；

6、加密算法更替频繁，更新速度与插件厂商相比。

2.自动游戏+加速

自动游戏，简单的说就是在游戏UI上模拟鼠标或者键盘的操作，代替你去做重复性的工作。 使用按钮向导可以制作最简单的自动游戏脚本。 先把正常的操作录下来，然后编辑，设置热键，最后回放。程序实现一般有以下几个关键功能

(1) 模拟键盘

空白 （

BYTE bVk, // 虚拟键码

BYTE bScan, // 扫描码

双字，

// 附加键状态

)

(2) 模拟鼠标

空白 （

DWORD , // 并单击

DWORD dx, // 或

DWORD dy, // 或

DWORD, // 车轮

//-

)

自动游戏的作弊方式在战斗刷怪游戏中很常见。 自动识别地图上怪物的位置，自动移动打怪，自动拾取掉落的宝物。 常与加速插件配合使用。 总的来说，就是靠实现那种不知疲倦（脚本操作）、精准（自动识别地图中的UI特征）、快速（网页游戏加快flash动画播放速度）的操作方式来快速升级。

自动游戏类作弊的防御比较简单，加入人机识别因素，类似避免在论坛批量注册，使用只有人才能识别的验证码（题外话，很多网站的验证码其实都是机器可以识别的)，例如对于游戏，记录每场的频率和操作时间特征，异常操作弹出图片验证，中断自动游戏。

在实现图像验证时，应考虑两个要素：

一是图片是否真机识别难度大，要杜绝简单的像素采集技术；

二是图片库是否及时更新，需要防止图片库的遍历。

加速作弊在对战游戏中也很常见。 改变运行速度有两种情况。 一种是使用变速齿轮等加速插件来加快flash动画的播放速度，另一种是修改游戏中某个变量值对应的速度值。

对于加快flash动画播放速度的加速插件，我们可以通过比较客户端和服务端的时间是否同步来检测。 当检测到异常时，可以弹出图片验证，中断加速。

对于在游戏中通过数值控制速度的，保证协议安全，使数据包中对应的数值无法更改； SWF要做好防逆向保护，不能修改源码中的控速逻辑。

3. 内存安全：内存修改

修改内存中的游戏值是单机游戏的经典作弊手段，同样适用于页游。 原因很简单。 服务器不可能验证来自客户端的每一个数据。 （看看网页游戏公司开发的前后端比例！） 以社交网页游戏为例，里面会嵌入很多小游戏。 这些小游戏可用于赚取游戏经验或货币。 显然，这类小游戏基本上是一个单机游戏，主要逻辑在客户端，只是在最后将游戏分数上传到服务器，服务器再根据游戏得分的差异。 我们可以在点上传前在内存中查找并修改这个值。 如下图，在IE进程中使用cheat查找游戏分数。

（cheat是我最喜欢的内存修改工具，和手游上的这个内存修改工具相比，简直是胎儿版，这个工具支持自定义格式的内存查找，强大的反汇编功能，更棒的是可以直接生成插件-in，特别好的是游戏通关的方式用来教工具的使用，我的博客有关于第九关通关方式的第八篇）

程序实现一般有以下关键功能

(1) 读取过程数据

(2)搜索，搜索算法可以根据值类型、扫描类型和内存扫描方式来实现

比如数值类型有二进制、1字节、2字节、4字节（游戏中最常用）、8字节、浮点数、双精度浮点数、文本、字节数组、自定义（这个最好）；

例如扫描类型可以支持精确搜索、模糊搜索（大于...，小于...，介于两者之间），数值变化趋势（数值递增，数值递减，数值没有变化，和第一次扫描的值一样，增加一个指定值，减少一个指定值）；

比如内存扫描方式有自定义的扫描起始地址和结束地址，同时扫描只读内存，深度扫描，快速扫描，扫描时暂停游戏

(3) 写入数据

内存修改的防御有几个建议：

(1) 重要数值被拆分存储在内存中，无法轻易定位（这会使游戏逻辑复杂化）

(2)默认可以修改，收益在服务器端控制。 （考虑到成本，是目前主流的控制方式）

4.档案安全：档案修改

在flash单机游戏时代，修改本地存档文件是游戏作弊的重要手段。 相信很多人都用过Flash存档修改器。

随着页游的兴起到现在页游的繁荣，依赖存档进行逻辑判断的设计有所减少，但这部分也不能完全忽略。 总会有一些函数需要调用本地存档。 例如在登录模块中，记住密码功能会将密码信息存储在本地。 以IE浏览器为例，在C:\和\(你的用户名)\Data\\Flash\#\(一些随机数和字母)\文件夹下，可以看到存放密码的SOL文件，可以使用工具查看一下，如下图所示，密码是明文存储的，SOL文件是永久保存的，除非手动清除，如果玩家在公共环境下登录，会有被盗号的威胁。

一些开发者也意识到这个问题，采用加密存储，一般使用md5（其实md5并不是真正的加密算法）。 网上有很多md5解密的网站，如下图，密码是经过两次md5后保存的，我们可以在这里找到。

所以建议对进行加密，使用自定义的加密算法，比如md5，然后再md5，等等。

5. 账户安全/充值安全：盗号/低价充值

账号安全和充值安全不仅适用于网页游戏，也适用于所有游戏乃至所有在线应用。 如果是大话题，我就只介绍网页游戏中常见的威胁和防御。

（一）账户安全

威胁：

1. 账号盗用

比如下面这个号称可以无限获取游戏币的插件，实际上是在用户输入账号和密码后，将信息发送到账号黑客的邮箱。

2. 社工盗号

在游戏中获取信任，盗取账号作为引诱对方代练等利益。 或者通过获取个人信息，黑客从保密问题入手。

3、从游戏账号管理中心等门户网站入手破解账号。

比如登录模块没有验证码或者验证码实现机制存在漏洞，使用字典扫描批量破解

4.传输嗅探黑客

5.利用账号申诉流程漏洞盗号

例如，在一些投诉评分机制中，有提供多个充值凭证后找回密码的方式，先充值，再破解账号。

防御：

1. 安全意识提升

2.弱口令检测

3.远程登录提醒

4.登录行为监控

5.设计账户相关功能，如申诉流程

(2) 充值安全

威胁：

1.社工

在网上发帖，谎称发现充值漏洞，骗取贪心网友为其指定账户充值

2.利用手机充值漏洞

使用即将过期的手机卡充值，大部分充值不会再次检测手机卡是否存活

3.利用宽带充值漏洞

盗用宽带账号充值，由于实际上不会影响游戏收益，最多是在受害人损失严重时，受害人投诉造成的不良影响。

4.真正的充值漏洞

比如现在广泛使用的点卡充值，就可能存在点卡被重放的漏洞。

防御：

1. 安全意识提升

2、充值相关功能的安全检查

综上所述

一般来说，页游的各种外挂问题非常普遍，部分端游也有，但安全防御不如端游。 这很大程度上是因为页游的开发周期短、生命周期短，比如更长的神仙道游戏页只有两年的历史，甚至大部分页游也只是在短时间内洗用户、盗钱。时间，所以他们不会在外挂防御上投入人力物力。 也许第三方安全服务会有市场，比如说他们很乐意购买支持多个项目的 AS 混淆工具。 总之后台运行手机页游，页游是一个浮躁的市场，只有生命周期强的游戏才会注意到作弊问题。

================================================ ================================================ ==== ========================

SWF加密的隐藏密钥

本片博文介绍的加密方式是最基本的隐藏密钥的加密方式。 当然这种加密方式目前也是可以破解的。 （对于公共的swf文件，如果adobe不提供支持，多数情况下swf加密是徒劳的），本文只是对swf加密方式的整理，分享一种思路。 如果您是swf加密专家，期待与您交流，

钥匙隐藏

破坏swf标准文件头是最简单也是最常用的方法。 向swf二进制文件的文件头写入无意义的数据，会导致破解软件无法正常解析swf。

如图，在core.swf的起始位置写入无意义的数据，

这样做的原理是swf文件的前几位代表swf的版本信息，以及解析swf所需要的参数数据。 如果修改成无意义的数据，反编译器自然无法解析。 当然，如果你这样做了之后后台运行手机页游，也会导致core.swf在运行时无法解析，

俗话说，加密和解密一定是一对同时存在的好朋友。 所以我们需要在core.swf加载后恢复损坏的文件头，需要像加载普通.swf一样加载加密后的swf，并恢复加载的swf文件头。代码如下

由于众所周知的原因，这样做只能防君子不能防小人，无异于增加破解者的工作量。 破解者不能直接反编译core.swf，但是可以通过破解.swf找到解密代码（如上图红框内的数字7明文存放在.swf中），还原core.swf 的文件头。 然后继续用反编译软件反编译，

以上就是关于：后台运行手机页游-网页游戏安全攻防、SWF加密与隐藏密钥的相关内容，更多精彩请继续关注玩手游。