原文链接：http://netsecurity.51cto.com/art/201211/364775.htm
页游，最最核心的就是客户端（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文件
很明显，文件头部变成了无意义的符号。
实现函数示例（参考http://blog.sina.com.cn/s/blog_731fdd2b01010u9k.html）
有加密就有解密，加密的SWF文件需要还原，虽然反编译不了加密后的SWF文件，但可以反编译解密文件找到解密代码来还原加密SWF文件的文件头。（参考 http://www.2cto.com/Article/201211/167406.html ）
很明显，这种SWF加密方法没什么作用。于是大家想着如何用一种无法反编译的实现方法来隐藏加密算法，例如利用Alchemy能够编译C/C++代码为AS字节码但无法被反编译的特性来隐藏加密算法。其实我怀疑目前有工具将Alchemy还原成C了，例如ASV（actionscript view 2012)就号称是目前最强悍的SWF解密工具，网上都有该工具的团购消息了。
我不懂SWF的加密解密，但我知道有一条万能守则，任何加密在内存中都是解密状态的。当无法解密的时候，就从内存中查找导出吧，我们可以先使用SWF Memory Dumper从浏览器内存中导出解密并解压缩的SWF文件，再用传播程度都烂大街的硕思闪客反编译得到源码。这一方法对游戏协议安全来说，是非常非常非常悲剧的。如下图所示，包的组成结构，包中各个字段的生成算法都可以通过逆向解密SWF文件获得！
例如下图为游戏协议结构
例如下图就是游戏协议对应的命令号
例如下图为游戏配置表
一切的一切，都注定了要想完全解决协议安全问题，只有靠AS混淆了。目前有一些收费软件提供AS混淆，例如secureSWF 。但奇怪的是，没有多少页游公司实施AS混淆。
写到这里，或许你会幻想游戏协议算法不会被逆向得知，那不就完事大吉了吗？再次申明，现实是残忍的，即使不知道协议算法，照样可以修改游戏封包。我们可以通过耐心的反复操作来对比封包的不同，定位到修改点。一般使用WPE工具，修改包体。WPE工具的关键就是过滤器，查找到符合指定特征的封包，将特定的位置替换为修改的值。如下图所示，
除了封包篡改，最简单的连封包结构都不要猜测的就是封包重放作弊了，例如打怪是一条封包，只要反复重放该封包，就能轻易刷取经验值了。
好的协议设计，一定要考虑到防御封包篡改和封包重放，最简单的方法是在封包的某个字段加入一个序列号，该序列号包含包体完整性检验值，时间因素值，来区分封包是否是重放的，是否有被篡改。
有了好的协议设计，协议是否安全了呢？协议的实现方法在客户端SWF中，这一事实又讲安全问题引回到SWF被逆向的问题上，只要被成功逆向，一切努力都打水漂了。虽然防御艰难，但也不能放弃，一种方法不行，可以用多种方法。总的来说，为了协议安全，可以做如下措施（不仅仅从技术上）：
1.好的协议设计，防重放与篡改
2.SWF加密 ，注意加密算法的安全，最好AS混淆
3.耐心的做协议检测，开发在提交测试前，做协议测试；测试在完成了功能测试，性能测试后也要搞好协议测试；策划运营对配置表做认真的检查；
4.设计一套监控系统，监控游戏中的收益与消费，大量的刷取物品肯定会在数值变化中体现出来；
5.留意游戏论坛，游戏QQ群里是否有新漏洞的披露，外挂是否有更新；
6.频繁更换加密算法，与外挂制作者PK更新速度。
二、自动游戏+加速
自动游戏，简单的说就是模拟鼠标或键盘对游戏UI的操作，代替你做重复的工作。最简单的自动游戏脚本可以使用按键精灵来制作，先对正常操作进行录制，然后编辑，设置热键，最后回放即可。程序实现中一般会有以下几个关键函数
（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
)
自动游戏的作弊方式常见于对战刷怪类游戏，自动识别地图中怪物出现的位置，自动出招打怪，自动拾取掉落宝物。往往还会配合加速外挂，总的来说，就是靠达成那种不知疲倦（脚本操作）、准确度高（自动识别地图中UI特征）、快速（对页游就是加速flash的动画播放速度）的操作方式来快速升级。
自动游戏类型外挂的防御比较简单，增加人机识别的因素，类似于论坛避免批量注册，采用只有人类才能识别的验证码（题外话，不少网站的验证码其实可以机器识别），例如对于对战类游戏，记录每次对战的频率和操作时间特性，对异常的操作弹出图片验证，中断自动游戏。
在实施图片验证的时候，要考虑到两个要素：
一是图片是否真正的机器难以识别，要预防简单的像素采集技术；
二是图片库是否及时更新，要预防图片库的遍历。
而加速外挂，也常见于对战类游戏。改变操作速度有两种情况。一种是使用变速齿轮之类的加速外挂加快flash动画播放速度，一种是速度值为游戏中的某个变量值，修改了对应的数值。
对于加快flash动画播放速度的加速外挂，我们可以通过对比客户端服务端时间是否同步来检测，当检测到异常的时候，可以弹出图片验证，中断加速。
对于速度由游戏中数值控制的，做好协议安全，使其无法改封包中对应的数值；做好SWF反逆向保护，使其无法修改源码中控制速度的逻辑。
三、内存安全：内存修改
修改游戏在内存中的数值是经典的单机游戏作弊方法，同样也适用于网页游戏，原因很简单，不可能每个来自客户端的数据，服务端都做验证。（看看页游公司开发前端和后台的比例吧！）以社交类网页游戏为例，其中会内嵌不少小游戏，这些小游戏可能是用来赚取游戏经验或货币等数值的，很显然，这种类型的小游戏基本就是主逻辑在客户端的单机游戏，只是最后将游戏分数上传给服务器，服务器再根据游戏分数的不同来下发相应数额的游戏货币。我们完全可以在积分上传前，在内存中查找并修改该数值。 如下图所示，用cheat engine去查找IE进程中游戏分数。
（cheat engine是我最喜欢的内存修改工具，手游上的内存修改工具和这个比起来简直是胎儿版的。该工具支持自定义格式的内存搜索，具备强大的反汇编功能，更妙的是可以直接生成外挂，特别赞的是竟然采用了游戏通关的方式来教授工具使用，我的博客中有第八关于第九关通关方法）
程序实现一般会有以下几个关键函数
（1）读取进程数据ReadProcessMemory
（2） 查找，查找算法可以按数值类型、扫描类型及内存扫描方式来实现
例如数值类型有二进制，1字节，2字节，4字节（游戏最常用），8字节，浮点数，双浮点数，文本，字节数组，自定义（这个最牛）；
例如扫描类型可以支持精确查找，模糊查找（比...大，比...小，两者之间），数值变化趋势（数值处于增加中，数值出于减少中，数值没有变动，与首次扫描数值相同，数值增加了某个指定值，数值减少了某个指定值）；
例如内存扫描方式有自定义扫描起始与终止地址，同时扫描只读内存，深度扫描，快速扫描，扫描时暂停游戏
（3）写数据WriteProcessMemory
内存修改的防御，有以下几种建议：
（1）重要数值在内存中拆分存放，使其无法简单定位到（会使得游戏逻辑变复杂）
（2）默认可以修改，在服务端控制收益上线。（考虑到成本，为目前主流控制方法）
四、存档安全：存档修改
在flas在flash单机游戏时代，修改本地存档文件，是游戏作弊的重要方式，相信有不少人就用过Flash存档修改器。
随着页游兴起到现在的页游繁盛，依赖于存档进行逻辑判断的设计减少了，但这块也不能完全忽略掉。总会有一些功能是需要调用本地存档的。例如登录模块中，记住密码功能，会将密码信息存储在本地，以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.从游戏的帐号管理中心等web入口下手，进行盗号。
例如登录模块没有验证码或验证码实现机制漏洞，使用字典扫描批量盗号
4.传输嗅探盗号
5.利用帐号申诉流程漏洞进行盗号
例如有些申诉打分机制存在提供多次充值证明就可以取回密码的方式，先充值，再盗号。
防御：
1.安全意识宣传
2.弱口令检测
3.异地登录提醒
4.登录行为监控
5.设计好帐号相关功能，例如申诉流程
（二）、充值安全
威胁：
1.社工
在网上发帖慌称发现充值漏洞，骗取贪心网友给自己指定的帐号进行充值
2.利用手机充值漏洞
使用快过期的手机废卡进行充值，大多数的充值不会再次检测手机卡是否存活状态
3.利用宽带充值漏洞
盗取宽带帐号进行充值，由于不会实际影响游戏收益，顶多会出现受害者损失严重的情况下投诉带来的不好影响。
4. 真正的充值漏洞
比如说广泛采用的点卡充值，可能存在点卡被重放使用的漏洞
防御：
1.安全意识宣传
2.充值相关功能的安全检测
结论
总的来说，页游的各种外挂问题很普遍，端游有的它都有，但安全防御不如端游，这很大程度上是因为页游的开发周期短，生存周期也短，例如较长的神仙道游页才两年了，甚至大多数页游，只是为了短时间洗用户抢钱，因此不会投入人力物力在外挂防御方面，或许第三方的安全服务会有点市场吧，比如说他们乐意购买支持多项目的AS混淆工具。总之，页游是个浮躁的市场，只有生命周期强大的游戏，才会注意到外挂问题。
==========================================================================================================================
SWF加密之隐藏密钥篇
本片博文介绍的加密方式为最基础的隐藏密钥的加密方式，当然目前来说这样的加密方式也是可以被破解的,也只是防君子不能放小人，加密最终极的办法还是混淆。（在swf文件个公开的情况下，如果adobe不提供支持，大部分情况下对swf的加密都是徒劳的），本篇只是对swf加密方式的一个整理，分享一种思路。如果您是swf加密高手很期待和您交流，
密钥隐藏
破环swf标准文件头是最简单也是最常用的方法。 向swf的二进制文件的文件头写入无意义的数据，这样就可以导致破解软件无法正常解析swf。
如图所示，向core.swf的ByteArray开始位置写入无意义的数据，
这样做的原理是Swf文件的前几位表示这个swf的版本信息，以及解析swf需要的参数数据，把它修改为无意义的数据，反编译程序自然也就无法解析了， 当然如果你这样做了之后，也会造成在运行时flashPlayer无法解析core.swf，
正所谓加密和解密是必定会是同时存在的一对好基友。所以我们就需要在core.swf加载好之后把破环的文件头还原回来，你就需要如一个正常的loader.swf来加载被加密的swf，并且把加载的swf文件头还原回来。如下代码
由于总所周知的原因，这样做只能防君子不能防小人，只是增加了破解者一点点工作量而已，破解者不能直接反编译core.swf、但是他可以破解loader.swf来找到解密代码(如上图红框的数字7是明文存在在loader.swf里的)，来还原core.swf的文件头。然后继续用反编译软件进行反编译，
参考资料 （摘自不知出处的地方）
SWF文件头
所有的SWF文件均以以下头部开始：
SWF文件头
| 字段 | 类型 * | 说明 |
| 签字标识 | UI8 | 标识字符： “F”表示未压缩 “C”表示已压缩（版本6或后续版本） |
| 签字标识 | UI8 | 此标识通常为“W” |
| 签字标识 | UI8 | 此标识通常为“S” |
| 版本 | UI8 | 单字节文件版本数（例如，0x06表示版本6） |
| 文件长度 | UI32 | 整个文件的字节长度 |
| 帧尺寸 | RECT | 单位帧的尺寸 |
| 帧率 | UI16 | 每秒的帧数，其16个位是按照8.8的格式表示的 |
| 帧数 | UI16 | 影片的总帧数 |
| * 此类型在基本数据类型一节中定义 | ||
文件头部是由一个三字节的标识符开始，为0x46、0x57、0x53（“FWS”）或者0x43、0x57、0x53（“CWS”）其中之一。“FWS”标识符说明该文件是未压缩的SWF文件，“CWS”标识符则说明该文件前8个字节之后（即文件长度字段之后）的全部数据为开源的标准ZLIB方式压缩。
上述方法仅仅只能防止一些对swf不了解的外行人，
如上图红框的数字7是明文存在在loader.swf里的。 那现在的思路就很清晰了,要做的就是把好个明文的数字7给隐藏起来，达到让破解者无法还原core.swf文件头。由于swf文件格式是公开的，毫无保密性，所以任何用AS实现的加密算法都是耍流氓（没用的），那我们有没有办法用其他方法来隐藏数字7呢。答案是有的：
有2种方法
1.alchemy
Alchemy 能够编译C/C++代码为AS3字节码(运行在AVM2上)能够运行在Flash或者Flex平台，并且Adobe宣传Alchemy能够为计算密集型任务提升性能(但是比原生C/C++慢)，
介绍完毕，我可以看到adobe把alchemy吹的神呼其神，事实上好像确实不错^_^。但是我们今天要用到的不是alchemy执行C/C++代码飘逸的效率，而是利用alchemy暂时（我只能说暂时，鬼知道以后asv会不会也能把alchemy给还原成C）无法被反编译的特性，有点旁门左道了，我想adobe捣鼓alchemy的初衷肯定不是让开发者用来加密自己的swf。但谁让adobe把swf格式公开了呢(这里扯个淡，任何东西都可能是双刃剑，破解使开发的劳动成果被瞬间复制的同时也间接间或一部分成就了flash的遍地开花，山寨起来容易啊，在天朝山寨才是王道，个人观点仅供参考，不要纠结flash真正火的原因)，
如上图为alchemy的一个HelloWorld的示例程序，你可以在C（alcnemy）返回我们解密用到的数字7，或者你觉得用数字其不放心。可以用个公式算一个数字出来返回。Alchemy的性能，我想再复杂的运算都是轻松搞定的。
如上图所示。 我仅仅写了个helloworld的程序。Alchemy就给我编译出几百个AS类来（截图只是一部分），你能找出还原算法在哪个文件里面吗。反正我是找不出，
还原时你要做的就是。 把alchemy编译的swc放到工程库里，执行如下代码，用返回的数字来欢迎core.swf的文件头。
二:Pixel Bender
Pixel Bender是Adobe开发的一种编程语言，用户可以使用该语言创建自定义滤镜、效果和混合模式，以用于Flash、AE（After Effects）和Photoshop。
Pixel Bender与硬件无关，可高效地运行于各种GPU和CPU体系结构之上。Pixel Bender开发人员通过编写Pixel Bender代码来创建滤镜。 欲知道详情请点击度娘
和alchemy一样。Adone 捣鼓Pixel Bender的初衷肯定也不是让开发者用来加密自己的程序。但是没办法，被adobe逼的呀、 
如图所示，你可以在pixelBender的返回值里，返回我们还原core.swf需要的用到的数字7。
用pixelBneder解密的过程过程可能有点复杂，不能直接调用方法并返回值。需要监听渲染成功事件。
如图fuckNum（罪过粗口了）就是我们的还原core.swf文件头需要用到的数字了
=======================================
好了。回到开始，以上介绍的加密方式目前来说都是可以被破解的,只增加了点破解的难度，加密最终极的办法还是混淆。这里只是对swf加密方式的一个整理，分享一种思路。如果您是swf加密高手很期待和您交流