网页游戏的攻击和防御.docxVIP

网页游戏的安全问题，在刚入职接触的时候，写过两篇比较浅显的文章《网页外挂防御有感》和《网页游戏常见外挂原理及防御》。算算时间，距离现在也有 一年多了，虽然页游安全总体上并没有显著变化，没有新的攻击方法，也没有新的防御方法，我个人的工作重心也由页游安全转向了手游安全，但出于完美主义的偏 执，还是希望写一篇覆盖完整的页游安全文章，希望能给页游产业一点帮助。 大纲 —————————————————————————————————————————————————- 一、协议安全（swf安全）：自动封包 （重点） 二、自动游戏+加速 三、内存安全：内存修改 四、存档安全：存档修改 五、帐号安全/充值安全：盗号/低价充值 正文 —————————————————————————————————————————————————- 一、协议安全（swf安全）：自动封包 （重点） 页游，最最核心的就是客户端（swf）与服务端的游戏通信了。游戏通信产生的封包，内容是否可识别，可篡改，可重放，处理逻辑是否有漏洞，都决定了这款游戏是否有重大的漏洞。 我们知道页游前端和后台的通信一般有两者方式，一种是http连接，一种是socket连接，前者适用于小型页游，例如内嵌在QQ平台的QQ农场，后者适用于大型页游。 不同的通信方式，产生的数据包格式也不一样，像HTTP AMF的可以使用charles来抓包查看，像sockets的可以使用WPE抓包查看。 以socket 通信为例，协议采用自定义格式，一般由两部分组成，包头与包体，包头一般是固定长度，包体为可变长度。包头一般是一些基本信息，例如包长度，版本号，命令 号，用户ID，序列号等；包体就是操作命令对应的接收参数，参数个数不同，参数类型不同会导致包体长度不同。 只要摸清楚协议算法，即包是如何生成的，就可以构造数据包与服务器自由通话，这一后果是非常严重的。自由通话意味着你不需要老老实实的在客户端操作，一条数据包就能代替你一连串的操作，例如发送一条数据包完成一个任务，常用于快速升级，淘宝上的页游代练绝大多数都是采用的这种方式；自由通话更意味着你可以绕过客户端的逻辑判断，传任意参数给服务端。说到这里，你可能觉得只要服务端能正常处理来自客户端的参数，不出逻辑错误，不出配置错误，就万事大吉。这种想法很常见，例如上海宝开公司的某个开发就说过，我们的游戏逻辑判断都在服务端，我们没有外挂。我推测这个人应该不怎么上外网。 理想是丰满的，现实是骨感的，怎么能保证后台不将逻辑写错，策划运营不将配置弄错呢，特别是在高强度的通宵加班后。你可能说靠测试呀，中国页游 行业，配给给游戏的测试人员是非常少的，相应的测试时间也是远远不足的，并且测试技术也非常需要提高，总的来说，在页游行业，能做完整协议测试的公司不 多。但玩家，特别是从事外挂制作代练服务的打金工作室会“帮你”好好地彻底地做协议测试。他们会先反编译客户端上的SWF文件（缓存中的，内存中的）得到 协议生成算法，制作成封包工具，遍历每个协议号，每个参数输入，让你的错误无从遁形。 我见过一个非常聪明的外挂制作者，在外挂中添加了脚本分享平台，号召大家共同摸索，将有问题的封包以脚本的方式上传以供大家下载，这种集思广益 真的很妙，脚本的分享会给“找bug”精神奖励，将其帐号公布出来以供大家瞻仰，因此乐意分享的人很多。而且作者还很负责的有脚本审核机制，并支持快捷的 查询。这是什么样的用户体验呀，这就是页游外挂界的app store 看到这里，你或许想，我保护好SWF文件，不让其逆向不就行了吗？有需求，就有满足需求的地方，市面上有不少给SWF提供加密服务的收费产品，例如Amayeta SWF Encrypt 和 DComSoft SWF Protector?，因为收费，没用过这些产品，不知道具体原理，但据了解，最常用SWF加密方式，就是破坏SWF标准文件头，通过向SWF的二进制文件的文件头写入无意义的数据，从而导致反编译软件无法正常解析SWF文件。下图是使用反编译器打开加密的SWF文件，会提示无法解析 我们可以对比一下采用这种加密方式的swf文件头内容： （1）未加密swf文件 正常的SWF文件，文件头部是由一个三字节的标识符开始，为0×46、0×57、0×53（“FWS”）或者0×43、0×57、 0×53（“CWS”）其中之一。“FWS”标识符说明该文件是未压缩的SWF文件，“CWS”标识符则说明该文件前8个字节之后（即文件长度字段之后） 的全部数据为开源的标准ZLIB方式压缩 （2）加密后的SWF文件 很明显，文件头部变成了无意义的符号。 实现函数示例（参考 HYPERLINK /s/blog_731fdd2b01010u9k.html /s/blog_731fdd2b01010u9k