页游安全攻与防
前言
网页游戏的安全问题，在刚入职接触的时候，写过两篇比较浅显的文章《网页外挂防御有感》和《网页游戏常见外挂原理及防御》。算算时间，距离现在也有一年多了，虽然页游安全总体上并没有显著变化，没有新的攻击方法，也没有新的防御方法，我个人的工作重心也由页游安全转向了手游安全，但出于完美主义的偏执，还是希望写一篇覆盖完整的页游安全文章，希望能给页游产业一点帮助。
大纲
一、协议安全（swf安全）：自动封包 （重点） 二、自动游戏+加速 三、内存安全：内存修改 四、存档安全：存档修改 五、帐号安全/充值安全：盗号/低价充值
页游，最最核心的就是客户端（swf）与服务端的游戏通信了。游戏通信产生的封包，内容是否可识别，可篡改，可重放，
处理逻辑是否有漏洞，都决定了这款游戏是否有重大的漏洞。
以socket 通信为例，协议采用自定义格式，一般由两部分组成，包头与包体，包头一般是固定长度，包体为可变长度。包头一般是一些基本信息，例如包长度，版本号，命令号，用户ID，序列号等；包体就是操作命令对应的接收参数，参数个数不同，参数类型不同会导致包体长度不同。
只要摸清楚协议算法，即包是如何生成的，就可以构造数据包与服务器自由通话，这一后果是非常严重的。自由通话意味着你不需要老老实实的在客户端操作，一条数据包就能代替你一连串的操作，例如发送一条数据包完成一个任务，常用于快速升级，淘宝上的页游代练绝大多数都是采用的这种方式；自由通话更意味着你可以绕过客户端的逻辑判断，传任意参数给服务端。说到这里，你可能觉得只要服务端能正常处理来自客户端的参数，不出逻辑错误，不出配置错误，就万事大吉。这种想法很常见，例如上海宝开公司的某个开发就说过，我们的游戏逻辑判断都在服务端，我们没有外挂。我推测这个人应该不怎么上外网。
理想是丰满的，现实是骨感的，怎么能保证后台不将逻辑写错，策划运营不将配置弄错呢，特别是在高强度的通宵加班后。你可能说靠测试呀，中国页游行业，配给给游戏的测试人员是非常少的，相应的测试时间也是远远不足的，并且测试技术也非常需要提高，总的来说，在页游行业，能做完整协议测试的公司不多。但玩家，特别是从事外挂制作代练服务的打金工作室会“帮你”好好地彻底地做协议测试。他们会先反编译客户端上的SWF文件（缓存中的，内存中的）得到协议生成算法，制作成封包工具，遍历每个协议号，每个参数输入，让你的错误无从遁形。
看到这里，你或许想，我保护好SWF文件，不让其逆向不就行了吗？有需求，就有满足需求的地方，市面上有不少给SWF提供加密服务的收费产品，例如Amayeta SWF Encrypt 和 DComSoft SWF Protector ，因为收费，没用过这些产品，不知道具体原理，但据了解，最常用SWF加密方式，就是破坏SWF标准文件头，通过向SWF的二进制文件的文件头写入无意义的数据，从而导致反编译软件无法正常解析SWF文件。下图是使用反编译器打开加密的SWF文件，会提示无法解析
正常的SWF文件，文件头部是由一个三字节的标识符开始，为0×46、0×57、0×53（“FWS”）或者0×43、0×57、0×53（“CWS”）其中之一。“FWS”标识符说明该文件是未压缩的SWF文件，“CWS”标识符则说明该文件前8个字节之后（即文件长度字段之后）的全部数据为开源的标准ZLIB方式压缩
例如下图就是游戏协议对应的命令号
有了好的协议设计，协议是否安全了呢？协议的实现方法在客户端SWF中，这一事实又讲安全问题引回到SWF被逆向的问题上，只要被成功逆向，一切努力都打水漂了。虽然防御艰难，但也不能放弃，一种方法不行，可以用多种方法。总的来说，为了协议安全，可以做如下措施（不仅仅从技术上）：
1.好的协议设计，防重放与篡改 2.SWF加密 ，注意加密算法的安全，最好AS混淆 3.耐心的做协议检测，开发在提交测试前，做协议测试；测试在完成了功能测试，性能测试后也要搞好协议测试；策划运营对配置表做认真的检查； 4.设计一套监控系统，监控游戏中的收益与消费，大量的刷取物品肯定会在数值变化中体现出来； 5.留意游戏论坛，游戏QQ群里是否有新漏洞的披露，外挂是否有更新； 6.频繁更换加密算法，与外挂制作者PK更新速度
（1）模拟键盘
VOID keybd_event( BYTE bVk, // 虚拟键码 BYTE bScan, // 扫描码 DWORD dwFlags, ULONG_PTR dwExtraInfo // 附加键状态 )
（2）模拟鼠标
VOID mouse_event( DWORD dwFlags, // motion and click options DWORD dx, // horizontal position or change DWORD dy, // vertical position or change DWORD dwData, // wheel movement ULONG_PTR dwExtraInfo // application-defined information )
在实施图片验证的时候，要考虑到两个要素：
一是图片是否真正的机器难以识别，要预防简单的像素采集技术； 二是图片库是否及时更新，要预防图片库的遍历。
修改游戏在内存中的数值是经典的单机游戏作弊方法，同样也适用于网页游戏，原因很简单，不可能每个来自客户端的数据，服务端都做验证。（看看页游公司开发前端和后台的比例吧！）以社交类网页游戏为例，其中会内嵌不少小游戏，这些小游戏可能是用来赚取游戏经验或货币等数值的，很显然，这种类型的小游戏基本就是主逻辑在客户端的单机游戏，只是最后将游戏分数上传给服务器，服务器再根据游戏分数的不同来下发相应数额的游戏货币。我们完全可以在积分上传前，在内存中查找并修改该数值。 如下图所示，用cheat engine去查找IE进程中游戏分数。
（cheat engine是我最喜欢的内存修改工具，手游上的内存修改工具和这个比起来简直是胎儿版的。该工具支持自定义格式的内存搜索，具备强大的反汇编功能，更妙的是可以直接生成外挂，特别赞的是竟然采用了游戏通关的方式来教授工具使用，我的博客中有第八关于第九关通关方法）
程序实现一般会有以下几个关键函数
内存修改的防御，有以下几种建议：
随着页游兴起到现在的页游繁盛，依赖于存档进行逻辑判断的设计减少了，但这块也不能完全忽略掉。总会有一些功能是需要调用本地存档的。例如登录模块中，记住密码功能，会将密码信息存储在本地，以IE浏览器为例，在C:\Documents and Settings\（你的Windows用户名）\Application Data\Macromedia \Flash Player\#SharedObjects\（一些随机数字和字母）\ 文件夹下就可以看到存储密码的SOL文件，可以使用minerva工具查看，如下图所示，密码明文明文存储的，SOL文件是永久性保存的，除非手动清除，如果玩家在公共环境下登录，就会有盗号威胁。
也有些开发意识到了这个问题，而采用加密存储方式，一般采用md5（其实md5不是真正的加密算法）。md5解密的在线网站非常多，如下图所示，密码通过两次md5后存储，我们可以在http://www.cmd5.com/ 查到。
所以建议存档加密，采用自定义的加密算法，例如md5后转置再md5，等等。
五、帐号安全/充值安全：盗号/低价充值
帐号安全和充值安全不仅页游如此，所有游戏，甚至所有线上应用都如此。如果说开是个大的话题，我仅仅介绍页游中常见的威胁与防御。
例如下面号称可以无限刷取游戏货币的外挂，实际上在用户输入帐号和密码后，将信息发送给盗号者的邮箱。
防御：
1.安全意识宣传 2.弱口令检测 3.异地登录提醒 4.登录行为监控 5.设计好帐号相关功能，例如申诉流程