珠海学网站开发,结婚证制作生成器app,足球比赛直播平台,app软件开发官网原文链接#xff1a;http://netsecurity.51cto.com/art/201211/364775.htm 页游#xff0c;最最核心的就是客户端#xff08;swf#xff09;与服务端的游戏通信了。游戏通信产生的封包#xff0c;内容是否可识别#xff0c;可篡改#xff0c;可重放#xff0c;处理逻辑…原文链接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了例如ASVactionscript 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的示例程序你可以在Calcnemy返回我们解密用到的数字7或者你觉得用数字其不放心。可以用个公式算一个数字出来返回。Alchemy的性能我想再复杂的运算都是轻松搞定的。 如上图所示。 我仅仅写了个helloworld的程序。Alchemy就给我编译出几百个AS类来截图只是一部分你能找出还原算法在哪个文件里面吗。反正我是找不出 还原时你要做的就是。 把alchemy编译的swc放到工程库里执行如下代码用返回的数字来欢迎core.swf的文件头。 二:Pixel Bender Pixel Bender是Adobe开发的一种编程语言用户可以使用该语言创建自定义滤镜、效果和混合模式以用于Flash、AEAfter 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加密高手很期待和您交流 转载于:https://www.cnblogs.com/hisiqi/archive/2013/01/26/2877573.html
