as3杂记

一、内存回收方式：

　　1、引用计数【没有互相引用】

　　2、标记清除【fp自己检测是否引用，没有引用的清除】

二、通信方式：

　　1、http：小型页游【charles抓包查看】

　　2、socket：大型页游【WPE抓包查看】

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

三、加密工具：Amayeta SWF Encrypt 和 DComSoft SWF Protector ，

四、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文件，再用传播程度都烂大街的硕思闪客反编译得到源码。这一方法对游戏协议安全来说，是非常非常非常 悲剧的。

 

 

http://blog.sina.com.cn/s/blog_56c9b55c0100unzp.html

http://blog.sina.com.cn/s/blog_71f1fb3701015s29.html

http://blog.sina.com.cn/s/blog_731fdd2b01010u9k.html

http://www.cnblogs.com/wonderKK/archive/2013/01/25/2877063.html

 

转载于:https://www.cnblogs.com/tinytiny/p/3477125.html